Friedrich W. H. Kossebau changed bug 1037891
What Removed Added
Flags needinfo?(kossebau@kde.org)  

Comment # 12 on bug 1037891 from
Hi. Not sure how much I can help, as I also need to look into Qt sources to see
which x11 properties are set how and read up on the X11 property info and the
window manager data (as linked above) to know what properties need to have
which values.

But well... so after searching around I find Qt does this with xcb for the
WM_CLASS property:
https://code.woboq.org/qt5/qtbase/src/plugins/platforms/xcb/qxcbintegration.cpp.html#_ZNK15QXcbIntegration7wmClassEv

Where the m_instanceName seems only set if "-name" argument is passed, see same
file.

So given the options there by the existing logic, to get "YaST2" instead of
"ruby" as first string of the WM_CLASS property, it's either
a) relying the caller to pass -name YaST2
b) tricking by some early qputenv("RESOURCE_NAME", "YaST2");
c) twisting the argc passed to qapplication instance to have argc[0] point to
"YaST2"

You hopefully have an idea what works best in the yast case.

Not exactly sure what really should be in the second string of the property,
might be less interesting. 

For getting proper window titles (*WM_NAME property), you might want to use
qapp->setApplicationDisplayName() (_Display_), with an argument containing
whatever has the module name (e.g. "YaST2 - Software Management") inside:
http://doc.qt.io/qt-5/qguiapplication.html#applicationDisplayName-prop


That all might still not solve the problem of the not-existing icon property,
which seems to be set via _NET_WM_ICON. Without that it's up to window
managers/shells to guess some matching icon (which IMHO should ideally be the
one referenced in the desktop file, so per module).


You are receiving this mail because: