Today is my last day working for Novell. They say we shouldn’t focus on the past, but I do have to look back a little.

Novell has allowed me to take part in some really awesome projects. Going back to Ximian, I was lucky to be part of the Linux desktop revolution (this year will totally be the year!). I helped to shape the aesthetics of Novell Linux Desktop, SUSE Linux Enterprise, openSUSE and most importantly SUSE Studio.

I won’t forget Novell for making many opensource projects such as Evolution, Mono, F-Spot, Banshee, Tango and many others possible.

Some really good stuff is about to happen with Studio, but for obvious reasons can’t spoil it by telling you. Soon SUSE Meego will bring what I think is the best netbook ui design to a wider audience and the last openSUSE I was involved in, 11.2, will come out in just a few days.

I will also miss the upcoming hackweek, which is something I recommend to any company. People will do awesome things for you if you let them do their little pet project. I would never be brave enough to dive into type design if it wasn’t for hackweek.

As for what I’m up to, stay tuned for an upcoming entry

It was almost 9 years ago when the first ever scalable icon theme Gorilla came to be. One of the things I imagined to happen soon after was that the icon theme would inherit the colors from the widget theme to really feel integrated. That part never happened. Until now. But this time it’s not for the default theme and not because of visual integration. In fact, with 2.30 we seemingly stepped back from SVG and started using bitmaps when we introduced the high resolution icons.

While we work hard on filling the gaps in the highly detailed, colorful gnome-icon-theme, on behalf of the gnome-art team I have proposed a new module for inclusion in GNOME, gnome-icon-theme-symbolic.

International symbol of marriage.

Unlike the default theme, the icons don’t scream with color and don’t become Times Square when few of them stay persistent on your panel. The simple symbols are mostly monochrome but in some cases they may include some color to emphasize importance. Unlike the Tango style or high contrast theme, the icons don’t include stroke tricks to make them legible on any background. Instead, the icons’ contrast is achieved the same way as it is done for text. The icons are simply rendered with the foreground color in the context of the widget where they are drawn in. Bastien has summed up the details of the implementation in his recent post.

