Stuff from the old NewThemeApi Page
Inherit styles from the parent widget (not the case when using gtk_widget_modify_*.)
- New color model that is not as fixed into states?
Animation support inside GTK+ would be great. Note that there are a few different things that need to be considered:
- Continuous animations (e.g. progress bars)
- Animations between different states (transition effects)
- Animations where widgets are dynamically moved and/or resized. This could be an expander that opens, or a popup menu.
Another thing, for example is the feature that windows has, where the selected item in a menu stays visible for a while longer. How would this fit in?
Some use cases (such as embedded devices) require highly customised user interfaces. In some cases this means it would be nice for different themes to be able to change the size and position of widgets. For example, in a pixmap based theme you may want to set a size request so that the widgets are the same size as the pixmap being used to draw them. You may also want to set the size of two widgets so they line up next to each correctly.
There should be a nice way to set the arrow sizes for submenus, comboboxes, etc. at the same time. So you would have an arrow size option that affects all widgets, but can be special cased if needed.
GTK+ should support variable sizes. These should be either based on the font size, or the screen resolution (plus some user defined factor maybe). All sizes from internal widget paddings over icon sizes and paddings between widgets should be dynamic.
comment by tigert : One possibility would be to base these on "em" size - a unit derived from font size, thus then adjusting font size would scale everything accordingly. Hinting / pixel snapping might be a problem, but at least for very high DPI it will not be a big issue. But for very small widgets might need pixel-level sizing (for example theming special applications like a multitrack music recorder or graphics editor like Gimp if one wants very small dialogs to maximize content area on screen) - maybe it might work though if one just sets the font size right, so this might not be a real issue in practice. Or maybe just do the theme engine so that it snaps to nearest pixels always, to keep the look crisp. As I work on the maemo stuff nowadays, one important thing we have realized too is to start specifying widget sizes as physical units (millimeters etc) in screen, as we have a touchscreen user interface. This is not as critical with mouse I guess, but still it might be useful to keep in mind.
comment by Raphael Bosshard :For XAML Microsoft took the freedom to redefine "px" as being "device-independent units (1/96th inch per unit)". While I don't think that using the name "px" is a good name ("px" being a single dot on the screen everywhere else), I do think that this approach has its merits. On the low-resolution screens applications get almost pixel-perfect representation, on high-resolution screens you get device-independent scaling. What about "dot"? The idea came up to support some sort of contexts. So for example preference dialogs would set a "preferences" context and could get special theming using this. So theses contexts would basically be tags for widgets to apply special theming. This could work by parsing additinal gtkrc files from the theme depending on the application name. Tommi Komulainen has written a mail about this to gtk-devel-list. http://mail.gnome.org/archives/gtk-devel-list/2007-June/msg00042.html
(In the example the gnome-control center could also set a "control-center" tag.)
Application Level Theming
The idea came up to support some sort of contexts. So for example preference dialogs would set a "preferences" context and could get special theming using this. So theses contexts would basically be tags for widgets to apply special theming.
This could work by parsing additinal gtkrc files from the theme depending on the application name. Tommi Komulainen has written a mail about this to gtk-devel-list. http://mail.gnome.org/archives/gtk-devel-list/2007-June/msg00042.html