My First Snow in Helsinki

Wheee!

Document Representations

In response to Stuart:

I don’t think it’s a good idea in general to confuse the user with the technical difference between data in memory and data that has a representation on disk.

What I would like to see in the long-term is:

* Every document is stored on disk (and regularly synced), even if it’s as anonymous files in a temporary directory. “Saving” a document should be as simple as giving it a name, which might then move the document to a permanent storing location. In the usual case, I believe that documents should be created first and then edited. I would see temporary documents mostly used for things like working image copies in Gimp.

* Very direct mapping between a document on disk and its corresponding window, e.g. it should be possible to manipulate a window in the same way you can manipulate the icon representation of a document (drag it to the web for uploading, and things like that). I’m not sure if the “icon in a window” approach of OS X is the best way to do it, but that would be one possibility. Nautilus implements something like this with the folder button in the status area for spatial windows, but there is no general way to do this right now.

Generally, creating, naming, moving and deleting files should be a breeze, wherever you are, so that the idea of creating a new document does not seem like a chore or give the user the feeling of creating a mess. Sensible names and places should be suggested and data stored in a way that does not crowd the data that the user cares about most. Also, accessing a document should not have to involve finding the document at its physical location, but still give the option in case the user would like to put it in a specific place for quick access (e.g. the Desktop, as long as it acts as a workspace).

Of course none of these ideas are new, so this is not a useful post in any way. But I think it’s a petty that we still don’t have the means to even allow applications to implement these kind of mechanics in a sensible way. Let’s think about it, and let’s solve it.

Creating Themes

(This is, more or less, a continuation of the previous entry)

Jono writes enthusiastically about the CSS theme engine work, and I would love to share his excitement. But I just can’t see it making a big difference. Don’t get me wrong, Rob’s work is fantastic and might lead to some very interesting things. It also promises to serve as a more flexible kind of pixmap engine in the future, and the familiar CSS syntax is certainly nice for us developers (and those of us sitting on the fence).

What I don’t see is, how it will dramatically lower the barrier to entry for GNOME theming, or even lead to better themes. When you look at the web, spectacular designs are (by and large) not spectacular because of CSS attributes, but because CSS allowed web designers to precisely position… pixmap images. Positioning, however, is the least of our problems in Gtk theming (or rather, we don’t have a choice in the first place). CSS attributes alone won’t help us create breath-taking designs, so by and large it will be things like the border-image attribute (a standard feature of the pixmap engines), which will drive most visually exciting designs. I believe this is a good thing and the right way to go, but the important part here is not the CSS syntax in the GtkRC, but that we get back to embracing image-based themes. Arguably, a more stream-lined syntax would even be easier to deal with for artists, even if they have previous experience with CSS. Just because many people know CSS, doesn’t mean that artists and designers will suddenly enjoy writing code. In the ideal case, they should never have to touch the GtkRC in the first place.

The only way I could see CSS making a real difference is if we would enable absolute themes as kamstrup calls it, which I believe are very badly needed if we want to see some actual creative spark injected into Gtk theming. A UI designer working with a graphics designer should be able to create compelling designs, but right now this just isn’t happening due to a ridiculous amount of abstraction. It’s not possible to create ideal interfaces because it is impossible to know how the actual elements will look like with a random theme, and it’s not possible to create ideal designs, because you have no control over how your graphics end up being used by application layouts. That’s why our themes feel dull and repetitive compared to the competition. There is no lack of artistic talent or enthusiasm in the GNOME theming community, there are just too many technical limitations (and sadly, CSS will not get rid of any of them). Look around GNOME theming sites and you will see a huge amount of creative ideas and compelling designs, but pretty much everyone trying anything out of the ordinary is running into problems sooner or later. Some we have been able to work around with terrible hacks and special cases in the theme engines themselves (which made pixmap themes all but obsolete), others we just accept or cave in and go for more generic, bland designs.

What set Clearlooks apart in the beginning was, that it tried to break with the monotony in many ways. So our comboboxes actually started looking like unique widgets, instead of a button put besides a text entry (a simple feat that frustratingly enough requires a lot of hackery), and many similar details which had generally been ignored by Gtk themes. I believe we managed to close some of the gap between our GUI and the competition at the time, but now they are running circles around us again. And I strongly believe that the core reason for this is that they actually design their user interfaces, while we generate them.

