Federico rants on themes
- Sanity checklist for theme engines
- Discussion on a new default theme for Gnome
- Havoc's blue-sky ideas for themes; start reading at the fifth paragraph.
- Seth's blue-sky ideas on a rendering framework
- Seth's screenshots; grep for "dynamic themes"
- Owen's explanation of the GTK+ theme architecture
- Reference documentation for gtkrc files
What problem are we trying to solve?
I don't think "use CSS" is an answer to everything. What problem are we trying to solve?
Different toolkits have different looks
People have successfully overcome this by writing custom theme engines for GTK+, Qt, OpenOffice.org and Mozilla. This has been mostly customized for a particular look (e.g. Industrial). Metatheme would be the right approach in this regard: just write theme engines for each platform, so that those engines share a common set of drawing primitives. This is harder than it sounds because each toolkit draws its widgets with different granularity.
Different toolkits have different spacings
This is harder to solve, as the spacings are often not in the toolkits themselves, but rather in the way applications define their windows and dialogs.
GTK+ apps normally use hardcoded pixel distances like gtk_box_set_spacing (box, 12); - this is in effect what libglade does, too. Bug #101859 has a concrete proposal for how to "magically" turn this into abstract units: apps would not need to be modified, and the spacings would still scale with the font size or some other factor.
OpenOffice.org uses absolute positioning rather than a container system; I don't know if it uses pixels or twips or something else.
I don't know how Mozilla/XUL does it.
Changing the layout
E.g. do we want people to change the spatial relationships between widgets, or even the widget types themselves? This doesn't always make sense. Havoc had a sophisticated blue-sky idea based on "essential" and "inessential" components for the internal layout of widgets, but this smells of gratuitous complexity at this point in time. Also, rearranging the widgets won't always give you a better GUI; it will just give you a prettier dialog.
Or do we want the HIG police to easily change the spacing in dialogs that look "wrong"? It just sounds easier to hunt down the definition for the offending dialog and change it - especially for things like OO.o which use absolute positioning; shifting a widget by a few pixels may cause the rest of the dialog to become misaligned. I'm not sure how OO.o deals with different string lengths when translation occurs; Michael Meeks told me at some point that they follow the horrible road of "just add enough spacing in the untranslated version so that uberlonggermanwords will fit in the end".
Different toolkits have different feels
Do shift/ctrl and clicking do the same thing on lists with multiple selection?
Do the "up/down" arrows that appear when you click on a column header indicate ascending or descending sort order?
Does the scroll wheel scroll the focused widget, or the widget under the pointer, or something else?
Do modifier keys do the same thing when you drag-and-drop and the drag comes from different toolkits? Can you cancel in the middle of the drag by hitting Esc like GTK+ lets you?
Will double-clicking on the handle of a paned container hide one of the panes?
Do text entries select the whole text when you focus them?
Do all the toolkits have the same items in the context menu for text entries?
GTK+ uses a triangular buffer area for navigating multi-level menus with the mouse (like the Mac). Qt and OpenOffice seem to use a timer (like Windows).
What about the timeout value for popping up submenus? This is subtly different across toolkits.
Do context menus come up as soon as you press mouse button 3, or as soon as you release it?
All of this needs to be audited and documented so that we can standardize it. There are countless other little details that make up the feel of a toolkit.
Investigate Metatheme. Audit it, taking in mind the sanity checlist for theme engines.
Audit apps that use ad-hoc spacings. Investigate how to turn hardcoded spacings into multiples of some-magic-factor which can be made to scale with the font size in the future.
Michael had started some work on providing container-based layout for OO.o. Finish this work, and convert all of OO.o by hand (!) to use that system.
"Use CSS" sounds to me like trying to shoehorn a buzzword into a very broad problem. Instead, let's look at what we need to do to make things uniform now with the least amount of work.
In the future, even if someone writes a super-powerful system for theming/layout, you are still not going to succeed in making people rewrite their apps to use it. Look how long it took to rewrite Mozilla, from Motif to XUL. This is the kind of thing that really needs to be done incrementally if you expect to get adoption from major platforms.
Story from the past: It used to be that the Midnight Commander had its own text-mode widget system. For the very first versions of Gnome, Miguel wrote a quick hack to map the text-mode layout GTK+ widgets; everything looked like total ass. We had to rewrite all the windows and dialogs using hand-crafted GTK+ code - Glade/libglade didn't exist yet. It took JRB and I, and basically the rest of the RHAD Labs people and several hackers from the Gnome community, between two and three years to do this, even though MC was a small program (under 50 Kloc). Think of how much time it would take you to rewrite OO.o's user interface like that.
Metatheme sounds really worthy of investigation. When it is known to work, you can make its own engine use SVG+CSS or whatever other drawing primitives you want to use; with that in place, you would learn a lot of things to be used for the uber-powerful theming system of the future. Still, I don't think you'll get much traction with theme authors (graphic designers, not theme engine hackers) unless you have a GUI editor for the actual look.