Bug of the day: hiding “(as superuser)”

sulking HulkAs we mentioned the other day, there are some situations where Metacity’s ability to mark a window as running as root is unhelpful. One of these is during installation: this naturally runs as root, but it baffles new users to be told “Install (as superuser)“.

For this reason, GNOME bug 605137 requests a hint which can be added to a window to suppress this message.

Thomas has implemented this as the hint _METACITY_HIDE_USERNAME, and there is also a test case.

This patch may also be of use to other distributions, assuming we keep the “(as superuser)” ability at all– see GNOME bug 609431.  It may not necessarily go into the master branch, unless it would be useful to other people.  If it doesn’t, perhaps it can be a distro patch.

Photo © Sharyn Morrow, cc-by-nc-nd.

Bug of the day

Ladybird, ladybirdThere are several hundred bugs still open in the Metacity bug tracker.  Over a hundred of these are enhancement requests.

During the first quarter of last year, this blog ran a daily “bug of the day” or “squib of the day” feature, where suggested enhancements would be discussed.  Every so often, there’d be a roundup post where the fate of the bugs of the previous few weeks was revisited.  The idea was that decisions could be made in the open rather than behind closed doors.

That was all very well, and it got the community more involved in discussing new features.  However, there were two main problems:

  1. Enhancement bugs are probably the least important kind of bug, and yet they’re the most interesting to write about.  So this plan focused people’s attention on the least important things.
  2. There’s only a few people who are willing to hack on Metacity, and they only have a certain amount of time available to do it.  This plan meant that more time was spent writing blog posts than writing patches.

It might be useful to resurrect this feature, but not unless these two issues were addressed.  Perhaps we should extend it to covering all kinds of bugs in order of priority, and instead of having daily posts have a strict rule that nothing new could be posted until the previous bug had been dealt with.  Perhaps your chronicler should also delegate writing the posts, if some willing amanuensis could be found.

Photo © wiccked, cc-by-nc-nd.

“(as superuser)” considered harmful

It's not easy to be a superheroAbout a year ago, we considered the idea of showing the name of the user running a program in the titlebar, as suggested by GNOME bug 549389.  So if you were running Epiphany as user fred, and you yourself were not user fred, you would see “(as fred)” in the titlebar.  More commonly, if you were running Nautilus as root, you would see “(as superuser)” in the titlebar.

This eventually made its way to being commited to the master branch.

Various problems have since arisen:

  • Several people still say that it should say “as root” instead of “as superuser”.  The wording was chosen for fear that “root” was techspeak, but apparently “superuser” is as well.
  • gvim is somehow able to fool the user detection and displays “as superuser” even when it’s not.  Your chronicler suspects the EWMH properties are misapplied, but has not yet investigated.  This is Debian bug 549290, Gentoo bug 292517, and GNOME bug 603240.
  • Colin Watson has asked in GNOME bug 605137 for a way to suppress the message on particular windows, because the Ubuntu installer runs as root under Metacity, and the user doesn’t need to be worried about the “as superuser” part.  This is certainly something we can do, assuming we keep this feature at all.
  • Launchpad bug 519035 (which is GNOME bug 609431) says that any attempt to mark the titles of windows owned by root is “techspeak and ineffectual”.

We could:

  • keep things as they are
  • rename “(as superuser)” to “(as root)”
  • remove all visual indication that a window is running as root, but leave it in for running as other unexpected users
  • remove the patch entirely
  • replace the patch entirely with a way for themes to specify a titlebar style for windows running as root; this was GNOME bug 505157 and wouldn’t be very difficult with CSS themes (“frame[is-root] > titlebar { background-color: blue; }“).

Gentle reader, your opinions are welcome.

Photo © Esparta, cc-by.

Specifying button widths in CSS

The height of a button in a CSS theme is determined by the height of the titlebar, which in turn is determined in most cases by the height of the titlebar font, but occasionally explicitly.  The height of buttons cannot be set explicitly.

