Future directions of Cowbell

Future directions. Here’s where Cowbell is going next:

1. The existing functionality is going to be moved into a library called libcowbell.  Very little will be changed at this point from what we already have.  (But there will be some extra tests.)
2. A release of the metacity-cowbell branch will be made that can use libcowbell.
3. A release of real Metacity will be made that can use either libcowbell or conventional themes.
4. Development of libcowbell can continue.  (I expect pseudoclasses to be among the first things added.)

More more cowbell. Iain has pointed out an existing GNOME-based project called cowbell.  I hope the fact that this project will be libcowbell will be enough to avoid confusion.

Feedback on feedback. Screwtape has reviewed the existing cowbell documentation in a web page here.  Here is my feedback on the feedback:

• §3: I did start out by showing the structure as pseudo-XML, but people commented as if the window borders were the result of rendering that XML (as if it were XUL, or something similar), so I think it may be misleading.
• §3: I dithered over using the ID or a class for this sort of thing for quite a while.  In the end I went with a class because we use classes for buttons (since they may repeat) and it seemed as well to use the same design for areas, and because you may have more than one content area visible at once, even if they are on separate windows.  But I may have been wrong, and I invite opposing opinions.
• §3: buttongroup: I really like this idea.  But AFAIK libccss doesn’t yet support last-child etc (see next…)
• §3.1: I want our CSS support to be up to level 3 wherever possible.  However, we are constrained partly by what libccss is currently capable of.  Of course we can patch libccss too!  Backgrounds and Borders is largely supported by libccss, though.
• §3.2: Unpainted areas are transparent (though if the frame is opaque, you’ll just see the frame through them).
• §3.3: font-size is important; what should the interaction be between the font size set in Metacity gconf and the font size in the theme?  Just use the theme font size for scaling as in v2?
• §3.3: button heights: I think I didn’t explain myself properly here.  You can (should) set height and width on buttons.  But these only serve to establish an aspect ratio.  The height is always calculated from the titlebar height at present.  Perhaps this is overly confusing.
• §3.5: :focus pseudoclass: perhaps this should be set on all elements in a focused window.  Or perhaps just the frame and we can use the descendant selector.
• §3.5: :disabled — hadn’t thought of this, good idea.  TMTOWTDI.
• §3.5: I’m not sure libccss supports :not() (but maybe it does!)  If so, yes, we should use it.  It’s far better to work the way people expect us to work.
• §3.7: I hope we support SVG too.  It would be extra nice if it could be styled with the same CSS somehow.
• §3.8: I really want mm and em as well as px.  I’m not certain libccss knows how to do this, but I will check.
• §4: Nobody’s really tried to put Dublin Core data in CSS before, and I’m probably not doing it the best way.  I worry that including a required custom XML file will be slipping back into using custom formats, though.  Maybe we should use an @rule.  Or specially-formatted comments.  Or maybe we should give up on the whole required metadata idea.
• §4: I like the idea of specifying alternative stylesheets, though metadata in the stylesheets themselves could also do this.
• §6.1: yes, we really need a default stylesheet.  I’m not sure what should go into it.  I will think about this and include it in the first libcowbell release.
• §6.2: okay, we’ll avoid data: URLs.
• §6.2: let’s implement the single file doctrine by allowing any file in ~/.themes/ThemeName/cowbell/ThemeName.tar to be treated as if it was in ~/.themes/ThemeName/cowbell/.  I think we can get that in the first libcowbell release too.
• §6.5: I really like Firebug.  Are you thinking we could use Firebug itself, or just copy its UI?
• §6.11: Maybe we could also modify hue/saturation/value directly in the URL thus: url(‘file:fred.png?hue=#f00’)?
• §6.13: I was thinking of themes which, say, repeat a pattern an integral number of times on the otherwise empty part of the titlebar, scaled to fit; this wouldn’t be possible using border-images, but would work fine with filler.  On the other hand, perhaps this is overkill.

Feedback from everyone reading this, on the above and on the original document, is very welcome.

Maybe we need to take over a little piece of live.gnome.org to hash all this out.  Or maybe we need a mailing list.  I’ll wikify all this tonight and then post about it here.

Photo © Honza Soukup, cc-by.