On Fri, Jul 31, 2009 at 6:19 PM, Tristan Van Berkom<t...@gnome.org> wrote:
[...] > The idea of theme writers doing something to the first or last item > of a GtkBox simply based on it being a GtkBox; is a scary idea to me, > while I do recognize the value of exposing the positional data of GtkBox > to the theme code - ideally though - the theme code should never ever do > anything to the interface that the interface didnt ask for (i.e. the > theme engine > only applies CSS classes to widgets that set a tag for that class, or possibly > default to a tag, leaving programmers with expectable results, always), > unfortunately we have to include some level of support for this in order to > transition away from old broken themes that make direct assumptions > about your widget classes. People frequently request being able to round only the outer buttons of button boxes or treeview headers, like so: http://www.gnome.org/~robsta/tmp/child-index-selector.png > So, small/medium/large indentations for instance, could be done something > more like this: > > /* GtkBox theming for large indentations */ > gtk-stock-style-indent-large.GtkBox { indent first widget by X pixels } > > /* GtkTable theming for large indentations */ > gtk-stock-style-indent-large.GtkTable { indent widget at first > column/row by X pixels } > > I even wonder if the CSS code could be scoped and look more clear: > > /* theming for large indentations */ > gtk-stock-style-indent-large { > GtkBox { indent first widget by X pixels } > GtkTable { indent widget at first column/row by X pixels } > } That wouldn't work, but in an ideal world you would get away with something like .gtk-stock-style-indent-large { margin-left: 12px; } > This approach would make it more clear, that its the tables and boxes > that appear in the "indent-large" tag that we are theming, the other > way around makes it look like theming widgets hardcoded by class is > standard and that "gtk-stock-style-main-toolbar" is some kind of special > case only for toolbars (for instance, a theme that handles toolbars might > effect toolitems or even theoretically menuitems in the main toolbar by > virtue of being in the "main-toolbar" tag, the fact that there is a GtkToolbar > instance in the "main-toolbar" area is only a detail). A toolbar item in the main toolbar would be addressed like .gtk-stock-style-main-toolbar GtkToolItem { ... } > The design we need makes a clean separation between the application > and the theme, the theme is like a hypothetical palette of symbolic > names that needs to eventually cover all of our needs, every time the theme > modifies a widget - it has to be because the application developer intended > the theme to modify it in some way (GtkDialogs and other composite widgets > would setup indentations and other spacing tags from the theme onto its > internal children instead of setting up spacing pixels directly). > > Also, about exposing the position in GtkContainer, personally I think > "position" should stay a detail of GtkBox, GtkMenuShell, GtkToolBar, > I think that when accessing the position of a GtkTable its best to use > the row/column - not sure if/how "position" can just make sense or > be useful on just any container. A container that has no notion of position (maybe like GtkFixed) could return -1 for each child, so the CSS subsystem would know to ignore it and not apply any positional selectors like ":first-child" and friends. - Rob _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
