Brainstorm

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/Transition Support

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?

Size Requests

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.

Consistency

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.

Sizes

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"?

Contexts