Mailinglist Archive: opensuse-bugs (4295 mails)

< Previous Next >
[Bug 1037891] All YaST module window names show "ruby" instead of a more specifc name (was: Yast module windows in Plasma: generic x window icon and grouped as "ruby" in task manager)
  • From: bugzilla_noreply@xxxxxxxxxx
  • Date: Tue, 23 May 2017 18:31:32 +0000
  • Message-id: <bug-1037891-21960-YNI2anWoze@http.bugzilla.suse.com/>
http://bugzilla.suse.com/show_bug.cgi?id=1037891
http://bugzilla.suse.com/show_bug.cgi?id=1037891#c12

Friedrich W. H. Kossebau <kossebau@xxxxxxx> changed:

What |Removed |Added
----------------------------------------------------------------------------
Flags|needinfo?(kossebau@xxxxxxx) |

--- Comment #12 from Friedrich W. H. Kossebau <kossebau@xxxxxxx> ---
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:
You are on the CC list for the bug.
< Previous Next >