Re: windowmaker - application icon missing at first start

[Sergii Stoian]

Hi Wolfgang,

On Oct 18, 2020, at 14:38, Wolfgang Lux <wolfgang.lux@gmail.com> wrote:

Hi Sergii,

Hi,

On Oct 17, 2020, at 00:27, Wolfgang Lux <wolfgang.lux@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