bugGNUstep - Bugs: bug #14987, Applications cannot modify icon.

Group
 
 

bug #14987: Applications cannot modify icon.

Submitter:  Gregory John Casamento <gcasa>
Submitted:  Wed 16 Nov 2005 01:39:22 AM UTC
   
 
Category:  Backend Severity:  2 - Minor
Item Group:  Bug Status:  Fixed
Privacy:  Public Assigned to:  FredKiefer
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 24 Nov 2005 03:27:46 AM UTC, comment #7: 

Tested and working.  Closing.   Thanks Fred!!

GJC

Gregory John Casamento <gcasa>
Group administrator
Mon 21 Nov 2005 01:11:41 PM UTC, comment #6: 

Should be fixed in CVS

Fred Kiefer <FredKiefer>
Group Member
Fri 18 Nov 2005 05:56:58 AM UTC, comment #5: 

_NET_WM_ICON is a window property, not an application property. It's the image to be displayed when a window is iconified, or in OpenStep parlance miniaturized.

We have a name for that, it's called the miniwindow image. The app icon is not involved.

Anonymous
Fri 18 Nov 2005 05:28:10 AM UTC, comment #4: 

Fred,

My apologies if you took my posting to the list personally, it really wasn't meant that way.  See below for why...

The focus issue
---------------
Actually, I haven't experienced the focus problem discussed by Andreas on the list, at least not unless I switched workspaces and then clicked on the icon.   At which point the app would not come up because it was on a different workspace.   From my experience, Gorm and other apps always come forward when I click on the icon.  I actually just now tried to do this with the most recent CVS using exactly the case Andreas described in his email and I can't recreate it.

I admit that I jumped to the conclusion that the focus issue was related to this bug because I haven't seen it before, so I thought it might be a recent issue.  My mistake.

Bug severity discussion
-----------------------
In my experience as an engineer bug severity is judged based on impact to users, not on a scale relative to other bugs in the same system. 

In my opinion, since this bug impacts applications which use this functionality as thier primary means to display information, it is not a minor bug since those apps are rendered unusable by it.  It is, at the very least "Normal" in priority.

Testing with other window managers
----------------------------------
I've been quite busy this week attending to urgent and personal family matters (there was recently a death in my immediate family), so I didn't get to test this until tonight.  My results confirm yours and Chris' it does appear to be WindowMaker specific, please see my response to Chris on the bugs mailing list earlier today.

Conclusion
----------
As indicated, the problem appears to be WindowMaker specific.   Whether this will require a patch to WindowMaker or additional code in GNUstep, I'm not sure.  Please make whatever change you feel is right in this case.

If it is a WindowMaker problem, someone familiar with WindowMaker code should probably take a look and submit a patch.

Please write me at -email is unavailable- for further discussion.

Later, GJC

Gregory John Casamento <gcasa>
Group administrator
Fri 18 Nov 2005 12:28:11 AM UTC, comment #3: 

Hi Gregory,

I can understand that you are annoid about the fact that some functionality you are used to, currently wont work with GNUstep from CVS. But your posting on the discussion mailing list about the well known focus problem goes totally beyond my limit of acceptance:
"My guess is that this is also related to bug #14987 which I reported yesterday."

I was just about to submit the mentioned work around for Window Maker, but after reading that mail of you I am just fed up. What sort of attitude is this you are showing? I wrote a long explanation of the problem and asked you to confirm that it is a Window Maker problem (Chris Vetter did this). All you did was complaining about me setting it to be a minor problem. It is one, have a look at some of the other open problem in GNUstep if you don't think so.

Up to now I did regard you as a sensible person one could work with. Looks like I was wrong.

Anonymous
Thu 17 Nov 2005 01:47:09 PM UTC, comment #2: 

I disagree that this is a "minor" bug as many applications depend on the icon to display thier information and they are now non-functional.

TimeMon, for example, uses its icon to show the current CPU usage, batmon (a laptop battery monitor) uses its icon to show the charge level... etc etc..

Just to be clear, I'm referring to the icon which appears on the bottom of the screen when an application is run, not the window which shows when an app is miniaturized.

As for which way to go, I believe that kludging it for WindowMaker might not be a bad idea in the short term, but we should ultimately try to do it the "right way".

GJC

Gregory John Casamento <gcasa>
Group administrator
Wed 16 Nov 2005 09:55:20 PM UTC, comment #1: 

First a short explanation what the change from Nov. 7th acutally does. For EWMH specificvation complient window managers the property _NET_WM_ICON gets set to the applciaiton icon for all the windows of an application (Actually not true the inspector window of Gorm does not play along).
The result of this setting is for example in KDE that the windows show the application icon in the left uper corner of the window frame and also in the control panel, where the running applications are listed.
This may not be the best icon to use, but the mini window image set for a window is not passed on to the backend. Also the changing of the application icon is not forwarded to the backend.

To your problem, I cannot reproduce it with KDE, so it is most likely a window manager specific problem, probably in your case one of Window Maker. I would expect that Window first tries to get a EWMH icon for a window and failing that tries the specific GNUstep way to get hold of the icon.
Now the strange bit is that the app icon pixmap for Window Maker is also create only once. So what is Window Make displaying that changes with the changed application icon?

To resolve the issue I see two ways to go. The simple one is not to set the _NET_WM_ICON property for Window Maker, a one line change. The other would be to informe the backend whenever the mini icon of a window changes and recompute the displayed icon for the window each time. This requires much more thinking and coding. But first we need to reach a common understanding of what is causing the problem.

Fred Kiefer <FredKiefer>
Group Member
Wed 16 Nov 2005 01:39:22 AM UTC, original submission:  

I have confirmed that this problem is due to a change to XGServerWindow.m in back made on the 7th of November.

To recreate:

1) Update via CVS to latest code on the trunk.
2) Compiled/build.
3) Open Gorm.app
4) Start a new application
5) Test application

Result: The Gorm icon remains the same.
Expected: The Gorm icon should have the word "testing" in front of it.

Alternatively... compile and start any other application which modifies it's icon as part of it's operation.  The best example of this is TimeMon.

GJC

Gregory John Casamento <gcasa>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

Only logged-in users can vote.

 

Follow 5 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2005-11-24 gcasa StatusReady For Test Fixed
    Open/ClosedOpen Closed
2005-11-21 FredKiefer StatusNone Ready For Test
2005-11-16 FredKiefer Severity4 - Important 2 - Minor
    Assigned toNone FredKiefer

Back to the top

Powered by Savane 3.13-d3ae.
Corresponding source code