Future directions of Cowbell

November 4, 2009 – 10:50 am

Traffic signsFuture 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.

By Thomas Thurman | Posted in CSS themes, Letters, Metacity Labs | Comments (3)

Future directions for Cowbell

October 30, 2009 – 7:56 pm

55 femöringar - five-öre coinsI believe the best direction in the immediate future for Cowbell is as follows:

  1. Fix the :hover and :active pseudoclasses.
  2. Add support for v2 themes back in.
  3. Provide a patch for Mutter.
  4. Port some more themes, such as Crux.

Anyone wishing to advocate for anything else on the future directions list to come sooner is welcome to make their point, however.

Please let me know if you’re testing Cowbell, or if you’re interested in it. whether or not you’re working on new themes.  I’d like to keep the Cowbell community cohesive.

Photo © Eva the Weaver, cc-by-nc-sa.

By Thomas Thurman | Posted in CSS themes | Comments (2)

The Sunshine theme

October 29, 2009 – 11:52 pm

In order to demonstrate Cowbell more adequately, I asked Firinel to help design a new and simple theme. The result was Sunshine.

In order to test Cowbell, you will need to download Sunshine.  Then follow the instructions in the README to unpack it into your ~/.themes directory.  The tarball also includes a copy of Crux, so that you can share GConf settings between desktop Metacity and Metacity-with-Cowbell running in a Xephyr window.

I hope this new CSS theme is the first of many.

By Thomas Thurman | Posted in Themes | Comments (1)

CSS on window borders experimental layout language

October 29, 2009 – 8:31 pm

cowbellI’m happy to announce the first experimental version of Metacity with support for CSS window borders (”Cowbell”).  This work was largely supported by Collabora Ltd.

You can:

This diagram should explain everything, perhaps.

I would especially like to hear from:

  • theme artists, to let me know whether it’s adequately powerful;
  • anyone else interested in hacking on this with me;
  • the GTK client-side decoration people, so that we can harmonise the way we represent things;
  • people who know a lot about CSS and can offer insights into the suitability of the way we represent things;
  • people who know a lot about the Dublin Core and can offer insights into whether our metadata system uses it appropriately;
  • maintainers of other window managers (especially Mutter), so we can talk about including CSS support in other window managers;
  • everyone else, to suggest which of the directions for future development are most interesting.

I think it may perhaps be helpful to set up a Cowbell mailing list, so that we can compare notes on implementations.  For example, I haven’t written down anywhere how to place an image to the right of the title, which is commonly needed (you use border-image).

Photo © Craft*ology, cc-by-nc.

By Thomas Thurman | Posted in CSS themes | Comments (6)

Now with more cowbell

October 21, 2009 – 3:54 pm

I posted a while ago about a system to represent window border styles in CSS. Well, once we had a workable system sorted out, it was time to add the support to a window manager. So I’ve recently been working on adding CSS support to Metacity. The most fiddly part so far has been getting the window geometry calculations right, rather than actually rendering anything.

On the right you can see the Human theme rendered using CSS, and below it the result of adding a blue border to the CSS.

Clearly I still need to fix:

  • text rendering
  • getting the rounded corners on the physical window and the corners rendered in CSS the same

but I believe it won’t take more than a few days to get this to a state where other people can happily play with it.

Meanwhile, you can follow the work in the “cowbell” branch in git, or on the project’s home page (which will eventually have more interesting content).

Special thanks go to Collabora, who supported this project and let me do some of it on work time.

By Thomas Thurman | Posted in CSS themes | Comments (0)

Apologia for CSS

July 20, 2009 – 7:05 pm

2000 two penceThis blog is not about to become devoted to the single topic of experimental CSS theming, but some interesting points were raised in the discussion yesterday, which spilled over to Slashdot.  We should have emphasised the experimental nature of the CSS subsystem in its name: perhaps “CSS On Window Borders Experimental Layout Language”.

Why? Some people have asked why anyone should be interested in CSS theming, given the existence of a stable and mature theme description format.  The answer is that there are perhaps a couple of hundred people in the world who understand the Metacity theme format, and its complexity presents a significant barrier to entry for anyone else attempting to learn it.  By contrast, millions upon millions of people have a basic understanding of CSS.

Efficiency. Some have pointed out that using CSS may cause great increase in memory footprint or execution time. Both of these are of primary importance to us. Furthermore, we know just how fast every theme renders using the standard engine. We are not prepared to introduce a new theme engine unless it is at least as efficient as the old one.