The icon set isn’t an actual theme, it just extends gnome-icon-theme. It relies on the index.theme of gnome-icon-theme (or will). The reason why the icons live in a separate module is that we use a slightly different way to manage and “build” them. The complete theme lives in a single SVG plate (icons are outside of the canvas, try Inkscape). We then crop the plate into individual icons that are saved as plain SVGs (right after bug #419266 gets fixed that is . Sadly we do that using Inkscape’s verbs so the process is dead slow and pops up Inkscape windows while you’re trying be productive. But still the benefit of having the whole theme on one canvas is worth some pain.

Gtk+ then doesn’t actually load the icons directly, but they are wrapped in a gtk+ generated xml container that includes a CSS stylesheet that overrides the colors.

Of course for future the simple style still opens up room to apply fancy renditions. Just by rendering the icon twice, we can get a small shadow for increased contrast. Similar technique, but inverted can be used to render insensitive state of a widget, etc. Another big area where these may prove extremely useful is accessibility. All of this can be done at runtime, no need to deal with two or more icon sets.

We discussed these “dynamic” icons years ago and it’s a really big moment for me to finally see this implemented. And I believe no other system does this. FOSS innovation FTW!

Big thanks to goes to Matthias Clasen and Bastien Nocera for making it happen!

Update: I realised after a while that for some reason recaptcha was broken on my site. Comments are working now again, sorry to those who lost time writing to /dev/null

Didn’t manage to write anything during the London UX hackfest as it felt more appropriate to steal some family time for that. Revitalizing, that’s what it was.

I haven’t had much time to focus on GNOME work lately. The people who made that work fun either moved on to other projects or suffered from the same lack of time. During the past week it was great to see many GNOMErs share the same design principles and being motivated to push things forward. My interest in gnome-shell shot up 1000% after talking to Jon & Jeremy.

The ever-cheerful thos walked me through the release process so I’ll be taking care of releasing gnome-icon-theme more often than we used to. 2.29.0 is out so people will finally start seeing the fruits of our long lasting labor.

The UI design sessions were awesome but we also got some visual design work done. I’ve talked to everyone about how necessary the widget-theme-color-aware symbolic icon style is and the reactions were overly positive. We’ve started on the essentials with Hylke and illustrated how these might fall in place for network manager for example:

We’ve also brainstormed some ideas for the window decoration and widget themes. Arstechnica has more details.

Big thanks to everyone making it happen. Check out the London set for more photos.

Oh no! This is one of those “Oops, I didn’t update this blog for ages” posts. Hopefully I’m not on the same path as my good old friend Tuomas. I’m blaming gwibber for making it so easy to nanoblog.

So what have I been up to lately? I’ve wandered back into font design land with Fifth Leg. Fixed things up a bit and generated & cleaned up a normal weight. Quite a bit of work went into it. So much that I even bravely released v 0.3. It goes well with the window decorations of Sonar, the upcoming openSUSE 11.2 theme. In the meantime I’m working on getting 0.4 out which will have some of the common kernings sorted out, improved ‘g’ and a few latin ligatures. I also dropped having old style numerals as default.

After reading the hilarious blog post by Mark Pilgrim I LOLed. But it also inspired me to start on a humanistic sans serif I’ll probably end up calling Mimicus. Currently it’s called RaveIn due to the type it’s been most inspired by.

The newly refurbished SUSE Studio website is using a condensed width of RaveIn. We’re using Cufon to render the type, but probably should support @font-face too. Hats off to Garrett for making it happen. Stay tuned for the initial font release later this year.

As you can see I haven’t been doing much icon design lately, but luckily the amazing Lapo Calamandrei has been doing great work on gnome-icon-theme in the meantime.

Again, apologies to my readers for having this blog rot a bit.

Stephane Delcroix of F-Spot fame has written a nice XCF loader for gdk-pixbuf so our GIMP files have become first class citizens in GNOME. Thanks dudie!

Federico mentions usability issues when trying to ban people from planets. I haven’t done any research, but personally think banning someone is a corner case functionality. I have never needed to do it on any of the planets I read.

What is striking to me when looking at the planets side by side though, is how unreadable the SUSE feed is. I can almost hear people say “but look how much information is shown on the right and you only see single post on the left”. Since when is packing as much text into an area a good thing? You will be scrolling in any case, and just look how long the lines on SUSE planet are. No padding for the paragraphs, everything crammed to the border which is also just noise as it doesn’t really separate the posts from one another. You cannot tell if the header isn’t a footer of the previous entry. Whitespace is a much better separator than lines/rectangles. And vertical logo? Yuck.

Feed banning may not be as convenient on planet gnome, but you can sure read it much more easily and it’s a pleasant view at that.

From time to time I get asked why has GNOME become so conservative when it comes to widget theming. I generally answer that’s a good thing and simply an effect of the default theme to have matured and becoming usable to the majority of users.

At the same time, you don’t see many designers interested in theming gtk+. Maybe due to the inefficiency of the theming functionality in gtk, or rather ignoring its target audience. Themes in gtk still lie on the shoulders of theme engine hackers. While there are exceptions to the rule, usually those are the people who have their ‘good enough’ limits in visual design set very low. To show this more clearly, those are the people who call this a rounded rectangle:

In addition they would not find addressing corner case situations where one needs to remove a 1px padding between certain elements worth their time. In summary they should NOT be working on widget themes. While the following seems to be a general knowledge, I haven’t seen anyone summarize what we are actually lacking in the field of gtk+ theming. Here’s my suggestions based on my theming experience.

• Drawing / box model. It should be possible to do some basic draw operations in a theme. A typical designer will be familiar with the web/CSS box model. From the theme it should be possible to draw a border, add a margin and padding to a widget/part, specify corner rounding solves most of the drawing needs if it’s accompanied by next item.
• Bitmaps. Most important is being able to use an image as a background. In addition to the CSS tiling and positioning, it would be beneficial to be able to stretch the bitmap to the size of the box/widget.
• Gradients. Drawing gradients as background/fill and box borders.
• Compositing. An extremely important feature would be to properly composite objects with alpha transparency. We should be allowed to use RGBA bitmaps, setting a global opacity of a box/widget and being able to use alpha transparency in gradients.
• Selectors.This one is slightly controversial, as the theming is already using a functional matching syntax, yet for a designer a CSS-like selectors would be much more understandable and approachable. With a tool described below, this may not be as important.
• Debugger. For a web designer, one word would sum it up — Firebug for widgets. Being able to visually select a widget on a window and be able to find it in the widget tree(?) and see its associated style properties would be a dream come true. A tool to help form efficient selectors. A tool to measure speed implications of certain operations.

And if somebody would like to rewrite theming from ground up, I would suggest form/functionality separation. Having actual layout and positioning functionality in the theming, it would stop being a pain to conform to the GNOME interface guidelines. Application developers would worry about what type of input widgets they would like to use, not how to indent labels or how many pixels is the suggested padding between X and Y.

Update: Turns our Rodney has touched the topic around 3 years ago. While I do refer to CSS a lot, I’m putting the basic drawing capabilities to theme authors in front of all the other items. Having an intermediate layer in the form of a specific theme engine as cimi mentions in the comments is a good-enough short term solution I guess.

So after finally getting the FLAC version of Ghost, I wondered if Banshee’s transparent transcoding would keep all the metadata intact and I could enjoy the album on my ipod too.

Sadly the codec situation did have to ruin my out-of-the-box euphoria. So to be of some aid to my fellow openSUSEists, here’s how.

openSUSE 10.3 doesn’t include the LAME mp3 encoder plugin in gstreamer010-plugins-ugly like other distros seem to. You need to grab the package from Packman. If you want to cover all your codec bases, you can actually do the install with one click (Pure marketing speak, it does sound better than 9 clicks + 72 popups; KDE folks get served here).

You can bring up the device properties from the sidebar context menu to access transcoding properties.

If you’re like the cool kids and use the lightning fast red carpet, however, you can –

rug sa http://ftp.skynet.be/pub/packman/suse/10.3/ packman && \
rug in packman:gstreamer010-plugins-ugly

It will actually pull its own gstreamer and replace the default one, but it did not seem to break anything for me.

After this, you can check out for presence of the magical LAME encoder with gst-inspect | grep mp3. If all went fine, you can simply drag and drop the flac files onto your ipod and Banshee will do the transcoding. And yes, the metadata is all fine.

I’m excited to see interest in dark widget themes. I’ve grown to love a dark environment as I usually work on graphics or photos and dark neutral gray just makes the content come alive.

Darkilouche theme.

It has been suggested to ship some dark themes in gnome-themes in the past, but I would go a step further and propose using a dark(ish) theme by default in stock GNOME. Having a dark theme would make perfect sense for vanilla GNOME. It would expose theming issues which are easily ignored when all you run is a light background. It will not really affect huge number of end users as most distros ship their custom themes though. But the core developers will have it up their faces

No other desktop I know is using dark widgets, it would make up for a distinct GNOME visual style to an extent the nature-theme we discussed at Guadec ever would. Let the distros be held down by conservatism, let’s be bold and go dark!

No matter I did the research and found the Star SP512 receipt printer to have cups support, I can’t get it to work. Simple echo "hello world" > /dev/ttyS0" is nifty, but I’d like to be able to use more sophisticated apps .

If anybody reading this blog has experience with it and can help making the provided cups driver (particularly the PPD) actually work on a recent distro (/var/log/cups/error_log is silent, gnome-cups-manager says “** (gnome-printer-view:31912): WARNING **: model named 'Star SP500 Tear Bar' doesn't have a recognized structure” I would appreciate it.