Hi Wolfgang, > On Oct 18, 2020, at 14:38, Wolfgang Lux <wolfgang....@gmail.com> wrote: > > Hi Sergii, >> >> >> Hi, >> >>> On Oct 17, 2020, at 00:27, Wolfgang Lux <wolfgang....@gmail.com> wrote: >>> >>> Hi Riccardo, >>> >>>> I noticed we recently have a strange behaviour, which is slightly >>>> different from setup (= installation on different computers) to setup I >>>> have >>>> >>>> The first time I start a GNUstep application with windowmaker (I mean >>>> the first GNUstep app started ever after X11 start essentially) it has a >>>> bad icon. >>>> - on some setup it has a "generic" icon by windowmaker >>>> - on other setups it has a black looking icon, as only the "mask" of the >>>> icon, the contours are drawn >> >> Riccardo, could you please provide more info on your specific setups? >> Do you have “UseWindowMakerIcons” set to “NO” in NSGlobalDomain? >> >>>> >>>> A restart of the app and then starting any other app, fixes that. >>>> >>>> >>>> This was not happening before. >>> >>> Actually, this has been happening before, but it was fixed about five years >>> ago in this commit: >>> https://github.com/gnustep/libs-back/commit/1e1185abb364f2ffcb5f06f62c1241d419b8b697#diff-c3c9abc7461037f8abf3f590d909cff84c39bc7817b79d7dfd379b38a3756385 >>> >>>> I think it is related to at least this >>>> commit - merge: >>>> >>>> https://github.com/mozilla/newtab-dev/raw/6be44da368fb869a3d3e1975f515857352a7d9fc/browser/modules/ProcessHangMonitor.jsm >>> >>> I assume you meant this commit instead >>> https://github.com/gnustep/libs-back/commit/31b7c4ed2f8efa0127605511aaf4eafef6a3d1c8 >>> And, yes, your suspicion is correct because it exactly comments out the >>> earlier fix. >> >> As stated in description to this commit it fixes flickering of appicon at >> application start. Quote: “This fix based on the fact that root application >> window (ROOT) is mapped in `-orderwindow:::` and this is the event of >> application recognition by WindowMaker because it is a first application >> window that is mapped.”. That "root application window" is called “group >> leader” and saved in every application window structure (WWindow) member >> `main_window` inside WM. It holds all required properties to be detected by >> WM correctly. >> >> The earlier fix probably masks other unknown problem. My WindowMaker 0.95.7 >> default configuration tests work like a charm. >> Wolfgang, do you observe the same behaviour as Riccardo? I yes, could you >> please share your setup? > > Sorry, I haven't been using WindowMaker for a while so I can't really > contribute anything > here. However, I can perhaps try to better explain the rationale for the fix. > Normally, > WindowMaker manages the app icon and the menu on the app icon itself. > However, it does > allow GNUstep applications to override that app icon by supplying those on > the app icon > windows. The problem here is that this works only if the app icon is the > first window which > is opened by the GNUstep application. This is not a problem in general, as > the first window > opened by gnustep-gui is the app icon. However, for the very first > application in an X11 > session, gnustep-back wants to determine the frame offsets and it does so by > opening a set > of off-screen windows in the _checkStyle: method, which is called from > setupRootWindow. > The important point here is that these windows are created *before* the app > icon window is > created in the -window:::: method. And at the point where the first auxiliary > window is > created WindowMaker creates an app icon for our application itself. Our > attempts to set the > icon and menu through the app icon window created by the -window:::: method > then go to the > wrong window are ignored by WindowMaker. The fix I had committed simply > attempts to make > sure that our app icon window is created before the auxiliary windows. If you > see a flickering > here, you might attempt to improve the fix by creating the app icon only when > the backend > is actually going to call _checkStyle: and create any auxiliary windows. > > Note that in a normal configuration the issue applies only to the first > application started > in an X11 Session, but you can set the default GSIgnoreRootOffsets to YES to > have the backend > determine the frame offsets for every application. > > Hope this helps, > Wolfgang
Thank you for excellent explanation. You’re absolutely right about _checkStyle: - I forgot about it since I’ve created a PR. Although probably code was changed and it works slightly different now. _checkStyle: method is called from _setupRootWindow only if GSBackHandlesWindowDecorations is set to YES. At least now I understand what we should check in Riccardo's setup. Riccardo, do you have GSBackHandlesWindowDecorations set to YES? Sergii
