Bug 657 - TN inferring WMClass from Exec is prone to breakage, it should ignore quotes
: TN inferring WMClass from Exec is prone to breakage, it should ignore quotes
Status: RESOLVED WORKSFORME
Product: Desktop platform
Application Menu
: 4.1.3 (5.2008.43-7)
: All Maemo
: Medium normal (vote)
: ---
Assigned To: unassigned
: task-navigator-bugs
:
: moreinfo
: int-87419
:
  Show dependency tree
 
Reported: 2006-06-28 19:01 UTC by Neal H. Walfield
Modified: 2010-03-10 21:25 UTC (History)
4 users (show)

See Also:


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description Neal H. Walfield (reporter) 2006-06-28 19:01:52 UTC
gpe-calendar has recently adopted the following as its Exec field in its
.desktop file:

  /bin/sh -c '. /usr/bin/connectivity_preload.sh; /usr/bin/gpe-calendar'

For reasons which I have not yet completely understood, this has caused problems
with gpe-calendar properly being register with maemo_af_desktop.  Adding
StartupWMClass=gpe-calendar to the desktop file fixes the problem.

Currently,
maemo-af-desktop-2.6.20/hildon-navigator/hn-wm-watchable-app.c:hn_wm_watchable_app_new,
takes the basename of the exec_name key (using g_path_get_basename) as the value
of the startup_wmclass key if that key is not present.  This means that it takes
gpe-calendar' (with a trailing quote) as the key name.  Setting the
startup_wmclass key in the .desktop file explicitly to gpe-calendar (without the
trailing quote) appears to fix the problem.
Comment 1 Tommi Komulainen nokia 2006-07-02 15:02:12 UTC
The bug here is that given 
Exec=program 'some args'

the derived wmclass is "args'" and not "program" (which means even if the bug is
fixed you'd still need to use explicit StartupWMClass in the .desktop files)

The derivation is meant to be identical to how gtk/gdk sets the WM_CLASS for its
windows, either it's derived from argv[0] or the value given by the developer
using g_set_prgname() The implicit behavior is a bit fragile (on GNOME Desktop
this inconsistency breaks startup notification) and breaks if the executable
referred by Exec is different from the eventually executed binary, or the
application uses g_set_prgname() -- but it works well enough for the common case.

Which is why the explicit StartupWMClass exists.
Comment 2 Eero Tamminen nokia 2008-12-30 17:18:33 UTC
Bug 3828 handles the issue of Maemo window management needing correct WMClass
for things to work, so focusing this into the issue of using Exec field and not
handling quotes.
Comment 3 Quim Gil nokia 2009-01-17 01:31:22 UTC
It would be good if Karsten could hav a look to this one.
Comment 4 Quim Gil nokia 2009-09-21 09:14:16 UTC
This very old bug has the target milestone set to Fremantle but has not filed
internally. Something looks weird here. :)
Comment 5 Andre Klapper maemo.org 2009-09-21 15:06:51 UTC
True - Unsetting. Maybe Eero could explain the status here if he finds time.
Comment 6 Quim Gil nokia 2009-10-14 08:40:54 UTC
Can this be reproduced in Maemo 5?
Comment 7 Andre Klapper maemo.org 2010-03-10 21:25:28 UTC
Unfortunately, without more information, as requested in one of the last
comments, we are unable to do anything more about this report. Until more
information is available, I'm resolving the report as WORKSFORME for Maemo5
(Fremantle). Note that this WONTFIX for Maemo4 (Diablo).
Please feel free to reopen this bug if you can still reproduce this in Maemo5.