Re: [Usability] Bug: Applications appearing on other desktops than started

["Elijah Newren" <newren gmail com>]

On 8/21/06, Martin Ejdestig <marejde gmail com> wrote:
> On Sun, 2006-08-20 at 21:18 -0600, Elijah Newren wrote:
> > It is almost as likely to be a bug in the application launcher as it
> > is in the application itself.  If the application is not launched with
> > startup-notification, the WM has no clue where the app was launched
> > from and only knows what the current workspace is when the application
> > finally maps its window.
>
> The bug should still be filed against the app assuming the launcher
> that comes with it is used and is missing StartupNotify=true. ;)

In most cases, yes.  :)  There is at least one other possibility I can
think of, though.  The user may have created one of their own
launchers (i.e. added a "Custom Application Launcher" to the panel);
last I checked, the custom launchers don't turn startup-notification
on and don't provide an option to do so.  Of course, last I check was
quite some time ago...

> I had a vague notion of what needed to be done. Thanks for the details.
> I've also been following Vytas' work from a distance. A GNOME Goal
> candidate for sure... when he's done that is. :)
>
> That it doesn't work when launched from a terminal and custom launchers
> where StartupNotify=true is left out can be quite confusing. Is there a
> reason why there ain't a function in GTK+ apps could call at startup
> that would have the same effect as StartupNotify=true in .desktop files?
> (I still haven't look at the details so bear with me. ;)

By the time the application could call some function to find out what
the "current" workspace is, the user may have already changed
workspaces.  So, the basic answer is no -- the launcher application
needs to find out the workspace and launch the launchee with startup
notification.  The more advanced answer is: (1) the launcher also
can't determine the "current" workspace with 100% precision either
(there's also a race there, though the likelihood of a user being fast
enough to be able to trigger it between clicking on a launcher and
switching workspaces is vanishingly small), (2) we could potentially
add workarounds at the gtk+ level to try to compensate for this  (e.g.
in _gdk_windowing_set_default_display()), but none exist at this time
and any such workarounds would almost certainly result in triggerable
race conditions (non-deterministic behavior regarding which workspace
the application would show up on) for the user.  (Note that gedit is
an application that manually does such workarounds on its own)

Cheers,
Elijah