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

["Elijah Newren" <newren gmail com>]

On 8/21/06, GSR - FR <famrom infernal-iceberg com> wrote:
> Hi,
> newren gmail com (2006-08-21 at 0954.18 -0600):
> > > 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)
>
> Maybe the startup notification spec should support an environment
> variable determining workspace and viewport, so via wrapper in
> terminal users could get a similar behavior ("startupnotify foo"). It
> will have the same issue than in 1 (really fast user), but solve the
> terminal problem. As a plus, it would allow simple control to launch
> apps in a fixed workspace & viewport (so really really fast users =
> scripts, could do without having to change anything, just set the env
> vars and launch).
>
> Maybe a heavier wrapper could be done that does the same than panel
> launchers, tho that would lose the option of choosing w&v, I guess. Or
> does such tool already exist (I know wmctrl could probably be used for
> a shell based launcher if there was support for env var)?
>
> Probably this topic would be better discussed in the startup
> notification list.

Checkout the startup-notification module from cvs.freedesktop.org and
take a look at the test-launcher in the test subdirectory.  Of course,
this doesn't quite handle everything: the current startup-notification
spec doesn't handle viewports at all, and workspace handling is
slightly suboptimal in that it doesn't do everything that
open-in-new-tab apps such as gedit or web browsers would want.

Note that a huge part of the problem with terminals is that people
aren't going to prepend all their terminal commands with an additional
program name of some sort (they'll continue typing "foo" instead of
"startupnotify foo").