For the width of the button, however, there are two common cases:

  • The artist wants it to be a specified number of pixels, millimetres, ems, etc.
  • Much more often, the artist wants it to be a specified multiple of the button’s height, often 1:1.

There has been some controversy about how we should represent this in CSS:

  • In the first draft of the themes specification, the width and height properties could be set on a button, but were only used to calculate the ratio.  Explicit widths could be set using max-width and min-width.  Screwtape called this abuse of the semantics “a bit cruel”.
  • We could honour width directly for absolute values, but then there comes the question of how to handle ratios.  If you set the width to a percentage, we could use that, but traditionally that has meant a percentage of the width of the enclosing element, not of the height.  We could make an exception in this case, of course.
  • The universal solution of width: -cowbell-button-ratio(0.25), or whatever, which is ugly.
  • Or alternatively allow width to be set directly for absolute widths, and as an alternative have -cowbell-width-ratio: 0.25.
  • Invent a new unit!  width: 0.25ht.  This idea should probably be avoided.

Your chronicler is stumped as to the solution which would be clearest to theme artists.  Gentle reader, do you have a suggestion?

Themes roundup

Here are four pieces of news from the world of theming.

  1. Human may be replaced. We don’t usually cover news about specific themes here (although perhaps we should) but it’s worth noting that Ubuntu’s default theme, Human, although very beautiful, is a little long in the tooth.  There has been a proposal to replace it in 10.4 Lucid Lynx with a new, similar theme called Homosapien.  (Your chronicler notes that the human species is homo sapiens sapiens, not *homo sapien, and wonders whether it is too late to change the name.)
  2. Universal theme format. At present, there are scores of different formats for theming user interfaces, some of which are often packaged together to be complementary or alternatives. There are also various metatheme formats for packaging several disparate types of theme together, but they are specific to a particular desktop. David D Lowe has proposed a “universal theme format”, which is a container for various types of themes, to be considered as a freedesktop.org standard. Time will tell whether it’s adopted, but for the moment, gentle reader, you can find out the details in this PDF (there is no HTML version, unfortunately).
  3. The state of Cowbell. Speaking of universal theme formats, Cowbell is an attempt to allow theming using CSS rather than Metacity’s own rather recondite theme format, which may hopefully one day be picked up by other window managers.  More work has been done on the cowbell branch than has seen the light of day, but it has proved difficult to merge the existing content with the master branch; furthermore, we should probably be looking at keeping the CSS theme code separate in a library so that other window managers can use it as well.  So the branch has been quiet recently.  There are plans to forge ahead with what we have, however, and to integrate the results of the detailed discussion on the subject at the end of last year.
  4. Cowbell and its dependencies. There are several ways in which the current libccss-based implementation falls short of what we need, at least last time we checked. Any or all of these apparent problems may be mistaken, but:
    • Several of the CSS3 selectors which would be really useful weren’t implemented, even things like sibling selectors.
    • There’s also a lot of flexibility we don’t need, since our “documents” are of a fixed form.
    • There’s apparently no way to refer to a window’s icon other than by saving it as a bitmap and reloading it.
    • Some of the extensions we’d need to have equivalent power to the v2 theme system, such as -cowbell-replace-color, look like they’d be a nightmare to implement for similar reasons.
    • We can’t easily implement the requirement that it should be possible to load images from a tarball, for similar reasons.
    • We can’t easily add new colours, which we’d need to to implement system colours (which may be deprecated but suit our purpose very well), or any similar way of getting at the GTK colours.

    We could work around these, but it’s far better to make the theme format usable by humans than to tie ourselves in knots to get around infelicities in the software.  And we always have the option of adapting libccss to our needs.  But a lot of what we need to do is specific to our own case, and if this results in tying the library in knots it may become better to write a stripped-down in-house CSS parser that does what we want and is, as they used to say in Cambridge in the old days, BALGE: by and large good enough.

Gentle reader, we love your letters.  Let us know your news, whether or not it’s about themes.

Photo © camera_obscura, cc-by-nc.

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