bugGNUstep - Bugs: bug #26438, First application does not get a...

Group
 
 

bug #26438: First application does not get a proper app icon under Window Maker

Submitter:  Wolfgang Lux <wlux>
Submitted:  Sun 03 May 2009 09:50:39 PM UTC
   
 
Category:  Backend Severity:  3 - Normal
Item Group:  Bug Status:  Fixed
Privacy:  Public Assigned to:  None
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 17 Dec 2021 12:09:24 AM UTC, comment #9: 

I tested here and there and I was confused. CUrrent behaviour is still bad, but it is different. THe "first icon ever" problem appears gone and so e.g. battery monitor works on first launch.

Now, instead I can get a totally grey icon for the time the application starts and becomes active, can take a while. Also when app-icon bounces with windowmaker it may flicker. It is a different issue.

This should be then the same bug as

https://github.com/gnustep/libs-back/issues/30

Hellp me out there, Wolfgang, closing this bug.

Riccardo Mottola <rmottola>
Group Member
Mon 13 Dec 2021 10:09:13 PM UTC, comment #8: 


> Is this still an issue?

After testing this again, I don't think it is an issue anymore. The issue had been fixed by my own fix about six years ago and, contrary to what I had suggested in the previous comment, Sergii's changes do work as well.

Riccardo wrote:

> Unfortunately yes, it is still an issue, but it changed. Sometimes it is totally grey or is a black silouhette or on certain backends/bit depth combinations it doesn't work at all.

Does this happen only for the first app icon? And when it happens do you get the default WindowMaker menu instead of the application's main menu? If not then there is presumably an issue but it's a different issue and this issue can be closed (I would do it myself, but obviously I lack the permissions to do so.)

Wolfgang Lux <wlux>
Fri 10 Dec 2021 01:47:07 PM UTC, comment #7: 

This issue is not related to the backend, it's an issue interacting with the WindowMaker protocol that allows GNUstep applications to control the app icon instead of having WindowMaker manage the app icon itself. Essentially, it means that the app icon must be the first window that a GNUstep application opens and maps to the screen. You can find a little bit more detailed explanation in this email on the GNUstep developer's mailing list: https://lists.gnu.org/archive/html/gnustep-dev/2020-10/msg00013.html
In fact, I had committed a fix for this issue about 6 years ago here: https://github.com/gnustep/libs-back/commit/1e1185abb364f2ffcb5f06f62c1241d419b8b697
However, that change was reverted shortly before the 0.29 release here https://github.com/gnustep/libs-back/commit/e5cdc1747be3b7d71e22b3757fb7649f99ace1b5#diff-c3c9abc7461037f8abf3f590d909cff84c39bc7817b79d7dfd379b38a3756385 because the fix was causing unwanted flickering of the app icon, which I hadn't noticed. So the issue apparently is back again.
I guess a proper solution would be to reinstate the original fix, but use that code path only when the frame offsets aren't known.

Wolfgang Lux <wlux>
Fri 10 Dec 2021 08:07:07 AM UTC, comment #6: 


comment #5:

> Unfortunately yes, it is still an issue, but it changed. Sometimes it is totally grey or is a black silouhette or on certain backends/bit depth combinations it doesn't work at all.


Is this an issue on the cairo backend? (It's still important if it's not, it simply helps to determine where the code issue is)

Gregory John Casamento <gcasa>
Group administrator
Thu 09 Dec 2021 02:55:41 PM UTC, comment #5: 

Unfortunately yes, it is still an issue, but it changed. Sometimes it is totally grey or is a black silouhette or on certain backends/bit depth combinations it doesn't work at all.

Riccardo Mottola <rmottola>
Group Member
Thu 09 Dec 2021 09:30:26 AM UTC, comment #4: 

Is this still an issue?

Gregory John Casamento <gcasa>
Group administrator
Thu 29 May 2014 11:16:35 PM UTC, comment #3: 

