The Past

My first ever libre software gettogether was GIMPCon in 2000. The location at the CCC gave it the proper underground vibe. That gathering later became what is now Libre Graphics Meeting when the GIMP and Scribus folks thought there’s some possible synergy to benefit from.

The future

It may sound like a little blasphemy for a GNOME person to say LGM is my favorite conference. I dig GUADEC for its mix of developer and user oriented talks and workshops, but at LGM this synergy seems to be working even better. There’s probably a trend towards attracting more designers than engineers, and I don’t know of a tech conference where there’s pretty much 50:50 gender mix (perhaps in Madrid there were more women than men even).

I want more conferences or gettogethers like this. Feedback from an animator struggling to finish a task is million times more valuable than online polls asking for a feature that exists in other tools. Small community projects struggle greatly with focus and motivation. These user<>developer sessions should not mean folding every single suggestion into Inkscape feature and SVG spec, but seeing tools used is the best we have for user testing.

There were some humorous mailing list like moments too (I hope video archives will be posted, the sessions were recorded). We had a nice example of miscommunication between Boudewijn and Mitch during the GIMP Q&A, but there is room to turn that “but printing spot colors is way more expensive than CMYK, stop ignoring your users” to “it’s the actual workflow, retaining control over individual channels during the process, that makes CMYK a subset of stop color process, the output/print process remains the same.” when talking off a mailing list. People sometimes need to talk face to face to turn those faster horses into cars. I have lost all faith in non-technical or controversial topics ever resolved on a mailing list.

Workshops

I also really enjoyed the “get your hands dirty” sessions such as David Revoy‘s Krita speedpaint workshop that are the carrot-at-the-end-of-the-stick for potential new designers giving libre graphic toolchain a go. Seeing amazing art created with our tools is an amazing motivator that allows to overcome some bumps on the way and actually find strength to find unfamiliar solutions or actually bite the lip and start the dialog with the developers (it’s harder than you think). I don’t think my painting skills will improve any time soon, but the workshop did expose a significant omission from the Wacom settings for non-screen tablet users. It felt the Krita developers are on a good course working closely with David to shape the tool and getting amazing promotion and an actual product in return, in a similar way the open movie projects dramatically improved the quality of Blender.

Type

A significant number of talks related to type. Ben Martin and Dave Crossland presented the collaboration features of the new Font Forge. This sounded really intriguing for me, because a lot of the design process is tedious and horrible and things like metrics are a torture that I found much more bearable when we did it with Patrys the other day.

Ana and Ricardo made me feel guilty about never finishing or publishing some of my fonts, because I felt they are too raw but then never gotten to finish them. They mentioned their new foundry and some utilities like the autospacer, giving you a template workflow rather than starting from the dangerous and feared blank slate.

If you ever needed some hand holding for designing your own type, Dave pointed out an extremely nice guide to me.

Getting Started

I gave a short talk on the work we did on Getting Started, but in an expected way was dragged away before I could show some guts of the project. As there’s been interest to see behind the scenes more, I’ll try to blow the dust off the design team youtube channel and do a screencast.

LGM Rocks

I really had a blast seeing everyone again, and came back with a list of things to do and also the energy to do so. Big thanks to the organizers and in particular the GIMP folks for their continuous support of the event.

Recently I saw a few people commenting along of ‘GNOME 3 icons being crap’ so I investigated what the actual core of the issue might be. When dissing the years of work that went into creating the system theme and pushing app icons upstream, most of the commenters seem to actually have a problem with the folder icon.

The GNOME folder is a result of using the actual beige color that is both the real world folder material, and the legacy of Tuomas’ GNOME 1 folder. Easy things are hard so it’s a result of endless iteration with my soul mate, Lapo Calamandrei, to get the icon look great at the small sizes, but also to have the icon snap to the render grid well for the common high res sizes (64, 96, 128, 256). It repeats well in a grid. I feel the voices disliking the beige folder are the same voices disliking the grey folder in the original Tango set. We ended up listening to those folks and changed it to blue, but I ended up regretting the decision.

The blue folder grabbed way too much attention for something that’s used when browsing for the actual content. While a lot of effort went into making the folder, we don’t actually expose it all too much. Exposing the directory structure is the pre-GNOME 3 world. What we focus on now are the applications.

Which is actually the other issue people seem to attribute to “GNOME sucking”. It is true that the current reality of opening up the overview is quite different to the ideal mockup.