Mismatch. Some complain that the lists we gave of things we would need to ignore and things which would need to be added proved that there was a mismatch between CSS and what was needed.  This is based on a misunderstanding of CSS as a language to style HTML.  In fact CSS is a general-purpose styling language, and there are only a few places where it does not quite meet our needs.  Even in those places the design is flexible enough to accommodate us.

The balance of power. Ray asked whether the structure of the window should be under theme control, as well as the styling. Some ask how we decide what is under the control of the CSS.  We always need to find a balance between giving power to themes and giving power to users. Some things should be under theme control and some under user control, but it’s not trivial to decide which. Here are some examples:

  • Justification of the text on the titlebar. Currently this is entirely under theme control; the user can’t change it. Some people would like this to change.
  • The arrangement of buttons on the titlebar: which are on the left, which are on the right, and which aren’t shown at all. This is currently entirely under user control; the theme can’t change it. (This means that themes which attempt to look like OS X have to ask you to reorder your buttons so that close is on the left, since they can’t do it themselves.)
  • The font on the titlebar. Currently this is entirely under user control; the theme can’t change it. This among other things is something we’d need to reexamine with a CSS theming engine.

(”Under user control” means set in GConf and, generally, modifiable in the control panel.  Some of these options cannot be set in the control panel at present, but that’s a separate problem.)

It may be true that windows should have a more flexible structure, and the ability to have the titlebar elsewhere is certainly something that’s been asked for from time to time. But assuming we should add such abilities, should the decision to use them be made by the theme, or should it be something selectable by the user in the control panel? These are deep questions.

Co-operation with GTK CSS theming. Yes: a good idea.  Whatever they’re doing, we should probably try to share in it.

Complexity. Some have said that CSS is a complex system, and that anything implementing it will therefore also be complex and difficult to implement.  This is an unwarranted assumption.  Take a look at the table of contents of the CSS specification and see how little of it actually applies to a fully-functional system for description of window borders:

  • Syntax and basic data types; Selectors; Assigning property values, Cascading, and Inheritance; Media types:  all handled for us already by libcroco.
  • Box model: we would need to implement this.  Not terribly complex because we have a simple and unchangeable layout model.
  • Visual formatting model; Visual effects: these are complex, and we can ignore them entirely, since our layout needs are simple and unchangeable.
  • Generated content, automatic numbering, and lists: we would need to implement basic generated content (the easy part); we have no content to be numbered, and no lists.
  • Paged media: does not apply to us.
  • Colors and Backgrounds: the most complex part which we would need to implement.
  • Fonts; Text: partially applies to us (since some of it isn’t theme-controlled); mostly involves passing things into Pango.
  • Tables: doesn’t apply to us; we have no tables.
  • User interface: this is about setting cursors and things, and doesn’t apply to us.

Finally, we should probably reiterate that:

  • this is still an experiment, and not an official direction which Metacity is taking;
  • even if it ever happens, there’s certainly no decision to use WebKit.

Photo © johninbkk, cc-by.

By Thomas Thurman | Posted in CSS themes, Letters, Metacity Labs | Comments (4)

Recent happenings in Metacity and Mutter

July 19, 2009 – 1:27 am

Mother and ChildHere’s a quick round-up of interesting goings-on in the Metacity and Mutter worlds this week.

Photo © Tiara, cc-by-nc-sa.

By Thomas Thurman | Posted in Mutter, journal | Comments (2)

More CSS thoughts

July 18, 2009 – 11:17 pm

Call... (4 of 4) [2007 - Day 174 - Edge]The recent discussion about CSS themes looks as though it may become one of the most interesting new ideas in theming in recent years. Here are some further thoughts on what may evolve from this.

An alternative. There is no general way, and few special ways, to convert expression-based v1 and v2 themes to the hypothetical box-based CSS themes.  Therefore this would need to be an alternative theming system, without any upgrade path leading to it.

Document structure. CSS exists to style documents.  In our case the document is purely notional rather than existing somewhere as a file, so we have great leeway in its representation.  As I mentioned earlier, there are multiple ways in which we can use the ideas of element name, ID, and class to represent what we want to do.  The guiding principle is not what would be easiest to implement but what would cause least astonishment to new theme authors.  After some thought, I think such a layout might look like this:

<frame class=”maximized”>
<area class=”titlebar”>
 <button class=”menu”/> <!– possibly others –>
