GNOME Bugzilla – Bug 167630
Metacity keybinding commands need to use startup notification
Last modified: 2006-05-03 23:17:30 UTC
A couple days ago, Sebastien pointed me to https://bugzilla.ubuntu.com/show_bug.cgi?id=3159. He had already slowly let me know of most the issues that had been reported there, but there was one new one--if we launch an application such as gnome-terminal with a keybinding, we aren't using startup notification. That breaks focus stealing prevention, and results in windows taking focus when they shouldn't on map, as well as weird apps (e.g. gnome-terminal, nautilus, epiphany, etc.) not getting focus when they should. Four solutions that I can think of: 1) Declare this to be not a bug (I use the word 'solution' very loosely here). Very easy from the implementational side of things, but I believe is the poorest behavior for the majority use case. 2) Add some kind of checkbox to the UI as well as the necessary gconf keys in order to allow users to specify whether commands should be launched with startup-notification. Technically works perfectly (assuming sufficiently smart users), but sounds like a pain to implement, breaks freezes, and doesn't feel like a "Just Works" solution to me. 3) Just launch all keybinding commands with startup-notification. Not an optimal solution, but at least gets the majority use case right. This solution actually seems tenable because no apps are bound by default anyway so we don't have to worry about legacy applications. It would have the drawback of preventing users from wanting to bind keybindings to legacy apps (e.g. xterm), but would perhaps encourage them to update to something newer (e.g. gnome-terminal). 4) Write a short metacity-launch-helper program, and always launch it with slightly modified startup notification. (i.e. when 'metacity-launch-helper gnome-terminal' is launched, have the taskbar show "launching gnome-terminal" not "launching metacity-launch-helper"). Have metacity-launch-helper run ldd on the specified executable. If appropriate toolkits are found (e.g. qt or gtk+), then just set DESKTOP_STARTUP_ID appropriately and launch the program without ending startup-notification; otherwise manually end startup notification and launch the program without setting DESKTOP_STARTUP_ID. This solution would get most cases right (though adding a small delay to program startup time) and would be easily upgradeable separate from Metacity if the need came up. It might even be useful outside of metacity as well for post-2.10 stuff (see, for example, bug 162424 and bug 161322). Out of the four options above, I like the fourth the best. Can anyone see any others? Does the fourth sound okay? Let me know so I can get coding...
2b) When adding the command scan the .desktop files for that command and set startup-notification on/off appropriately. This could also be done when the command is actually started, but that might slow everything down too much. This might be hard to keep as a gconf setting because I read somewhere that gconf settings shouldn't depend on each other. I personally hate 1, original 2 (I would never turn it on) and 3 (I still want to run legacy apps without screaming). Option 4 sounds perfect. If it is really possible to determine reliably if a command supports startup-notitication maybe this can be used more (and cache whether a command supports it somewhere). Eg what about gnome-volume-properties. You can fill in commands there too, how does that determine to use startup-notification?
5) Try to use startup notification, and if the notification times out on the command stop trying to use it in the future. When lauching from the WM we're in the unique position to be able to match up startup notification events with the command that triggered it.
(Warning, I know almost nothing about wm's and such.) How easy is it to: a) set a reasonable timeout b) use startup notification if the app supports it c) notice if the app creates a window d) stop whenever any of the above occur e) continue providing an awesome desktop experience it seems like this provides the best of all worlds, especially when combined with the helper program from 4) above...smart gnome/kde awareness, crutches for xterm, and also support programs which don't ever open a window.
Created attachment 37992 [details] [review] Part way there... Here's a functional but incomplete patch to use startup notification on keybinding commands. Problems: 1) Only tested for the run terminal command so far (but works really nicely for that case) 2) Adds a translatable string (but it's _identical_ to a translated string found in gnome-desktop, so if someone can pull out their script-fu, then we can get this by without breaking string freeze) 3) Use of startup-notification is unconditional (i.e. bad for legacy apps) 4) No timeout has yet been added (i.e. /really/ bad for legacy apps) However, it implements the common part of choices (4) and (5) listed previously so I thought I'd attach it. Hopefully I'll be able to tackle the other half of either (4) or (5) tomorrow.
Well, I didn't finish it. It would have been a lot of cut & paste from gnome-desktop (more than what I already did to get this patch together; all from gnome-desktop-item.c) in order to add a timeout, plus some new code to track which binaries we had previously launched with startup-notification but which resulted in the timeout running its full length. Anyway, with the nautilus, gnome-terminal, and epiphany patches to better handle not being launched with startup-notification, I think we'll punt this to 2.12. Besides, then it should be easier because startup notification will be added to gnome-vfs so hopefully we'll just be able to use that.
updating per comments.
*** This bug has been marked as a duplicate of 114384 ***