So what is this generic approach actually getting us? Perhaps it is easier to ensure a minimal amount of consistency like this, and the biggest advantage is probably that changing a theme will always affect the entire (Gtk-)desktop . But 1000 generic themes don’t out-weight a single really well designed one, and if we aren’t able to reach the optimal result because of our support for generic themes, then I believe that our priorities are terribly misguided.

A Proposal / Summary

Summing up all my thoughts on the subject, this is how I would like the future of GNOME/free-desktop theming to be like (you are welcome to flame my opinion, but in that case if you skipped to the end, please do me the favour of reading the entire post):

• Drop the idea of themes as a central feature of the GUI. Instead create visual standards for platforms, similar to the HIG, allowing components to provide their own custom elements (e.g. graphics), as long as they comply to these developing standards. The community focus should be on maintaining and improving this common design. If more than one theme can be supported, that is great, just don’t work from the assumption that themes are arbitrary. Customization should still be possible (and would even be more powerful due to less limitation, just requiring more work like in the old days of xmms and friends), but if you do, you should be expected to be on your own and not necessarily get 100% consistency across the desktop.
• Allow custom per-application/component layouts, ala Firefox (or at least considerably more flexibility than we have right now). Not every application has the same requirements, and it should be easy to create new interfaces specifically tailored to a new environment, e.g. a mobile device. Some kind of markup plus CSS and JavaScript perhaps. Just because this kind of flexibility has primarily been used for excessive irrelevant eye-candy in the past, doesn’t mean that we can’t use it for good (building fantastic user experiences).
• Separate layout from “skin”. A layout should be specified by designers and implemented by developers (where both may well be the same person of course). It might involve a modified theme engine or module, and most definitely the theme RC file(s). The skin, or image layer, should be the only thing an artist ever has to touch, and could be used for easy re-branding or modified colour schemes. Even dynamic colours could be generated from this skin.

Most of all, I would like to see a new theming API/engine with the following features:

• Image based. Cairo drawing operations have been a neat way to combine the flexibility of custom theme engines with some more attractive visuals, but this can’t scale forever. We are getting to a point where it becomes a serious consideration to use pixmap caching of complex drawing operations to increase performance, and this makes the entire reason to use coded drawing operations in the first place seem rather dubious. Images are what artists should work with, and the lack of flexibility is a problem we need to solve, not circumvent.
• For the sake of this flexibility, the engine needs to support a wider range of definitions, e.g. various pixmap slicing and simple effects like gradients and shadows which can be applied on dynamic objects (think blurred text shadow) as well as unlimited compositing (e.g. blending various images and effects to create one widget). CSS with extensions is certainly suitable for this.
• We need to solve the lack of contextual information (a button might be in an HBox inside a dialog, but does this make it a dialog button? There is too much guesswork involved in GtkRC pattern matching). A list of detail strings instead of a single one might be far more useful too. But there are certainly many good ideas out there, and it’s a well-known problem.
• Massive simplification. The fact that a combobox is a composited widget containing an entry and button (or a button, separator, and icon, etc…) for example makes things unnecessarily complex, when all you really want is to draw one unique element. But most of all, it might have made sense to build widgets from shadows, boxes and lines in the past, but these days, it just doesn’t. Rendering widgets should not be any more complex than it needs to be and in the vast majority of cases merely involve the rendering of a single (sliced) image.

The engine that comes closest to this already is probably the maemo engine, sapwood. It may well be the most advanced Gtk pixmap engine right now (aside from its made-for-tablet limitations), and I believe that some of its concepts should be explored for the desktop (e.g. caching and serving pixmaps from a separate process to conserve memory and increase performance).

Right, this wasn’t a proper summary. Again, these are just thoughts I want to get out there. I know that many will disagree violently, but I do believe that this is an approach worth trying. I hope I will get around to hack on things that make some of this possible, and I hope that future revisions of the theming API will tackle at least some of the most glaring problems. Let’s make GNOME styling fun again.

Thoughts on the GUI

Before I start, let me get one thing off my chest. The progressbar animation in Ubuntu 8.10… It moves the wrong direction! Sadly the original default in Clearlooks was chosen from a poll, which had a subtle flaw: The progressbar wasn’t actually progressing, and that makes all the difference (as more people will hopefully realize now ).

Thank you, this was important.

Some observations about current trends in GNOME themes:

