Hey, Here's another discussion point I want people to think about before the hackfest. This time it's not so much about API in a direct way but more about a guiding principles for the kinds of APIs we want to provide. The short question is this:
Who gets to decide how an application looks? This question is aimed at theming and the question of graphic design[1] and not at intersection design[2]. The way I see it, there is two extremes to this: A) The application decides on the theme Examples: The Web, Windows, Games On the web, no page looks like any other page. If you for example compare http://maps.google.com and http://www.openstreetmap.org/ one of them looks greenish with a lot of rounded corners, the other blueish with sharp corners; font sizes are different and so on. Every application decides on its own how it wants to look and implements that look. B) The platform decides on the theme Examples: GNOME 2, OS X, office suites Here the platform decides how things look and it's discouraged to deviate from the norm with custom designs. ITunes could win a Finder look-alike contest, even though both are very different applications. Even portable applications try to blend in. You will notice that Firefox looks a lot more like a platform app on OS X and GNOME than it does on Windows. Of course, there are a lot of shades of gray inbetween. Phone platforms have UI guidelines but applications often break it and games don't look like Apple apps even on OS X. OTOH Microsoft applications blend in quite well with the Windows design and all the Google web pages look very similar, too. There is no obvious answer for which way is better. But a lot of things need to be done very differently depending on what way you decide to implement. Some examples: - switching themes Using a completely different theme is a thing people like. With platform themes, the N900 people were able to look quite different from the GNOME on your desktop and various distributions could make themselves stand out by using their own theme. All without changing the applications. This would not have been possible with application themes. On the other hand, with application themes you can add features you want quickly. If you want to merge a foreground and a background button in a browser, you just add the styling to do that.[3] Or if you want to make info messages blue, you just make them blue. However, if the platform changes the theming from under you in a way you didn't expect, that tuning might make your app look like crap. Say if the theme decides backgrounds are blue now, your info messages are now unreadable. - complexity of theme design Writing a CSS for an application is easy. If your application has no toolbar, you don't need to style toolbars. And if you add toolbars later, you just style them in the CSS then. On the other hand, you have to write a CSS for every application. Writing a theme for a platform is hard. The current Adwaita CSS for example is roughly 5000 lines, so it's slowly getting as large as the code for GtkTreeview. But then, there's only one CSS file for all applications... - application UI design When developers design a UI for their application, the two ways require very different approaches. If the application decides on the theme, you can start with an image that's supposed to be a screenshot of the app when it's done. And then you can go and tweak the application's CSS until it matches. OTOH, if you're bound by the platform theme, the output should look closer to a Glade file, because you can't enforce pixel-exact alignment as you would expect in screenshots. This however usually requires the platform to provide (a) the editor to do these designs in and (b) a HIG so that application designers know why thinks work the way they do. - accessibility We have high-contrast, low-contrast, large-print and various other themes for people with visual disabilities. If applications theme things, GTK needs to make sure that these features are available even with custom themes. If there is platform themes, those people can just switch to a platform-provided theme for that feature. - form factors If you want to have different themes for desktops and mobile devices, this is easy on a platform theme. Just use a different one. But if it's done on the application side, the application needs to cater to those form factors explicitly. Whether this is a problem at all of course depends on how GTK aims to provide portability between different devices Now why is this interesting for GTK? Because the public API we want to expose and the cases we want to optimize the theming engine for differ quite a bit between the two approaches. Some examples: - gtk_settings_set (settings, "gtk-theme", "Adwaita") This does not make sense in an application-themed world. It should not be possible to change the theme. - gtk_widget_set_style (button, "color: red; border: 0"); This does not make sense in a platform-themed world. It should not be trivial to override the platform theme that easily. It's also interesting because the GNOME 3 design efforts are currently very focused on implementing pixel-exact screenshots in their applications while the GTK API is still mostly unchanged from the GNOME 2 design. And as a GTK developer I'm always torn between those two sides. Currently I'm telling both sides "you can't have that" whenever they want something, so they're equally unhappy. But I'd like that to change in the future. Benjamin 1: http://en.wikipedia.org/wiki/Graphic_design 2: http://en.wikipedia.org/wiki/Interaction_design 3: Hi Xan! _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
