2

Metacity: Further thoughts on extending the window menu

view story
linux-howto

http://blogs.gnome.org – 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. (Software)