Sadly, this bug still holds.
For most applications it is not so evident. But for an application like a battery monitor it means that iw will show an icon instead of the actual status!

Riccardo Mottola <rmottola>
Group Member
Mon 19 Apr 2010 01:12:27 PM UTC, comment #2: 

been a while since i've looked at this, so this may be hogwash.

IIRC the way appicons work in windowmaker is somewhat odd.

in the ICCCM if you look at...
4.1.2.4. WM_HINTS Property
where it talks about the initial_state hint it only describes behaviours for IconicState and NormalState,

iirc windowmaker does something special when the first window is mapped with its initial_state to WithdrawnState.
making that window the app icon window...

this happens in -orderwindow::: after the comment...
/* If we are asked to set hints for the appicon

i'm kinda confused on one thing, it looks like 'UseWindowmakerIcons = NO' default shouldn't really work anymore since the following patch, I mean... it looks like we create the windowmaker icon... but just don't send it any events in XGServerEvent or something... maybe wlux was just talking about the effect he would expect from UseWindowmakerIcons = NO?
anyhow, i haven't tried it.

https://savannah.gnu.org/patch/?5434

anyhow further down in XGServerWindow.m:-orderwindow:::
the comment starting with...
/* This doesn't appear to do anything useful, and, at least

iirc this line ensured that the first window mapped was the icon window, it could possibly be refined to aleviate the problems which caused it to be commented out.

it probably 'doesn't appear to do anything' because -gui was creating/mapping the app-icon window first anyways until the offset checks...

matt rice <ratmice>
Group Member
Mon 19 Apr 2010 10:52:43 AM UTC, comment #1: 

I tired to figure out how our interaction with Window Maker works and failed to understand it. How will Window Maker know that we don't provide our own icons? The flag UseWindowMakerIcons is only used internally, I don't see a way to tell this to Window Maker. There also isn't much difference in how we create normal windows and the ones used to determine the style offset. The only difference I could spot is that we don't request NSIconWindowMask | NSMiniWindowMask in the style of the check windows. And I would have thought this is the right thing to do. So why is Window Maker creating an app icon for these windows? To me this seems to be more of an Window Maker issue than a GNUstep one.

I am not using Window Maker, so I wont be able to look into this issue at all. If somebody is interested in solving this I am willing to help though.

Fred Kiefer <FredKiefer>
Group Member
Sun 03 May 2009 09:50:39 PM UTC, original submission:  

The first application started in an X-Windows session using Window Maker as window manager does not get a proper app icon and application menu. Instead, the standard Window Maker application menu is shown when right clicking the app icon as if the application was started with UseWindowMakerIcons = NO. If the user default GSIgnoreRootOffsets is set to YES this happens for every application.
Obviously, the problem is the code in XGServer's -_setupRootWindow method that attempts to determine the dimensions of the window frame added by the window manager. This code creates a few windows before the application creates its app icon. Apparently, Window Maker creates a standard app icon with its own menu when it becomes aware of the first of these windows and then ignores the later request for a custom app icon from the application.
I'm not sure what a good fix for this problem is. Of course, we could always special case Window Maker and just fix the window frame offsets for Window Maker (hoping that they will never change :-). Maybe the backend could always create an app icon window in advance before testing the window frame offsets and then later use this window instead of creating a new one when the application wants to create the real app icon window.

Wolfgang Lux <wlux>

 

(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

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -email is unavailable- added by gcasa (Posted a comment)
  • -email is unavailable- added by rmottola (Posted a comment)
  • -email is unavailable- added by ratmice (Posted a comment)
  • -email is unavailable- added by FredKiefer (Posted a comment)
  • -email is unavailable- added by wlux (Submitted the item)
  •  

    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 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-12-17 rmottola StatusNone Fixed
        Open/ClosedOpen Closed
    2010-01-30 FredKiefer Dependencies- bugs #28465 is dependent

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code