• Desaturation. I see many many themes and mockups tone down the amount of colour in the general chrome, which also happens to be what Apple and Microsoft are doing. The popular Ubuntu Dust is a good example of this. Personally I find this style very attractive, so I welcome this development.
• Another popular thing seems to be the reduction of borders and bevels. Many themes for a long time have tried to reduce the window border to a thin line, to create a cleaner look (as OS X does), which obviously fails to the lack of a consistent resize handle for GNOME applications. A workaround is to only make the bottom border thick, but this can look rather crude, especially when the application also has a status bar with a resize handle. Dust uses a fairly small bottom border which looks nice, but I find the usability of it to be fairly poor.
• Along the same lines, people are trying to create a more unified look and remove the separation between titlebars and the application (again, Dust is a decent example for this). This makes a lot of sense, it doesn’t just look good, it also makes windows appear more like objects and it should increase the area of the chrome which can be grabbed. Of course the latter isn’t the case with Gtk. Another problem is that the menubar gets in the way. Creating a unified look that works well with and without the existence of the menubar is near impossible. Dust does a better job than most, but the lack of a separator on no-menubar windows still feels like a bad compromise.

So what could we do to support these trends? It is unreasonable to think that themers will come up with something truly remarkable, if we don’t provide them the means to implement popular concepts. I see this as a general problem in the GNOME art community, design generally seems to be seen as this thing that has nothing to do with programming. But providing a set of API functions and replaceable images just isn’t enough. Great design has to be a top to bottom effort. I’m not optimistic that we can ever rival OS X (or Windows even), if we don’t start talking to each other and take design seriously on all layers.

That said, here would be some thoughts:

• Reconsider the menubar. Soon we are the only ones left who still stick to the traditional method of putting the menubar at the top of every window, right below the titlebar. It’s not just bad for design, there are other problems too. E.g. it really isn’t well suited for applications that have a very small profile, like a buddy list. And a small menu looks silly on a large window, which invites application developers of simple applications to add countless trivial menu items, instead of keeping the application menu nice and tidy. Let’s brainstorm some alternatives and let’s not be afraid of breaking consistency. We will have to do it sooner or later, if we don’t want to be trailing behind for all eternity.
• Make the resize handle ubiquitous. Resizable windows should have a resize handle, not just to make “borderless” designs a real possibility. I regularly find myself unmotivated to resize a window if it got no resize handle. Marrying the resize handle with the statusbar seems fairly pointless to me. Let’s make it possible to integrate the handle in every possible window design (even if it has to transparently overlap the content area).
• Pull the window frame drawing into the toolkit. The strict separation between frame and application causes many problems. The application should have complete control over the appearance of the window object, and there should be no difference in behaviour between different (often equal looking) parts of the chrome. This could also allow applications to tweak the entire window object, if the conventions are not ideally suited for a specific task. Consistency can be ensured by using common themes/layouts (more thoughts on this coming). This would also open up the possibility for many alternative menu designs (and of course “legacy” applications would still be supported with a separate frame).

I planned to write more, but this is already getting quite long (and I tired), so I will break it up into two posts. I will go more into my reasons for some of the more controversial thoughts and add some more thoughts about theming in general.

I am aware that this must look like armchair-criticism, but I am mostly just trying to express the various thoughts I’ve had in my head for a while now. I fully intend to make up for it in the near future with some actual work.

Apples and Oranges

Thanks to my very generous employer, I am now happily typing a blog post on this:

(my apologies for the crappy picture, which really doesn’t do it justice)

I believe there is a lot we can learn from Apple, and I’m not (just) talking about the software. I don’t think the future of Free Software lies in generic operating systems and applications, which we ask our users to install on their random hardware. We are already seeing Free Software being used on many small devices, and only Free Software allows the hardware vendor to create a unique and tightly integrated experience (even Apple requires the foundation of OSS). I think this is the best way to make users happy, and something we should be focusing on.

Today, our phones have comparable power to our high-end desktop computers from not too long ago. “Laptops” are shrinking to the size of Netbooks, and high-end Notebooks are now considered by many to be perfect desktop replacements. Devices are getting smaller, more integrated, more portable, and Free Software is right there with it. I believe that this is where exciting things happen, and what we should focus on. Not so much how to make a Linux distribution 5% easier to install, or how to make the generic desktop a little bit more acceptable for everybody.