<title/>
<button class=”minimize”/>
<button class=”maximize”/>
<button class=”close”/> <!– possibly others –>
</area>
<area class=”content“/>
</frame>

  • Feel free to disagree and to come up with alternatives.
  • There are no attributes on any element.  Attempts to select on attributes will fail.  The class is written as an attribute only for notational convenience: hence the italics.
  • Class is used instead of identifier because it’s not impossible that some implementation of this scheme will wish to have multiple buttons with the same function on a frame.

CSS3. Almost everything we already have can be represented in CSS level 2, and there is no immediate need for level 3.  The sticking point mentioned earlier was the window icon being part of the title in Atlanta.  However, this can be implemented in CSS2 as follows:

title:before {
content: url("metacity:icon");
}

where metacity:icon is a magic URL which returns the current application icon.  (But it might be wise not to use the name “Metacity” in this format, in case other window managers might like to use it; that goes for vendor-specific extensions, too.  Maybe we should use -wm-.)  That said, I am salivating over the possibilities of the new round attribute to background-repeat.

However, there is one piece of level 3 we absolutely need: we will need to allow border-radius at least on the frame, if not on the subsidiary elements.

Implementation. A format is independent of implementations, of course, but we need at least one implementation in order to test things. There have been a few possible implementations suggested:

  • webkit. This would work and reuse a lot of code, but I’m a little wary of embedding a web browser into the window manager.
  • nbtk. This seems to be missing a lot of what we need at present.
  • libccss. This has more of what we need, but still there’s a lot left open to us to implement, and a lot of what it implements we don’t need.  It also doesn’t allow us to define new colours, which we need, and appears not to implement sibling selectors, which we will probably also need.
  • Using libcroco for parsing and cascading and building the rest ourselves. This is slightly more work than using nbtk or libccss, but may be necessary because of the particularly specialised nature of what we are doing here.

Justification. One of the things people seem very keen on is how the window title is justified.  In the box model, the correct way to do this is with the auto keyword on the padding or margins of the title, and not using a text-justify declaration (since the title only has one line of text which fits snugly in its own content box).  However, since people are bound to try to use text-justify anyway, perhaps we should allow them to do so, and merely interpret it as another way of setting the padding.

Things we need to implement: The whole box model; several kinds of border pattern; basic generated content for the title; various kinds of text styling for the title; ability to use pseudoclasses to prelight and press buttons.

Things we should ignore: Padding on the frame.  Height and width set on the frame, or the content box.  Perhaps: Any theme without proper metadata.  If we’re doing things the same way as in v2, the font-family, font-weight, and font-style set for the title.  (Or should we allow themes to specify a font?)  Should we give a warning if a theme attempts to use anything we don’t support?

Photo © Jonathan W, cc-by-nc-nd.

By Thomas Thurman | Posted in CSS themes, Thought experiments | Comments (14)

The wider world of window border themes

July 16, 2009 – 5:26 pm

Pacific Highway crossingAfter all this talk about theme formats, an overview of how they are handled in other window managers seemed in order. Your chronicler is no expert on most of these systems, so there may well be mistakes below.

Feel free to add more in comments.

(And then of course there are two examples from outside the free desktop, which are so large they are easy to miss:

  • OS X does not generally allow theming;
  • MS Windows only allows very basic theming and no redefinition of window borders.

One reader contacted your chronicler offline to ask whether a theme editor, and indeed customisable themes, were not a white elephant, considering that most users of most computers in the world have no ability, and perhaps also no desire, to remodel their window borders.)

Conclusions:

  • Most environments do not allow anything beyond very basic theming.
  • Most of the other window managers rely either on pixmap theming or express their themes using a programming language.  The middle ground of using vector graphics is unknown outside Metacity.  (Of course, in the world of gnome-shell, we could always express themes in JavaScript, but expressing themes in code brings a whole raft of security implications of its own.)
  • Nobody uses external standards such as CSS or SVG, except insofar as programming languages are external standards.

Photo © scazon, cc-by.

By Thomas Thurman | Posted in Themes, overview | Comments (7)

Further thoughts on extending the window menu

July 16, 2009 – 1:06 am

alpine strawberryThe 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.

By Thomas Thurman | Posted in Thought experiments, Tools, nargery | Comments (7)

Bad Behavior has blocked 192 access attempts in the last 7 days.

Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported.