The previous post about extending the window menu caused a great deal of discussion. It would seem that our readers would be interested in an implementation. Thomas is considering working on this after the window matching experiments are more stable.
Now, we can imagine that any package might want to add menu options when it was installed, and delete them when it was removed. Let us not concern ourselves for the moment with how a menu option and its effects are represented, other than assuming that it may be represented by an ASCII string. Rather, let us consider the ways in which a newly-installed application may wish to add menu options. We are concerned with two kinds of menu option:
- ∀: these appear on every window menu, for as long as the application is installed. It need not be running. For example, Take screencast should be available when Istanbul is installed and removed when Istanbul is removed.
- ∃: these appear only on the menus of windows created by the application itself. For example, Play should appear on Rhythmbox‘s window menu, but not on other applications’ menus, even if Rhythmbox is running. (Otherwise, how would a user tell the difference between Rhythmbox’s Play and the Play of Totem?)
Users should have the option of disabling any ∀ options which are currently installed; the full set of ∀ options would be available in some kind of settings dialogue where a decision could be made about which options belonged on the list. It should be noted that Minimize, Maximize, Close, etc., are the ∀ of the window manager itself.
So, where should these settings be stored?
- In X properties on windows: The ∀ options would be stored as properties on the root window, and the ∃ options as properties on the windows involved. This would be the simplest to implement, but who has the responsibility to set the property on the root window, and where does the data come from?
- In GConf: This would only work for ∀ options. It’s presumably a better plan than keeping them on the root window, though, and we could still use X properties for the ∃ options.
- In /usr/share/applications/*.desktop: This is the way which would integrate best with package management, but would cause rather a performance hit as all the .desktop files would need to be scanned when the WM started up, and then there would need to be some kind of particularly clever window matching to work out which .desktop file corresponded to which windows for ∃.
Some kind of hybrid approach may be best: we could keep the ∀ menu options in .desktop files, and have a utility program that was run when any package was added or removed, to update GConf with the values. Or perhaps this updating could be done in the control centre, when the user chose which subset of ∀ options they wanted. Then we could keep ∃ options as properties on the windows, and rely on the toolkits to update them (perhaps even by parsing the application’s .desktop file).
Photo © van swearingen, cc-by-nc-sa.
For ∀ menu entries, using GConf seems not a bad idea.
And for ∃ is not D-Bus an option ? This should provide a way for applications to interact with window managers that supports it. Of course, applications should not rely on that feature to work, but use it as an option.
Using D-Bus will also be really dynamic, letting the application change menu entries depending on their own internal state (example: Rhythmbox may change entries when it’s playing or not).
That said, if D-Bus is used, entries provided through GConf for ∀entries, may also be provided by an other application (session management for example).
For ∀:
I agree this needs to be managed in an external way. But i think there are not that much cases besides the things that actually exist and some other features like “Take Screenshot” or something else. In my opinion the interesting part is ∃.
For ∃:
My idea would be to extend the current API so that programs can register functions through a callback mechanism. Something like
add_to_taskbar_menu(icon, text, function)
To be honest I dont know if this fits into the current architecture. Are programs allowed to alter the menu, or is it a pure metacity thing?
I don’t think this post or the previous one explains *why?*.
Why do we want to mix in a few application menu entries into the window menu? Take screenshot ok, it’s very window-centered, but Play absolutely not! There is already a menu in the window normally, the gtk menu (even though I prefer a global menu bar). Does it really help the user to have very random non-window actions in the window menu?
From the small window menu, there I do not see much added value.
But, the same menu is used when you right click on the window title bar. And it may be used in various other places in the future (i’m thinking about the gnome-shell scaled windows view, why not when your right click on it be able to interact with your application). If there is an easy way to expose custom menu entries, it should be easy for other applications to also display those entries n their contextual menus (for example the gnome taskbar).
This allows you to quickly access some specific applications actions without bringing the whole window to the front.
@Oliver: That can be valid. Hopefully in the future desktop windows are going to be really interesting objects to act on.
Sound control is some thing that needs to be bound to the window some how…
Every sound playing application having its own sound level slider / mute option is just silly :)
Pulseaudio already has the beginnings of this in that you can set the xid for any stream it just needs to be all bound together