The Metacity theme format has been roughly the same for six years now. Many people are quite happy with it as it is, but we fairly regularly get people coming along and asking why it can’t do this or that and how they can make it do so. The trouble is that changing the theme format is a fairly large upheaval, and not something we’d like to do much. Recently, two ideas have been put forward to change all that by making it not our problem to change the format if some newfangled idea comes about that we don’t support already.
- It’s GTK’s problem. Metacity doesn’t draw borders at all any more. This makes us a much more lightweight window manager, because all we’d have to do is keep out of people’s way and manage windows. It also means that the toolkit can interact more easily with the borders, leading to fun stuff like these Tango experiments. (Of course, this is a source of OOH SHINY, which gets people writing about GNOME more than anything else.) Or as alex-weej points out, we could do things like this using standard libraries. Downsides: non-GTK applications have a bit of a problem; we would obviously still need to figure out what we’re doing about window border theme file formats; all this will need a lot of coordination between people from different projects. However, it does have the seeds of great awesomeness within it.
- It’s librsvg’s problem. Make a new file format where everything is based on SVG files. Feed these into librsvg, substituting results of expressions as appropriate. There you have a simple format which can do anything librsvg can do, and keeps on growing as librsvg keeps growing. (This is all possible; I’ve done a little bit of test work here.) Allow no other instructions but a set of SVGs (I have the way to do this in my head if anyone’s interested, but I won’t bother writing this down if this is going to be a blind alley). Add a script which can take out an SVG so you can edit it with Inkscape. Disadvantages: it’s an evolution, not a revolution; it’s slower than the current system in tests (though I haven’t tried to optimise it); it doesn’t let us do all the fun stuff the other option does.
- Both.
- Neither.
Your thoughts, Gentle Readers, both on the pros and cons of each and of the best choice? I shall be updating the post with your ideas, with attributions.
Photo: © swizzled, cc-by-nc-sa
I’m no Metacity or GTK expert, but to me it sounds like suggestion 1 would also allow for the cool window border ideas suggested by Federico for Document-centric GNOME [1].
[1] http://www.gnome.org/~federico/docs/2008-GUADEC/html/img36.html
As you say, this has the seeds of great awesomeness. When in doubt, go for awesome :)
The old theme format had an important goal to avoid compromising UI behavior due to themability. All previous WMs had issues where themes did not usually support things like changing titlebar font size, different window types, window states, and button types. (See the theme previewer app for many of the cases).
Another objective of the theme format was to disallow themes from changing behavior (e.g. which buttons to have had to be a preference or a function of window type or something, but the theme isn’t supposed to mess with interaction possibilities, only with visual style).
A third objective was to keep themes data-only to allow a GUI theme editor and prevent theme engines from crashing the WM.
I don’t think just saying “SVG” is really an answer … you couldn’t just say “this SVG file is now a WM theme” … presumably SVG means you can use SVG where the current format allows “draw commands,” which could work fine, though it’s probably as you say a lot heavier than the current approach. librsvg is not super lightweight afaik, neither is libxml.
Havoc: It’s interesting to hear about some of the rationale behind the old format– thank you. (We should probably write some of this down in doc/ somewhere.) I think preserving separation of concerns as you say is a very important issue. You certainly can’t go straight from an SVG picture of a window to a theme, no.
There’s a few other problems I didn’t mention already with the SVG idea, including, I think, the need to vet the SVG on the fly to make sure it’s not attempting to call home over http.
Jared: I think it would, yes. (We should ask Federico whether it’s quite what he meant, though.)
Hi,
About point 1., something may be done at fd.o level in order to have feature such as Tango experiment. Anyway, i actually don’t want any programm to paint it’s own window border, this should always be something shared. But where in the stack (WM or toolkit ?) that’s a good question. Which piece of the stack know the most about the window ?
Regards,
Étienne.
Moving window decorations to the client side is very clearly the right direction for a number of reasons.
– Much more flexibility wrt. visual style
– Reparenting causes all sorts of pain for compositing managers
– Applications can manage the backing pixmap themselves instead of relying on the X server
The supposed downside is that window decorations would look different across toolkits, but that is actually an advantage because it would indicate that the controls in the window will behave differently. (Until someone “integrates” the visual styles, that is).
#1 sounds compelling even if it is done as an experiment by the means of a gtk module. Then (correct me if I’m wrong) metacity could detect apps where the module is loaded and refrain from drawing any borders.
And as Étienne said – the app shouldn’t be able to directly alter the way the chrome is presented. It should be handled internally by the toolkit.
There’s a potential downside to #1. There will be virtually no intuitive way to kill an unresponsive application.
patrys: You raise an important point, and one I don’t have an answer to. Whoever it was who first raised the idea on IRC suggested this because of Cocoa, though; is it possible (other than through Apple’s task manager) to kill unresponsive apps in OS X, and is this a tradeoff which is worth having?
(Of course even now we can only kill local apps, though for most people these days that’s most of them.)
Thomas:
I think it could be solved by giving the System Monitor app more exposure in the UI. Currently it’s just one of many icons in the Applications → System Tools and many users fail to discover it (what constitutes a “System”? whatever it is, to a user it sound pretty much outside of her daily usage scope)
patrys: I think System Monitor should have more exposure, but one problem currently with it is that if you are going to kill an app you have to know it’s name. I think it should somehow communicate with the WM and have the possibility to kill application by window-name.
Xake: There’s actually nothing difficult in any program talking to X and finding out the name of a window. The trouble is that windows aren’t applications. Newer applications do mark their windows with their process ID, which means the WM can kill them given a window, as Metacity offers to when an application doesn’t close a window within a certain amount of time. But this is going from process ID to window name, which is a different challenge– though not an impossible one.
patrys: It would still be possible to kill it using the window list at the bottom, or am I missing something here?
Robin: and you always get the chance to kill it using the system monitor. The problem is finding the option.
No idea how feasible it is, but perhaps Metacity themes could produce GTK composite widgets. They take some common expected data inputs (Title, subtitle, application name, icon, close / minimize / maximize) and are expected to present them… somehow. This would basically remove the job of decoration from Metacity, as would be good, because decoration is completely out of scope from window management! Maybe Glade with a little information file to tie things together could do it.
This way, a GTK application could theoretically know the language to talk, and thus have deeper access to produce those Tango window experiment goodies out of the existing shell from the window theme engine. Legacy apps remain perfectly content without knowing or caring about those goodies. GTK apps elsewhere don’t die. New apps would be able to place their menus, toolbars or other things inside containers provided by the theme engine.
This would spare the users complaining about “free choice” and whatnot when they wake up and find the power to change the window titles independent from GTK themes missing.
Having rambled so, my thought on implementing the beautiful Tango window stuff is usually more along the lines of having a lot of stock GTK containers for developers to choose from for toplevels, each suiting different tasks… which fits with the idea of Metacity being blank but, as mentioned, does not fix everything.
I do think it is very important that controlling windows globally is always doable, rather than the ability to drag or resize a window being left at the mercy of whether its host process can be bothered to update the necessary details. (See MS Windows on a bad day for an example). May be worth looking at Matchbox’s code for free window movement, which lets me drag a window whenever the associated events are not otherwise caught.
Thanks for looking into this stuff! It makes me happy to know that the Metacity folks are indeed sane, and think about the Tango project’s mockup to boot :)
It’s a source of “Oh shiny”, but also potentially a way to better integrate file management. Look at the window icon, for example, which is often representing a file. Instead of it just being a useless window decoration, it can be a real widget known and understood by the program. With that, we can do some neat stuff. For example, produce a library that abstracts the idea of displaying a file, centred around GTK widgets, and magically have it used everywhere. *Boom* ugly file management begone, because every application that deals with anything resembling a file creates that same widget, working just like the file’s icon in Nautilus.
Still arguably just bling, but this is the stuff of Hollywood computing… and they can sure be productive in those movies, so they must do something right!
One thing I have been looking for, and don’t know if this is possible now, or whether it would require other changes (like those listed here) is to be able to have separate windows decorations for each application.
For example, I’d love for the color of the decorations on root terminals to be red (while the regular windows remain, say blue.)
Another example would be to have a dark window decoration theme (to match a dark GTK+ theme) for Gimp, as to be unobtrusive.
I know that you can have per-application GTK+ themes, it would be nice for Metacity to have the same functionality.
Ken:
One thing I have been looking for, and don’t know if this is possible now, or whether it would require other changes (like those listed here) is to be able to have separate windows decorations for each application.
It’s not possible now (at least, I’m pretty sure it doesn’t at the moment simply because the theme class is singleton), although there’s no technical reason why it shouldn’t happen. I’m not sure how people would control it in practice, though (perhaps they would set an environment variable which GTK would pick up and set a property on each window of _METACITY_THEME or something? It seems kind of clunky.)
For example, I’d love for the color of the decorations on root terminals to be red (while the regular windows remain, say blue.)
Funnily enough, someone suggested exactly the same a few months ago— it’s quite doable too, but not a high priority (though patches are always considered, and help to write them available as much as I can).
I really like the concept of the tango-experiment linked and would love it if it would be doable via an svg-system. SVGs might have the disadvantage of speed, but for me the advantages the svg format holds overall outweigh the speed-matter.
For “should meta-city do anything”, well, only where it must, I suppose.
Having a fast way to do all the basic instructions that the decoration provides currently is of course necessary, though I don’t see a reason to have that functionality stay in the decoration of the window itself.
There’s basically the same instruction-set accessible through the window-list applet, which should, just like the decorations currently, be visible at all times and thus make a good target to put the controls onto.
Something like this -> http://img296.imageshack.us/img296/6408/exampletg6.png (imagine a ‘move’ button next to minimize… forgot to add it)
They could be shown by hovering over the button or constantly (only for the currently active one).
Looking at the problem that there’s many users who use docks instead of the window list, it might be necessary to introduce a ‘fast window control’ applet that gives the four buttons (move/minimize/maximize/close) a home on the panel.
I don’t like the idea of giving more exposure to the system monitor since it would give even more of a ‘you got to know all the tech’-feeling to new people, but a more user-friendly tab displaying the window-names would indeed be nice. Though in the end it would be just another “window list”.
Overall the prospect of removing the current way a decoration is displayed sounds promising, integrating functionality of the tango-window-experiment link would definitely create higher customization possibilities. The aim of getting more space on the screen for production instead of ‘useless’ decorations should definitely be the way to go. Those extra-pixels can be the line between usability-dream and -horror, at least if one doesn’t have the money to spend on a new monitor just because some programs and/or webpages aren’t usable otherwise.
Well, I guess that concludes my ramblings on out-sourcing the duties of the window-decoration.