GNOME bug 102548 suggests that warning dialogues should have a special frame style, and it’s suggested that this could look like safety tape wrapped around the edge.
This is not unlike the special frame style suggested here for root windows. However, while there’s already a way for the window manager to tell whether a window belongs to the superuser, there’s currently no way to tell whether a window is a warning, so this would need a change made to the EWMH and then need all the toolkits fixing to use it. It’s thus rather nontrivial, although it may still be worth it if it helps users.
Because this requires a change to the theme format, it must be committed first on a branch.
I am seriously entertaining the idea of doing away with the window and frame_style_set tags in v3 of the format, and just using tags on frame styles such as maximized, shaded, focused, unfocused, root, warning, modal, and so on, with some well-defined and intuitive rule about how to break ties:
<frame_style geometry="foo" tags="border focused maximized">
<piece position="title"> ...
Photo © Robin Gallagher, cc-by.
I like the idea of tag sets instead of a complicated hierarchy of tag-references, but figuring out a suitably “well-defined and intuitive rule” for fallback would be the crux of the thing. As I mentioned my a comment on the “policy about theme versions” post, well-defined and intuitive fallback is probably the most useful thing in a new theming format.
I think you’d still need frame_style_set elements, you might want a particular frame_style to be used for two or more disjoint sets of tags.
The more I think about this, the more I remember that a bunch of clever people have already done the hard work of designing a language for composing visual styles from least to most specific: CSS. Rather than matching elements, you’d match pieces; you could use psuedo-element syntax to match states, class syntax to distinguish buttons by location and ID syntax to distinguish buttons by type… something like this:
window:active:maximized title_bar {
/* Styles the title-bar in a focussed, maximized
* window
*/
padding: 2px;
}
dialog:active:resizable(X,Y) #close_button:hover {
/* Draws the close_button in the prelight state on a
* focussed dialog that is resizable both
* horizontally and vertically.
*/
draw: url(“#draw_close_glyph_prelight”);
}
modal_dialog .left_button {
/* Sets the inter-button spacing for buttons that
* appear on the left-hand side of the title bar
* of a modal dialog.
*/
/* I would imagine that unlike HTML, margins would
* only be relevant on button elements, and margins
* would collapse horizontally (rather than
* vertically)
*/
margin: 0 5px;
}
I can think of a couple of problems with this model, of course – firstly, there’s no good way to express draw_ops elements in CSS syntax. This could be addressed by having themes be XML documents containing a style element for the CSS as well as a collection of draw_ops elements with id attributes, and the CSS could refer to draw_ops with “draw: url(#draw_dialog_border);”.
Another problem that springs to mind is that ideally the CSS styles would handle both drawing and layout; that is, they would subsume the current frame_geometry and frame_style elements with “padding” and “margin” and “draw” styles. This might be so radically different from Metacity’s internals as to ruin any chance of implementation.
Lastly, CSS is not a perfect syntax – there are any number of proposals for improving it. Most of those don’t really apply here, because the “document model” for windows is vastly simpler and more static than for HTML, and the most practical need in standard CSS is for colour and size constants – which we cleverly side-step by keeping draw_ops in their XML syntax and re-using Metacity’s existing constant system.
Hmm… that was a lot of typing. Should I file that as an enhancement bug?