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.

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).

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.

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!