Bug 3828 - (int-87419) Act like a standard task navigator (don't rely on StartupWMClass)
(int-87419)
: Act like a standard task navigator (don't rely on StartupWMClass)
Status: RESOLVED WONTFIX
Product: Desktop platform
window-manager
: 5.0-alpha
: All Linux
: Low enhancement (vote)
: ---
Assigned To: Tapani Pälli
: window-manager-bugs
:
:
:
: 657
  Show dependency tree
 
Reported: 2008-10-27 11:35 UTC by Thomas Perl
Modified: 2010-03-11 17:37 UTC (History)
3 users (show)

See Also:


Attachments


Note

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


Description Thomas Perl (reporter) 2008-10-27 11:35:11 UTC
SOFTWARE VERSION:
All Maemo versions up to the latest Diablo release

STEPS TO REPRODUCE THE PROBLEM:
Write an application that has a different StartupWMClass than the binary name
or (even worse!) the "StartupWMClass=" property in the .desktop file.
Alternatively, just write an SDL application and always have this problem!

EXPECTED OUTCOME:
I don't need to specify "StartupWMClass=" in the .desktop file and all windows
appear in the task navigator, like on a standard GNOME/KDE/XFCE Desktop.

ACTUAL OUTCOME:
The window does not appear in the task navigator. Switching away from the
window makes it disappear and no way to make it re-appear, with the program
still running (!!!!)

REPRODUCIBILITY:
always

EXTRA SOFTWARE INSTALLED:
-

OTHER COMMENTS:

This section in the Wiki describes "Adding support for the Task Navigator". In
an ideal world, we would not need to do this. Other task navigators/window
managers work fine without these "hacks":

https://wiki.maemo.org/Game_development#Adding_support_for_the_Task_Navigator
Comment 1 Eero Tamminen nokia 2008-11-03 16:25:11 UTC
TN implementations (already in 770) have been tightly bound to the concept of
Desktop file objects (which contain translated app names, D-BUS services names,
icons etc), windows are just mapped to these (using WMCLASS property). 
Changing this will require major changes i.e. this will not happen in Diablo,
but hopefully in Fremantle.
Comment 2 Eero Tamminen nokia 2008-12-30 17:13:06 UTC
Note: NB#87419 is about being able to manage windows that don't have their
WMClass properly set.  Even with that fixed, correct WMClass would still be
needed for single instance launching.
Comment 3 Quim Gil nokia 2008-12-30 17:34:36 UTC
As a comment aside, this report is listed at
http://wiki.maemo.org/Mainstream_Linux_Alignment
Comment 4 Andre Klapper maemo.org 2009-04-23 15:17:39 UTC
Still valid in Fremantle, but very low priority.
Comment 5 Thomas Perl (reporter) 2009-12-23 17:21:53 UTC
Is this really still an issue on Maemo 5? AFAIK the first window that gets
mapped after the application icon has been clicked replaces the "loading"
window, so as far as I'm concerned the bug has been fixed in Fremantle at least
since the Summit image.

(This was an issue for Diablo, but in Fremantle, the task navigator seems to
show all toplevel windows, including SDL apps.)

As far as I'm concerned, this bug can be closed as FiF.
Comment 6 Eero Tamminen nokia 2009-12-28 10:50:54 UTC
What about Desktop stuff that e.g. uses splash screens / startup progress
windows which go away once the real program window comes up?  Do those work
properly too?
Comment 7 Andre Klapper maemo.org 2010-03-11 17:37:46 UTC
WONTFIX internally.