Anyway… Last weekend I finally worked on Scratchpad again, mainly porting it to use gtksourceview-2 and replacing some GnomeVFS functions with gio (though it doesn’t use it for file loading yet). It was a shock to me, that the last ChangeLog entry was almost exactly two years ago. Many thanks to Juerg Billeter for keeping the source at least somewhat compatible to Vala SVN.

Working on Scratchpad often gets me thinking about the irony of writing software which essentially only allows me to more efficiently write software. I think we often tend to get caught up in this loop, writing software just for the heck of it, and writing interfaces for developers so they can write better interfaces for developers… Then I need to pinch myself and remind myself about the actual goal: Writing software that makes peoples life more enjoyable (or easier, healthier, …) than they would have been in a time before computers were invented.

That should be enough rambling for now, maybe next time I will actually manage to find a clear topic to write about.

I am happy to note that a Macbook can be used quite comfortably on the lap after all. Not that I would mind some heat, in the months to come.

Changes

• Not long ago I cut my hair, so I need a new hackergotchi. This should do:
  
  Could someone update it pretty please?
• Got employed by Openismus.
• Moved to Helsinki for the next few months.

So far I am liking the place and work very much, and I hope I will be able to be a more active part of the GNOME themeing/UI community again. I have a lot of thoughts on it, but more about this later.

One thing though, I do not believe anymore that scripting is the way to go, which makes it doubtful that I will actually finish the Lua engine at this point. I might use the codebase to explore different ideas though.

mobti

For the last month or so I have been working intensively on a site called mobti. I got the idea for it when I was discovering something new about my personality, and thought it would be nice to have a website where I could easily find people of a certain MBTI type, e.g. to find out if there are commonalities. The idea expanded and for a long time I put the project on hold, thinking that it would probably take too long to tackle right now.

While it’s not quite finished yet, it is basically usable and I was quite pleased with the amount of work I got done in this relatively short time period. The biggest time saver turned out to be the decision to switch from code igniter to CakePHP, which spared me from having to implement many mundane details, like an authentication system (I know that CI has third party libraries for this, but I couldn’t find anything that appealed to me). I used jQuery for the Ajax and effects and quickly fell in love with it. The last time I used JavaScript was many years ago, when it was virtually impossible to write anything moderately complex and expect it to unconditionally work on all major browsers. It is almost unbelievable how much things have improved, and I’m actually looking forward to write more JavaScript based interfaces now.

Chrome First Impressions

Sometimes, using Windows does have its advantages. For instance, not having to wait before I could try Chrome. I didn’t get to be excited about software releases since I switched to mostly using Windows again, so this is a very nice change of pace. And who would have thought, that out of nothing a new web browser would appear, that actually does make a difference.

Even the installation made a nice impression, effortlessly importing my Firefox settings (for once this is not a mess) and even asking me if I would like to switch the default Google search to something else (nice touch).

The interface is definitely one of the slickest I have seen in a while, and one of the most consequent applications of the “less is more” mantra. There is not much, but what is there feels insanely smooth and polished. The titlebar is particularly elegant, with the integrated tabs. In fullscreen, the titlebar collapses and the tabs touch the screen edge, creating an OS-X menu-like effect with Fitt’s law benefits. Mostly it’s about the little touches though, like instant bookmark saving, being able to open the first autocomplete entry without scrolling down, not getting the dropdown cluttered with huge URLs I never typed in the first place. The homepage does not feel like a useless gimmick, but actually fits very well into the overall design. All in all it feels like an extremely well designed piece of software.

Equally impressive however has been the speed. It is hard to believe how light the application feels, and everything from starting the browser, over switching tabs, to loading pages feels perfectly responsive. This honestly beats every text editor I currently have installed (with the possible exception of Notepad), and it’s a bit of a mystery to me how this is even possible. Certainly WebKit has a large part in it.

Speaking of WebKit, it has turned into a very impressive engine. Not long ago I didn’t expect that it would ever get close to Gecko before Gecko would close the performance gap, but now I believe that I was probably wrong. Every time I tested WebKit recently it has impressed me with its accuracy on even the most complicated sites (and sites which I never tested for it), while still being lightning fast. Add to this advanced features like multiple CSS backgrounds or rounded borders (I have to say though, that the latter look much smoother in Firefox 3), and I got very interested in seriously trying a WebKit based browser. Now with Chrome I am certain that WebKit will establish itself as a serious alternative to Gecko, and I’m curious to see how this will play out. Mozilla might have to kick in a gear if they intend to keep the lead.

