On 8/21/06, Martin Ejdestig <[EMAIL PROTECTED]> 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 _______________________________________________ Usability mailing list [email protected] http://mail.gnome.org/mailman/listinfo/usability