Many apps ship with very sub par application icons. One of the solution to this problem is to “take over” the theming of Application icons. We have been there in the past and just like taking over app distribution by distro packaging, there is a lot to lose when you centralize something that should really be left to the application authors. The app icon is the app’s identity. Sure it’s more difficult to convince the upstream to take your work despite it not being created by an algorithm, but taking away a project’s identity in the name of policing the aesthetics of the overview is not the right approach. We toyed with the idea of forming a blacklist and buttonizing some icons in prior to the 3.0 release, but came to the conclusion we should help app authors with guidelines and design help instead. For the life of me, can’t find this on the wiki anymore.
We’ve been successful in pushing app icons upstream for projects such as Inkscape, GIMP, Blender, Transmission and helped other projects such as Font Forge to create a multi-resolution icon adhering to the Tango guidelines. Another aspect of taking over all app icons by overriding them with an all-encompassing theme seems to be “consistency”. The word is used in a sense that the icons share a common shape and perspective. Now while that makes them form a really nice grid, it goes against the most useful attribute of a good icon — being distinguishable form the rest. I love the challenge of being restricted to a button shape and I’ve certainly drooled over some of the smart icons fitting into a rectangle pill, but a unique silhouette is really helping in identifying the app in the grid.

We do have a wider choice for the perspective in the Tango guidelines. Experience has showed us some objects simply can’t be made immediately distinguishable facing straight, so the on the table perspective is used sometimes. But that doesn’t suddenly make the set inconsistent.

To make myself clear, the icons aren’t perfect. We have a lot of issues to fix, but I felt I needed to express my stance on the repeating comments.

• Greyness of GNOME icons.
• Tile fit.

GNOME 3 introduced a new style of icons we call symbolic. Last year, Meg Ford joined the effort we kicked off with Lapo and did a great job extending the theme coverage, without us having any style guidelines in place yet. This year, we’ll have another Woman Outreach program participant joining the effort, so I’ve edited a little video introduction on how we design these icons along with a little overview of all the icon styles currently in place.

Allan’s new rule says that if you don’t blog about it, it didn’t happen. Thus here’s me telling you about the recent icon design sprint for GNOME 3.0. There’s not much to say, I’ll be honest. This post is about pretty pictures.

GNOME shell exposes application icons in higher resolution than usual, so the fearless Italian led the icon design faction of the design team to fix up the most visible app launcher icons to include the ridiculous size of 256x256px. We also investigated possible workarounds for applications shipping horrid icons, but in the end it’s more important an application is recognizable more than it is pretty, so we backed up from all of those ideas.

All this work is of course on top of the base themes, which are also in a better shape than ever. Big shouts to Lapo, Andreas and everyone involved!

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

Matthias, not sure what sub-pixels you refer to, but it’s great to see pixel-grid snapping love. Also worth noting is proper rounded corners. The last thing that’s subpar are the blown up tango icons. Perhaps Moblin-like stencils would be better for the images on the OSD panels.

And please enable comments on your blog

One of the greatest things about openSUSE is happening again this week. Hackweek time seems to also be the only time I have something worthwhile to put on my blog.

I don’t have a very focused plan for this year, but I’d like to investigate the following:

• Stencil icon workflow.

  I’d like to have a single SVG canvas with all my icons and generate an SVG-only icon theme. Ted Gould showed me his nifty script at GCDS that used Inkscape‘s verbs to ‘chop up’ an SVG into individual SVG files, so that part I already know is feasible.

  The untouched ground is importing those SVGs into a FontForge project file to generate a font out of the theme as well.

• CSS gtk+ theme. Robert Staudinger has been working on a gtk+ theme engine that allows a theme creator to use CSS-like language to draw stuff (as opposed to talking to a developer to draw stuff). The project has been on my radar forever and I’ve never really sat down and gotten my hands dirty. Must fix!

Wish me luck!

Hey Daniel – I happen to have been working on OPML and RSS icons this eveni^W morning, so this one came out for free. Not that I think the symbol is meaningful. It’s really just a coincidence I’ve had this open in Inkscape and bumped into your blog entry.

At Novell, we take everything from Redmond as the Holy Grail.

Some people prefer to have the tool icons unobtrusive, not to steal the focus form the actual artwork. Here’s a quick theme to do just that for GIMP 2.3. Untar to ~/.gimp-2.3/themes/ and select the Greyscale theme from the preferences. The gtkrc uses menu-sized icons for the toolbar and tiny fonts.

Click to download the theme.

You need to tweak the gtkrc to your liking if that’s not your choice. There is a dark widget gtkrc included, but is commented out as it looks weird for metacity to pick up light colors from the global theme, but have the window content dark. You can of course use that one globally. Just add your favorite engine to it.