So far I am very impressed, even more so than I expected to be impressed, and unless further testing reveals some glaring deficits, I am very certain that Chrome will be a big hit (hopefully not just eating from Firefox marketshare, but also from Microsoft). This is the first time I have been so excited about a browser since the first releases of Phoenix Firebird Firefox.

Updates

It has been a while since my last blog entry, so it is probably about time that I provide some updates. I have not done a lot of programming lately and recently I have not even used Linux most of the time, so things are going rather slowly.

Thanks to a patch by Jürg, Scratchpad now compiles again against Vala SVN. Since I don’t have much use for it right now when I don’t use GNOME, help would be much appreciated. I do hope to get back to it sooner or later though, as I still don’t know a real alternative to it.

While looking for a decent text editor for Windows I found e, which has many good ideas. Interestingly a Linux version is planned, but unfortunately it is proprietary.

Meanwhile I got severely addicted to Go and thus I’m afraid Chessmonk development is on hold. Fortunately the first (and only) release was already very usable as a PGN viewer, so I hope it will be of use to some people. Feel free to use any of the code or graphics in your own projects.

There has been no progress on the Lua Gtk Theme Engine either, it is still in the state of basically usable, with a few crucial details missing. It is unlikely that I will find the time and motivation to finish this unless I get a sudden urge to create a new Gtk theme, so if anyone would like to continue it, let me know.

A for myself, I realized that I enjoy design more than programming after all and intend to make a more serious attempt to get into web design, especially the visual side of it. For now I want to gain experience and build a portfolio, so please let me know if anyone needs a website done.

Hopefully I will have something to show again the next time a post is overdue.

Updates

Lua Gtk Engine

I’ve been working on a Lua based scripting engine for Gtk themes. Right now it isn’t really useful without example themes and documentation, so I will write more about it later. If you want to try it anyway, get gtk-engines from CVS and configure with –enable-lua. It still needs some work, many widgets aren’t supported yet.

For the API I’ve tried to find a middleground between flexibility and simplicity. It is based on simple drawing functions with parameters, for example: rectangle {x=0, y=0, width=200, height=200, radius=3, filled=true, color={1, 0, 0}}. Most parameters are optional. It is possible to specify both colours and gradients (linear and radial) with arbitrary colour stops. The nice thing about passing parameters like this is that you can store and modify them in a Lua table, for example:

myrect = { x=0, y=0, width=200, height=200 }
myrect.color = {1, 0, 0}
rectangle (myrect)

There is also a shape () function which takes an arbitrary number of normal and bezier points to create any shape you want. A screenshot that shows most of the current widget coverage:

Writing themes like this is a lot more fun, especially since you don’t need a recompile and restart anymore before you can try your changes. But most importantly users will be able to install Lua themes like any other theme via drag and drop, instead of having to install a new engine, just because they prefer their Clearlooks to have square corners… Performance seems to be completely acceptable so far. The difference is measurable, but almost neglectable compared to the actual drawing times. Lua is a scripting language that was developed with speed and size in mind, so it adds minimal overhead.

Chessmonk

For chessmonk, I decided to split up the chess board part into a separate package. Not just the display but also any chess logic will be contained in this package, so it will become easier to create different board window types. I got this idea when reading about a software called Chess Position Trainer, which is based on a similar chess board widget. This still needs a lot of work and isn’t functional yet, but if you are curious you can find it in the gtkboardview branch of the Subversion repository.

Chess Tournament

I didn’t dare blog about this before, because I assumed it must bring bad luck. I recently played a seven round swiss tournament in Krefeld and surprisingly was able to reach fourth place with a performance of over 2100 (Final Standings).

In the last round I had white against the third seed of the tournament (2060 DWZ). I didn’t really expect to win this game and reach the price ranks, but then it even became a nice miniature after my opponent made a mistake soon after the opening moves:

1.d4 g6 2.c4 Bg7 3.Nc3 d6 4.e4 Nf6 5.Nf3 O-O 6.Be2 e5 7.O-O Nc6 8.d5 Ne7 9.a4 a5 10.b3 Nd7 11.Ba3 h6 12.Ne1 f5 13.f3 b6 14.Nd3 Nf6 15.b4 axb4 16.Bxb4 Nh5 17.a5 c5 18.dxc6 bxa5? 19.Nb5 Be6? 20.c7 Qd7 21.Bxd6 Bxc4 22.Nxe5 1-0