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.

As Barbara has been rocking the symbolic world, she was interested in the fullcolor Tango icons as well. We did a live Hangout session together with Garrett which we didn’t advertize anywhere, and yet some 20 people joined in. Now it’s up on the GNOME 3 Design youtube channel for your viewing pleasure.

Pssst! Looking for icons to design?

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!

One of the best features of SUSE Studio is the ability to boot your appliance remotely on our servers without downloading it first. It’s cool to test and improve the appliance as you can actually bring the changes done interactively back to the appliance project.

Of course there are times when everybody wants to do that at the very same time, so we have a queue system to accommodate the situation with limited resources. As this is not exactly a pleasant thing for the user we thought to make it less annoying by providing a nice graphic to look at while waiting. The first idea was to have a couple of Disters (our robot mascot) standing a line.

But it looks a bit depressing, doesn’t it? Instead of cheering up the user waiting, the image of a long line actually strengthens the negativity of the situation. So back to the drawing board. How about focusing on the fact that we have our hands full rather than the user waiting.

As the sketch worked well and got approved, I went ahead with tracing it. The beginnings are always hard as the graphic doesn’t seem to work until the very last moment. But in the end we’ve gotten ourselves a brand new failwhale:

It’s been a while since I’ve given a random Inkscape tip. This one is about exporting your designs for the web.

A great thing about mockups created in Inkscape is that you can actually use parts of the mockup for the final PNG export. What you need to do is to name objects or more likely groups of objects (and remember you can easily enter those groups). To do this you open up object properties window with
Ctrl+Shift+O and provide an id. The id needs to be unique in the document. Inkscape will use a randomly generated one if the name you provide exists already, so be careful.

When ready you select all the objects you want to export and in the export dialog (Ctrl+Shift+E) use the batch export the selected X selected objects checkbox. You will find the exported PNGs in the folder of the SVG with filenames based on the object ids.

If you have them on some background you don’t want exported, use the option below as well — hide all except selected. Note that Inkscape will only hide everything but the selection. If your selected objects are overlaid, you will still get fragments of them in the export. It doesn’t hide everything but the currently exported object, it hides everything but the selection.

Of course Inkscape is great in that you can do all this from the commandline: `inkscape -e foo.png --export-id=foo bar.svg`.

Last week we launched our SUSE Studio service announcing its 1.0 status. It’s been an honor to be part of the team behind it. I mean what other project uses javascript, flash, java, ruby, perl, mysql and git and at the same time qemu, kvm, libext2fs or fontforge, inkscape and blender?

You’ve had the chance to hear about some of the technology behind the project. I’ll add some artwork related bits into the mix here.

Dister

Building software appliances isn’t exactly a hip topic general web folk would rave about, but judging from the response I think we managed to get quite a broad attention. Our robotic mascot, Dister, helped maintain the fresh startup-like identity.

Initially he was created as a vector illustration, but went 3D in the end. The 3D part was a bit masochistic. While the process has been very painful and I’ve struggled with every small thing while creating the character, at the same time it was great fun. The result isn’t quite where I wish it would be, so I hope I can build up on the skills I’ve learned here soon rather than forgetting everything as I usually do. People who do character rigging deserve my utter respect. Even simple things turn out to be quite complex in the end. I also wish Inkscape performed like Blender does. It’s absolutely mindblowing what you can build up using modifier stacks in Blender and move it interactively. Inkscape just lets you taste the power of linked offsets, clones and filters but really under-performs in real life scenarios.

See the whole set on flickr.

Website Aesthetic

As any good product, we went through numerous iterations of the site. Sadly I didn’t manage to migrate the db back well enough to give you a taste of how things evolved over time, so here’s just a few things I managed to resurrect.

Comic Strip

One thing I’m sad we had to bin was our comic strip, err documentation. The idea was to create a nice walkthrough of the interface and the tech behind Studio in the form of a short comic strip.

Unfortunately I couldn’t pull it off in a reasonable time and even if I did it would probably retain that “oh, they’re copying Google” aftertaste.

Origami CD Covers

Another feature that didn’t make it into 1.0 and will hopefully become available in future is a mean to print out an origami cover and a CD label to the custom appliance you’ve built using the custom artwork you’ve specified.

I’ve only created a proof of concept using my favorite duo — Inkscape & ruby, only this time throwing rmagick in the mix to get the automatic text color based on the background lightness.

I hope you have enjoyed a look behind the evolution of SUSE Studio visuals as much as I’ve had fun creating it. Don’t be shy and let me know at the comments below.

Failure IS an option for hackweek . While things looked fairly optimistic on the icon theme/font front, the actual results don’t look so good.

While the chopping script is working fairly well, it’s hardly elegant and really suffers from insanely slow startup time of Inkscape. The “crop” is done thanks to Inkscape’s verbs and requires Inkscape to be called once per icon. Even worse, to clean it up and remove some cruft for the Fontforge import, it needs to be called once again.

Ted mentioned a GSoC project to provide a better interface for external scripting (using dbus), but I haven’t had time to look into it yet. By the time I’ll look at this again, it’s going to be merged in, surely .

Fontforge’ interface couldn’t be in a bigger contrast in terms of speed. Importing SVGs as glyphs and generating a truetype font out of the template is faster than you can release the return key. Sadly FontForge doesn’t expect the font height to be 24pt and all the circles don’t end up as such after the import. I haven’t been able to figure out how to either scale the SVGs up to 1000px in Inkscape or transform after the import in FontForge.

So this has been a rather kind failure. One that doesn’t leave me feeling like I wasted my time.

CSS theme engine

I had an old mockup for a CSS theme that now felt too bubble gummy. After dealing with the hyper-realistic renderings of gnome-icon-theme high res, I enjoy the minimalism of Moblin.

Sadly time has run out as I’ve had some outstanding tasks I needed to handle. Hopefully I can get back to this. The engine just manages to avoid me.

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!