Re: Thoughts on GTK+ and CSS
2009/8/5 Robert Staudinger robert.staudin...@gmail.com: On Tue, Aug 4, 2009 at 1:08 AM, Tristan Van Berkomt...@gnome.org wrote: [...] I think half of that complexity is certainly needed, and the other half can be reliably introspected. For instance: a.) I think its necessary for a customized composite widget author to be able to mark a vbox as an itemized list, which directly translates to: its wrong to assume a GtkBox contains an itemized list of widgets, and its bad design to write code that tries to guess that information by casing the types in the hierarchy. b.) I think its not important to specifically have the GtkBox mark the first or last child as first or left or top, if the positional information needed to layout the contents of a GtkBox can be introspected with consistent results. Also, Christian suggested that we expose read-only child properties specifically for use in the theme engine, this would work but IMO would be equivalent to assigning some theme tag data to the child widgets of a container, i.e. it would be code written in the GtkContainer implementation dictating how the theme should handle the child widgets. Either way would work well, also, it would be possible to instead introspect the packing at runtime reliably by listing the children of a container and comparing their coordinates to eachother relative to the parent container, thus deriving virtual row/column information. The problems I see with the current gtkrc/GtkStyle is only the guesswork thats done on the classes directly, this causes apps to be written more rigidly to cooperate with the theme and I also think GTK+ application layouts can potentially be pretty complex and definitely have needs that span beyond every GtkEntry looks like this. To fix these limitations I think its necessary to add a level of abstraction across the board, that allows the application to define what is the style to be used for a widget or container and also allows the theme to define classes that suit an idea from a list of stock items that would be required to implement the base GTK+ theme. In an ideal world, only a composite/specialized widget would have some theme data defined, and a GtkButton, GtkEntry or GtkComboBox would always come out reliably naked and unthemed - unless a style has been explicitly set for that widget, or unless you place the GtkButton in an itemized list or a dialog action area, the effect of adding a GtkEntry to a spreadsheet area might be different than the effect of setting a GtkEntry to be of the style urlbar or password. It seems we are looking at the issues from a different angle. I think all gtk should do is expose a DOM that the future CSS subsystem can match against. Then there could be a gnome-hig.css that when loaded sets HIG compliant paddings and spacing like the standard group indent you mentioned. I sort of agree here, I don't think we should support the full DOM API though, just enough for CSS to do its job. On the other hand, anything we do to represent an abstract scenegraph and poke properties could potentially be shared by the accessibility bridge (gail) which would be a big win IMHO. That would avoid putting semantics into gtk proper that are not applicable to all platforms (desktop, embedded, whatever) or might go stale in the future. - Rob ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Thoughts on GTK+ and CSS
On Mon, Aug 3, 2009 at 12:39 AM, Christian Dywanchrist...@lanedo.com wrote: [...] I wonder what the API might look like. gtk_container_get_child_position (GtkContainer* container, GtkWidget* child, gint* row, gint* column); gtk_container_get_child_at (container, child, row, column); Can we assume that any container either lines up its children in one row or in 2 dimensions? Do we need or want to take into account the concept of primary and secondary children in boxes in the context? If we emulated an html table DOM we might get away with a single dimension. In html the cells are children of the row element, so e.g. td:first-child applies to each first cell in a row. That would also facilitate the position as container child property I mentioned earlier. - Rob ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Thoughts on GTK+ and CSS
On Tue, Aug 4, 2009 at 1:08 AM, Tristan Van Berkomt...@gnome.org wrote: [...] I think half of that complexity is certainly needed, and the other half can be reliably introspected. For instance: a.) I think its necessary for a customized composite widget author to be able to mark a vbox as an itemized list, which directly translates to: its wrong to assume a GtkBox contains an itemized list of widgets, and its bad design to write code that tries to guess that information by casing the types in the hierarchy. b.) I think its not important to specifically have the GtkBox mark the first or last child as first or left or top, if the positional information needed to layout the contents of a GtkBox can be introspected with consistent results. Also, Christian suggested that we expose read-only child properties specifically for use in the theme engine, this would work but IMO would be equivalent to assigning some theme tag data to the child widgets of a container, i.e. it would be code written in the GtkContainer implementation dictating how the theme should handle the child widgets. Either way would work well, also, it would be possible to instead introspect the packing at runtime reliably by listing the children of a container and comparing their coordinates to eachother relative to the parent container, thus deriving virtual row/column information. The problems I see with the current gtkrc/GtkStyle is only the guesswork thats done on the classes directly, this causes apps to be written more rigidly to cooperate with the theme and I also think GTK+ application layouts can potentially be pretty complex and definitely have needs that span beyond every GtkEntry looks like this. To fix these limitations I think its necessary to add a level of abstraction across the board, that allows the application to define what is the style to be used for a widget or container and also allows the theme to define classes that suit an idea from a list of stock items that would be required to implement the base GTK+ theme. In an ideal world, only a composite/specialized widget would have some theme data defined, and a GtkButton, GtkEntry or GtkComboBox would always come out reliably naked and unthemed - unless a style has been explicitly set for that widget, or unless you place the GtkButton in an itemized list or a dialog action area, the effect of adding a GtkEntry to a spreadsheet area might be different than the effect of setting a GtkEntry to be of the style urlbar or password. It seems we are looking at the issues from a different angle. I think all gtk should do is expose a DOM that the future CSS subsystem can match against. Then there could be a gnome-hig.css that when loaded sets HIG compliant paddings and spacing like the standard group indent you mentioned. That would avoid putting semantics into gtk proper that are not applicable to all platforms (desktop, embedded, whatever) or might go stale in the future. - Rob ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Thoughts on GTK+ and CSS
On Wed, Aug 5, 2009 at 12:09 PM, Robert
Staudingerrobert.staudin...@gmail.com wrote:
[...]
It seems we are looking at the issues from a different angle.
Yes, which is why I am still here :)
I think all gtk should do is expose a DOM that the future CSS
subsystem can match against. Then there could be a gnome-hig.css that
when loaded sets HIG compliant paddings and spacing like the standard
group indent you mentioned.
That would avoid putting semantics into gtk proper that are not
applicable to all platforms (desktop, embedded, whatever) or might go
stale in the future.
I already expressed it enough that the only thing I think that can save
us from unpredictable results, is a clean set of semantics for it.
When I look at HTML, there is text and images and dividers, the CSS
doesnt assume anything about the HTML elements by virtue of
them being a piece of text, or an image embedded in text - its always
done by strictly making an association to a class in the css file;
i.e. h1,h2 etc.
GTK+ is a much richer set of screen elements than just text, images
and dividers - the widget classes themselves can be comparable to
the elements you can find in an HTML document, the only thing missing
here is only the symbolic h1/h2 etc semantics needed to complete the
circle, i.e. transmit to the theme what was intended to be done with
this text or this image.
Without any semantics to be use to transmit the intent of the application
writer, how do propose to actually implement the casing code that decides
what GtkBox is an itemized list ?
Will you just assume that buttons inside a GtkBox are itemized ?
What if there are intermediate alignments ?
What if I have a GtkVBox { GtkMenuBar, GtkTable, GtkButton }, will
my button have an accidental rounded bottom ?
Im very curious about how the theme engine is at all expected to
operate without any hinting.
Regards,
-Tristan
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Thoughts on GTK+ and CSS
On Wed, Aug 5, 2009 at 12:44 PM, Tristan Van Berkomt...@gnome.org wrote: On Wed, Aug 5, 2009 at 12:09 PM, Robert Staudingerrobert.staudin...@gmail.com wrote: [...] It seems we are looking at the issues from a different angle. Yes, which is why I am still here :) Sorry to sound plaintive, I dont want to transmit the wrong message here, Im only trying to point out the failures I see in the current theme engine, and trying to help figure out a path to fix those issues. Im curious, if a possible new theme engine for GTK+ doesnt address these fundamental issues, then what advantage does it have over the old gtkrc format ? Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Thoughts on GTK+ and CSS
On Fri, Jul 31, 2009 at 7:28 PM, Tristan Van Berkomt...@gnome.org wrote: [...] Ofcourse, great example - the way I would suggest implementing this is a.) we recognize the need to show itemized groups b.) we define GTK_STOCK_STYLE_ITEM_GROUP c.) we allow some customized containers define themselves as itemized groups: - Base container classes would not be itemized groups, this would obstruct the programmer - Classes like GtkButtonBox for instance could be an itemized group - or GtkMenuShell - Classes that define themselves or their children as styled widgets are always higher level composite widgets or special purpose widgets. Then, the implemented CSS style for an item group would also cover GtkBox, allowing GtkBox to be styled as an itemized group, but not be one by nature, allowing programmers to implement their own treeviews and column headers for example - and still leverage the itemized group definitions from the theme. Is that complexity really needed? Details below. [...] Is it important that the CSS subsystem have this data directly from GtkContainer ? For instance, there really is not many classes with positional data; and the positional data can vary depending on the container type, GtkBin doesnt have positional data - so would it represent much work to handle the position data only for GtkBox, GtkMenuShell and GtkToolBar instead of on the GtkContainer ? I would also expect that the nature of what the CSS subsystem is doing with a GtkTable is going to be all together different, and you probably wont want a position at all (i.e. you might want to know all the widgets that are on top, or on the left), and the position of a page in a notebook is well, entirely different ;-) I really have no idea how the css subsystem is implemented and I am probably overlooking some things; only it seems to me, if only for the sake of OO purity and api clarity; that the position property doesnt really mean anything for the GtkContainer class itself. HTML applies CSS on the DOM tree, thus positional pseudo classes like :first-child don't imply any semantics -- it's just the first element below the parent node. So I think it would be valid for containers that don't really have a notion of order (e.g. GtkFixed) to just match the first child of their internal list of children. - Rob ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Thoughts on GTK+ and CSS
On Mon, Aug 3, 2009 at 3:34 AM, Robert Staudingerrobert.staudin...@gmail.com wrote: On Fri, Jul 31, 2009 at 7:28 PM, Tristan Van Berkomt...@gnome.org wrote: [...] [...] Then, the implemented CSS style for an item group would also cover GtkBox, allowing GtkBox to be styled as an itemized group, but not be one by nature, allowing programmers to implement their own treeviews and column headers for example - and still leverage the itemized group definitions from the theme. Is that complexity really needed? Details below. [...] HTML applies CSS on the DOM tree, thus positional pseudo classes like :first-child don't imply any semantics -- it's just the first element below the parent node. So I think it would be valid for containers that don't really have a notion of order (e.g. GtkFixed) to just match the first child of their internal list of children. I think half of that complexity is certainly needed, and the other half can be reliably introspected. For instance: a.) I think its necessary for a customized composite widget author to be able to mark a vbox as an itemized list, which directly translates to: its wrong to assume a GtkBox contains an itemized list of widgets, and its bad design to write code that tries to guess that information by casing the types in the hierarchy. b.) I think its not important to specifically have the GtkBox mark the first or last child as first or left or top, if the positional information needed to layout the contents of a GtkBox can be introspected with consistent results. Also, Christian suggested that we expose read-only child properties specifically for use in the theme engine, this would work but IMO would be equivalent to assigning some theme tag data to the child widgets of a container, i.e. it would be code written in the GtkContainer implementation dictating how the theme should handle the child widgets. Either way would work well, also, it would be possible to instead introspect the packing at runtime reliably by listing the children of a container and comparing their coordinates to eachother relative to the parent container, thus deriving virtual row/column information. The problems I see with the current gtkrc/GtkStyle is only the guesswork thats done on the classes directly, this causes apps to be written more rigidly to cooperate with the theme and I also think GTK+ application layouts can potentially be pretty complex and definitely have needs that span beyond every GtkEntry looks like this. To fix these limitations I think its necessary to add a level of abstraction across the board, that allows the application to define what is the style to be used for a widget or container and also allows the theme to define classes that suit an idea from a list of stock items that would be required to implement the base GTK+ theme. In an ideal world, only a composite/specialized widget would have some theme data defined, and a GtkButton, GtkEntry or GtkComboBox would always come out reliably naked and unthemed - unless a style has been explicitly set for that widget, or unless you place the GtkButton in an itemized list or a dialog action area, the effect of adding a GtkEntry to a spreadsheet area might be different than the effect of setting a GtkEntry to be of the style urlbar or password. Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Thoughts on GTK+ and CSS
Am Fri, 31 Jul 2009 13:28:02 -0400
schrieb Tristan Van Berkom t...@gnome.org:
On Fri, Jul 31, 2009 at 12:47 PM, Robert
Staudingerrobert.staudin...@gmail.com wrote:
On Fri, Jul 31, 2009 at 6:19 PM, Tristan Van Berkomt...@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
Ofcourse, great example - the way I would suggest implementing this is
a.) we recognize the need to show itemized groups
b.) we define GTK_STOCK_STYLE_ITEM_GROUP
c.) we allow some customized containers define themselves as
itemized groups:
- Base container classes would not be itemized groups, this
would obstruct the programmer
- Classes like GtkButtonBox for instance could be an itemized
group - or GtkMenuShell
- Classes that define themselves or their children as styled
widgets are always higher level
composite widgets or special purpose widgets.
Then, the implemented CSS style for an item group would also cover
GtkBox, allowing
GtkBox to be styled as an itemized group, but not be one by nature,
allowing programmers
to implement their own treeviews and column headers for example - and
still leverage
the itemized group definitions from the theme.
[...]
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; }
Sounds awesome.
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 { ... }
Also awesome :)
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.
Is it important that the CSS subsystem have this data directly from
GtkContainer ?
For instance, there really is not many classes with positional data;
and the positional data can vary depending on the container type,
GtkBin doesnt have positional data - so would it represent much work
to handle the position data only for GtkBox, GtkMenuShell and
GtkToolBar instead of on the GtkContainer ?
I would also expect that the nature of what the CSS subsystem is doing
with a GtkTable is going to be all together different, and you
probably wont want a position at all (i.e. you might want to know all
the widgets that are on top, or on the left), and the position of a
page in a notebook is well, entirely different ;-)
I really have no idea how the css subsystem is implemented and I am
probably overlooking some things; only it seems to me, if only for the
sake of OO purity and api clarity; that the position property
doesnt really mean anything for the GtkContainer class itself.
I suspect the CSS will not want to special case each type of container
in GTK+, let alone third party libraries and applications. So
implementing a notion of positioning has to be at the GtkContainer
level.
ciao,
Christian
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Thoughts on GTK+ and CSS
Am Fri, 31 Jul 2009 10:33:41 +0200 schrieb Robert Staudinger robert.staudin...@gmail.com: On Thu, Jul 30, 2009 at 4:37 PM, Christian Dywanchrist...@lanedo.com wrote: [...] You are probably aware that gtk_container_get_children () does give yo the positions of children. Assuming that the lack of guarantees about order of widgets in a container is the actual problem, maybe this can be reconsidered. There was a bug I can't find right now suggesting a policy for this containers would be recommended to follow. We probably mean the same. GtkTable for example simply g_list_prepend()s in gtk_table_attach() -- thus I would just not use the word position here. That said, does it sound entirely off to gtk veterans trying to implement widget position as a read-only container child property? Sticking to the table example above -- a table child's position could easily be calculated using row (-count) and column (-count). From a quick look over the code this might not be quite as easy for box widgets, but maybe the child position could be calculated in the allocate() run and cached inside GtkBoxChild. I wonder what the API might look like. gtk_container_get_child_position (GtkContainer* container, GtkWidget*child, gint* row, gint* column); gtk_container_get_child_at (container, child, row, column); Can we assume that any container either lines up its children in one row or in 2 dimensions? Do we need or want to take into account the concept of primary and secondary children in boxes in the context? ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Thoughts on GTK+ and CSS
On Thu, Jul 30, 2009 at 7:06 PM, Tristan Van Berkomt...@gnome.org wrote:
[...]
An example of the backwardness we have in place, is that,
IMO its simply wrong to assume the role of a GtkToolbar in a
given application, the toolbar already needs properties to override
theme settings in cases where its not in context. Another example
would be that you simply cant write a custom toolbar implementation
and inherit the theme of a toolbar unless you actually subclass the
GtkToolbar.
This is a good point. The most natural mapping to CSS would probably
be using a set of CSS classes [1] defined by gtk.
Then GTK+ could have a list of stock styles:
#define GTK_STOCK_STYLE_MAIN_TOOLBAR gtk-stock-style-main-toolbar
Agreed (whatever the actual name). The theming would then go like
GtkToolbar { ... } /* Common theming for all toolbars */
GtkToolbar.gtk-stock-style-main-toolbar { ... } /* Additional theming
for main toolbar. */
#define GTK_STOCK_STYLE_SMALL_BORDER gtk-stock-style-small-border
#define GTK_STOCK_STYLE_LARGE_BORDER gtk-stock-style-large-border
Not sure what those would be for.
#define GTK_STOCK_STYLE_FIRST_ITEM gtk-stock-style-first-item
#define GTK_STOCK_STYLE_LAST_ITEM gtk-stock-style-last-item
Might not be needed since CSS defines positional pseudo classes
already [2]. We should be able to get the child position from the
GtkContainer, also see the related messages in this thread.
[...]
[1] http://www.w3.org/TR/CSS21/selector.html#class-html
[2] http://www.w3.org/TR/CSS21/selector.html#pseudo-class-selectors
- Rob
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Thoughts on GTK+ and CSS
On Thu, Jul 30, 2009 at 4:37 PM, Christian Dywanchrist...@lanedo.com wrote: [...] You are probably aware that gtk_container_get_children () does give yo the positions of children. Assuming that the lack of guarantees about order of widgets in a container is the actual problem, maybe this can be reconsidered. There was a bug I can't find right now suggesting a policy for this containers would be recommended to follow. We probably mean the same. GtkTable for example simply g_list_prepend()s in gtk_table_attach() -- thus I would just not use the word position here. That said, does it sound entirely off to gtk veterans trying to implement widget position as a read-only container child property? Sticking to the table example above -- a table child's position could easily be calculated using row (-count) and column (-count). From a quick look over the code this might not be quite as easy for box widgets, but maybe the child position could be calculated in the allocate() run and cached inside GtkBoxChild. - Rob ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Thoughts on GTK+ and CSS
On Fri, Jul 31, 2009 at 4:15 AM, Robert
Staudingerrobert.staudin...@gmail.com wrote:
On Thu, Jul 30, 2009 at 7:06 PM, Tristan Van Berkomt...@gnome.org wrote:
[...]
An example of the backwardness we have in place, is that,
IMO its simply wrong to assume the role of a GtkToolbar in a
given application, the toolbar already needs properties to override
theme settings in cases where its not in context. Another example
would be that you simply cant write a custom toolbar implementation
and inherit the theme of a toolbar unless you actually subclass the
GtkToolbar.
This is a good point. The most natural mapping to CSS would probably
be using a set of CSS classes [1] defined by gtk.
Then GTK+ could have a list of stock styles:
#define GTK_STOCK_STYLE_MAIN_TOOLBAR gtk-stock-style-main-toolbar
Agreed (whatever the actual name). The theming would then go like
GtkToolbar { ... } /* Common theming for all toolbars */
GtkToolbar.gtk-stock-style-main-toolbar { ... } /* Additional theming
for main toolbar. */
#define GTK_STOCK_STYLE_SMALL_BORDER gtk-stock-style-small-border
#define GTK_STOCK_STYLE_LARGE_BORDER gtk-stock-style-large-border
Not sure what those would be for.
Maybe indent would be a better name than border; the idea is basically
to circumvent the possibility of boxes and tables comming up with any
undesired margins or indentations.
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.
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 }
}
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).
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.
Cheers,
-Tristan
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Thoughts on GTK+ and CSS
On Fri, Jul 31, 2009 at 6:19 PM, Tristan Van Berkomt...@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
Re: Thoughts on GTK+ and CSS
On Fri, Jul 31, 2009 at 12:47 PM, Robert
Staudingerrobert.staudin...@gmail.com wrote:
On Fri, Jul 31, 2009 at 6:19 PM, Tristan Van Berkomt...@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
Ofcourse, great example - the way I would suggest implementing this is
a.) we recognize the need to show itemized groups
b.) we define GTK_STOCK_STYLE_ITEM_GROUP
c.) we allow some customized containers define themselves as itemized groups:
- Base container classes would not be itemized groups, this
would obstruct the programmer
- Classes like GtkButtonBox for instance could be an itemized
group - or GtkMenuShell
- Classes that define themselves or their children as styled
widgets are always higher level
composite widgets or special purpose widgets.
Then, the implemented CSS style for an item group would also cover
GtkBox, allowing
GtkBox to be styled as an itemized group, but not be one by nature,
allowing programmers
to implement their own treeviews and column headers for example - and
still leverage
the itemized group definitions from the theme.
[...]
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; }
Sounds awesome.
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 { ... }
Also awesome :)
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.
Is it important that the CSS subsystem have this data directly from
GtkContainer ?
For instance, there really is not many classes with positional data;
and the positional data can vary depending on the container type,
GtkBin doesnt have positional data - so would it represent much work to
handle the position data only for GtkBox, GtkMenuShell and GtkToolBar
instead of on the GtkContainer ?
I would also expect that the nature of what the CSS subsystem is doing
with a GtkTable is going to be all together different, and you probably wont
want a position at all (i.e. you might want to know all the widgets that
are on top, or on the left), and the position of a page in a notebook is well,
entirely different ;-)
I really have no idea how the css subsystem is implemented and I am
probably overlooking some things; only it seems to me, if only for the
sake of OO purity and api clarity; that the position property doesnt really
mean anything for the GtkContainer class itself.
Cheers,
-Tristan
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Thoughts on GTK+ and CSS
Am Tue, 28 Jul 2009 08:45:26 +0200 schrieb Robert Staudinger robert.staudin...@gmail.com: On Tue, Jul 28, 2009 at 3:40 AM, Keith Rarickk...@xph.us wrote: [...] The margin property in gtk is not implemented like you assume above. Also does GtkContainer not expose information about child widget positions like you suggest using :first-child and friends. Work on those limitations would break the way for more a more comprehensive mapping of css onto gtk. Okay. I only meant that example to suggest what a theme could do in principle, even if it uses features that don't exist yet. Would you accept a patch with work toward those things, such as margin or first-child? If there way a way to get the position of a child in a GtkContainer (thus allowing for :first-child and other positional pseudo classes to be implemented) that would make quite a difference in what you can do with the css engine. I'm not in the position to make the call on gtk patches though. You are probably aware that gtk_container_get_children () does give yo the positions of children. Assuming that the lack of guarantees about order of widgets in a container is the actual problem, maybe this can be reconsidered. There was a bug I can't find right now suggesting a policy for this containers would be recommended to follow. Regards, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Thoughts on GTK+ and CSS
Am Mon, 27 Jul 2009 18:40:41 -0700 schrieb Keith Rarick k...@xph.us: The margin property in gtk is not implemented like you assume above. Also does GtkContainer not expose information about child widget positions like you suggest using :first-child and friends. Work on those limitations would break the way for more a more comprehensive mapping of css onto gtk. Okay. I only meant that example to suggest what a theme could do in principle, even if it uses features that don't exist yet. Would you accept a patch with work toward those things, such as margin or first-child? Many people, including me, would like margin and padding for use in applications, you may want to consider that when looking into the theme side of it. Currently gtk_container_set_border_width, gtk_box_set_child_spacing and gtk_misc_set_padding are what comes closest to that on the application side. Regards, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Thoughts on GTK+ and CSS
On Tue, Jul 28, 2009 at 2:45 AM, Robert Staudingerrobert.staudin...@gmail.com wrote: On Tue, Jul 28, 2009 at 3:40 AM, Keith Rarickk...@xph.us wrote: [...] What you describe addresses the separation of semantic structure from presentation, but that approach is far more powerful if the semantic information is sufficiently rich and sufficiently general. Currently, writing a gtk theme feels like styling an html document made of nothing but div and span and some id attributes. I want it to feel like styling p, h1, nav, section, article, dl, blockquote, etc, with lots of useful classes too. Picking a next button by stock ID is too specific. For example, what if an app has a new group of related buttons, say local view and remote view, not accounted for by existing themes that only pick buttons by their stock ID? There is no way to get the proper look for that group of buttons. Furthermore, how would a theme distinguish a solitary next button from one that is part of a prev/pause/next group? A theme might legitimately want those two next buttons to look different, but I don't see how it can be achieved reliably. Perhaps a hints property is flawed in detail, but I think the idea is sound. I advocate denoting *well-defined* but *generic* semantic structure. Here is roughly the reasoning I used for the related hint: * A theme might want to display prev/pause/next buttons in a visually distinct group. * A theme might also do that with icon/list/compact view buttons or back/forward buttons or some other as-yet-unknown set of buttons. * What semantic properties do all of those examples share? * They are all groups of buttons somehow related to one another in a meaningful way. * This is a useful piece of information for themes. * Unfortunately, there is currently no way to express this information. * We should invent a way to denote this. I had similar lines of reasoning for the other example hints I listed. But maybe they should be handled on a case-by-case basis. Say, make up a new property for each one. I didn't suggest that because I thought it would have too much inertia. I want it to be easy for people to add new semantic structural information to apps -- the more the better! I think gtk(-2.x) theming will always just be the icing on top of apps that have to be well designed themselves. The hierarchy and ordering inflicted by box widgets and friends is much more constrained than, say, an HTML DOM. To relate to your example of grouping prev/next/pause buttons in a media player -- the way to do that would be writing application-specific CSS that modifies a dialog precisely how you want it to look. Pixel perfection just doesn't come for free. The margin property in gtk is not implemented like you assume above. Also does GtkContainer not expose information about child widget positions like you suggest using :first-child and friends. Work on those limitations would break the way for more a more comprehensive mapping of css onto gtk. Okay. I only meant that example to suggest what a theme could do in principle, even if it uses features that don't exist yet. Would you accept a patch with work toward those things, such as margin or first-child? If there way a way to get the position of a child in a GtkContainer (thus allowing for :first-child and other positional pseudo classes to be implemented) that would make quite a difference in what you can do with the css engine. I'm not in the position to make the call on gtk patches though. Best, Rob ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Thoughts on GTK+ and CSS
Hi, I think its really exciting that you guys are working on this, so I stole the time this morning to share in the fun... I just want to throw out some ideas that Im sure are not new, but I was surprised werent really addressed yet in this thread. Im really not versed in what can/cant should/shouldnt be done with CSS, so maybe my ideas are totally off mark in that regard, other than that lets get into the juice ;-) I think that the biggest problem with GtkStyle/gtkrc is that we have been theming applications by widget class, I think that if we are going to finally upgrade theming, this would need to stop. As Christian says, developers need to layout the spacing of the application - and ofcourse - theme writers need to augment/change the palette used to space the application etc. An example of the backwardness we have in place, is that, IMO its simply wrong to assume the role of a GtkToolbar in a given application, the toolbar already needs properties to override theme settings in cases where its not in context. Another example would be that you simply cant write a custom toolbar implementation and inherit the theme of a toolbar unless you actually subclass the GtkToolbar. Heres a vague outline of a relatively simple implementation that would get the job done, it would be up to the CSS gods to decide if it were right, but it would get the job done. Like any solution to a feature we never implemented before, we would have to add API: void gtk_widget_add_style (GtkWidget *widget, const gchar *style_id); A style would ofcourse cascade through the widget hierarchy, so adding a style to a container would effect all the children. Then GTK+ could have a list of stock styles: #define GTK_STOCK_STYLE_MAIN_TOOLBAR gtk-stock-style-main-toolbar #define GTK_STOCK_STYLE_DIALOG_MAIN_AREA gtk-stock-style-main-toolbar #define GTK_STOCK_STYLE_SMALL_BORDER gtk-stock-style-small-border #define GTK_STOCK_STYLE_LARGE_BORDER gtk-stock-style-large-border #define GTK_STOCK_STYLE_FIRST_ITEMgtk-stock-style-first-item #define GTK_STOCK_STYLE_LAST_ITEM gtk-stock-style-last-item (the details of this list would be a lengthly review process and probably as such represents the most work in this hypothetical implementation) ... Applications that are well themable would be discouraged from using GTK+ apis that effect the spacing directly, developers would be encouraged to use symbolic styles to define the look of thier applications. On the CSS side things would look almost the same, you would define style properties per widget class inside a specified tag (or style name), so all buttons defined inside a first-item tag would recieve the first-item GtkButtonClass sugar. And ofcourse, customized applications that use thier own CSS can derive elements from the theme and use style definitions that arent defined in the GTK+ stock list. Oh yeah, backwards compatability, well we could leave in the theming widgets by class name only and slowly migrate, theres not much to break anyway, just a hope to offer real theming capabilities in the future. Anyway that was my take, I hope its useful ;-) Cheers, -Tristan On Tue, Jul 28, 2009 at 2:45 AM, Robert Staudingerrobert.staudin...@gmail.com wrote: On Tue, Jul 28, 2009 at 3:40 AM, Keith Rarickk...@xph.us wrote: [...] What you describe addresses the separation of semantic structure from presentation, but that approach is far more powerful if the semantic information is sufficiently rich and sufficiently general. Currently, writing a gtk theme feels like styling an html document made of nothing but div and span and some id attributes. I want it to feel like styling p, h1, nav, section, article, dl, blockquote, etc, with lots of useful classes too. Picking a next button by stock ID is too specific. For example, what if an app has a new group of related buttons, say local view and remote view, not accounted for by existing themes that only pick buttons by their stock ID? There is no way to get the proper look for that group of buttons. Furthermore, how would a theme distinguish a solitary next button from one that is part of a prev/pause/next group? A theme might legitimately want those two next buttons to look different, but I don't see how it can be achieved reliably. Perhaps a hints property is flawed in detail, but I think the idea is sound. I advocate denoting *well-defined* but *generic* semantic structure. Here is roughly the reasoning I used for the related hint: * A theme might want to display prev/pause/next buttons in a visually distinct group. * A theme might also do that with icon/list/compact view buttons or back/forward buttons or some other as-yet-unknown set of buttons. * What semantic properties do all of those examples share? * They are all groups of buttons somehow related to one another in a meaningful way. * This is a useful piece of information for themes. * Unfortunately, there is
Re: Thoughts on GTK+ and CSS
2009/7/30 Christian Dywan christ...@lanedo.com: Am Tue, 28 Jul 2009 08:45:26 +0200 schrieb Robert Staudinger robert.staudin...@gmail.com: On Tue, Jul 28, 2009 at 3:40 AM, Keith Rarickk...@xph.us wrote: [...] The margin property in gtk is not implemented like you assume above. Also does GtkContainer not expose information about child widget positions like you suggest using :first-child and friends. Work on those limitations would break the way for more a more comprehensive mapping of css onto gtk. Okay. I only meant that example to suggest what a theme could do in principle, even if it uses features that don't exist yet. Would you accept a patch with work toward those things, such as margin or first-child? If there way a way to get the position of a child in a GtkContainer (thus allowing for :first-child and other positional pseudo classes to be implemented) that would make quite a difference in what you can do with the css engine. I'm not in the position to make the call on gtk patches though. You are probably aware that gtk_container_get_children () does give yo the positions of children. Assuming that the lack of guarantees about order of widgets in a container is the actual problem, maybe this can be reconsidered. There was a bug I can't find right now suggesting a policy for this containers would be recommended to follow. That sort of works for a widget instance, but doesn't work generically when you're painting a pseudoelement, for example, a notebook tab. I'm all ears if someone suggests a sane fix for this. Regards, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Thoughts on GTK+ and CSS
On Tue, Jul 28, 2009 at 3:40 AM, Keith Rarickk...@xph.us wrote: [...] What you describe addresses the separation of semantic structure from presentation, but that approach is far more powerful if the semantic information is sufficiently rich and sufficiently general. Currently, writing a gtk theme feels like styling an html document made of nothing but div and span and some id attributes. I want it to feel like styling p, h1, nav, section, article, dl, blockquote, etc, with lots of useful classes too. Picking a next button by stock ID is too specific. For example, what if an app has a new group of related buttons, say local view and remote view, not accounted for by existing themes that only pick buttons by their stock ID? There is no way to get the proper look for that group of buttons. Furthermore, how would a theme distinguish a solitary next button from one that is part of a prev/pause/next group? A theme might legitimately want those two next buttons to look different, but I don't see how it can be achieved reliably. Perhaps a hints property is flawed in detail, but I think the idea is sound. I advocate denoting *well-defined* but *generic* semantic structure. Here is roughly the reasoning I used for the related hint: * A theme might want to display prev/pause/next buttons in a visually distinct group. * A theme might also do that with icon/list/compact view buttons or back/forward buttons or some other as-yet-unknown set of buttons. * What semantic properties do all of those examples share? * They are all groups of buttons somehow related to one another in a meaningful way. * This is a useful piece of information for themes. * Unfortunately, there is currently no way to express this information. * We should invent a way to denote this. I had similar lines of reasoning for the other example hints I listed. But maybe they should be handled on a case-by-case basis. Say, make up a new property for each one. I didn't suggest that because I thought it would have too much inertia. I want it to be easy for people to add new semantic structural information to apps -- the more the better! I think gtk(-2.x) theming will always just be the icing on top of apps that have to be well designed themselves. The hierarchy and ordering inflicted by box widgets and friends is much more constrained than, say, an HTML DOM. To relate to your example of grouping prev/next/pause buttons in a media player -- the way to do that would be writing application-specific CSS that modifies a dialog precisely how you want it to look. Pixel perfection just doesn't come for free. The margin property in gtk is not implemented like you assume above. Also does GtkContainer not expose information about child widget positions like you suggest using :first-child and friends. Work on those limitations would break the way for more a more comprehensive mapping of css onto gtk. Okay. I only meant that example to suggest what a theme could do in principle, even if it uses features that don't exist yet. Would you accept a patch with work toward those things, such as margin or first-child? If there way a way to get the position of a child in a GtkContainer (thus allowing for :first-child and other positional pseudo classes to be implemented) that would make quite a difference in what you can do with the css engine. I'm not in the position to make the call on gtk patches though. Best, Rob ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Thoughts on GTK+ and CSS
Hello,
On Sat, Jul 25, 2009 at 2:04 AM, Keith Rarickk...@xph.us wrote:
I saw some discussion a while back [1] about using CSS for gtk themes
in the future. Now I have some ideas about that. My apologies if this
isn't the right time or place.
## Pseudo-element Selectors
Last I heard, the best way to represent pieces of complex widgets in
CSS is still being discussed. For example, a GtkNotebook has several
tabs, one of which is in the foreground, but they are not actually
widgets. This is exactly what CSS pseudo-element selectors were
designed for.
An analogy: in CSS3, p::first-line selects a meaningful thing that has
no node in the document tree [2]. Similarly, a gtk notebook tab is a
meaningful thing that has no node in the widget hierarchy.
GtkNotebook::tab {
padding: 2px 5px;
}
The limitation regarding pseudo elements is not that we aren't aware
of their existence, but that libcroco doesn't support them at this
point.
This also plays nicely with pseudo-class selectors:
GtkNotebook::tab:foreground {
font-weight: bold;
}
What is :foreground supposed to mean?
## Mapping Properties into CSS
To some extent, GTK _properties_ could be mapped into CSS just at XML
_attributes_ are.
This is already implemented.
Further, just as XML treats the class attribute as a space-separated
list of words to be selected via CSS dot-notation, gtk can usefully
treat some property in the same way. (I'd suggest a new property named
hints -- see below.)
## Richness of semantic structure
On the web, most designers control both semantic structure (in HTML)
and presentation (in CSS). This means they never have to worry about
sufficient semantic richness. If they need to target a particular
element or set of elements, they can just decorate the HTML with some
ids or classes. I think the success of CSS on the web is in no small
part due to this fact.
By contrast, the job of a gtk theme author is harder. Theme authors
only get to specify the presentation; they rely entirely on app
authors for semantic structure.
To me, this suggests that applications and gtk should provide generous
quantities of semantic information in the app, giving theme authors
more hooks.
So let's consider adding hints to widgets. A hint is like a tag on
delicious. It's intended to convey some meaningful property of the
widget that is independent of its type or location in the hierarchy.
They can be represented as a space-separated list of words in a widget
property called hints, as described above.
Some possible hints:
* related
This group (for example, an hbox) contains toolbar buttons that are related
or alternatives to one another. For example, a set of back/forward buttons,
or icon/list/compact view buttons, or prev/pause/next buttons.
* urgent
This widget displays urgent information.
* dense
This data-display widget (tree view, text box, etc.) contains a lot of data.
Themes might choose to display that data with smaller text, tighter spacing,
or more grid-fitting (for example).
* sources
This container or widget (tree view, group of radio buttons, whatever) is a
list of data sources for the application's main display.
For example, Mac OS conventionally shows these sources lists with a
light-blue background (in Finder, iTunes, etc.).
To be most successful, these hints must be both rich and consistently applied.
On the bright side, once this system is established, backward and
forward compatibility is no problem. Both theme designers and app
authors can specify new hints at any time without worrying about
fundamentally breaking existing apps or themes.
Also, hints of this style would be really easy to add to an app. It'd
usually be a one-line patch and could be done by someone with very
little C experience. If app maintainers are reasonably liberal about
accepting such patches, it would be feasible for one person to
conceive of a new hint, use it in a theme, and patch all relevant
applications to support it, all in a short time.
I think this approach would be quite hand-wavy and limited. Rather
than aiming to invent vocabulary for vague descriptions we should aim
to
(1) Consistently apply system-wide base styling, e.g. GtkButton.
(2) Specifically refine the styling where needed, e.g. pick
prev/next/pause buttons by their stock ID.
## Putting it together
Here's how a theme might style related toolbar buttons under this system:
GtkToolbar GtkButton {
margin: 0 5px;
border-radius: 2px;
}
GtkToolbar GtkHBox.related GtkButton {
margin: 0;
border-radius: 0;
}
GtkToolbar GtkHBox.related GtkButton:first-child {
margin-left: 5px;
border-radius-left: 2px;
}
GtkToolbar GtkHBox.related GtkButton:last-child {
margin-right: 5px;
border-radius-right: 2px;
}
The margin property in gtk is not implemented like you assume above.
Also does GtkContainer not expose information about child widget
Re: Thoughts on GTK+ and CSS
On Sun, Jul 26, 2009 at 11:41 PM, Robert
Staudingerrobert.staudin...@gmail.com wrote:
The limitation regarding pseudo elements is not that we aren't aware
of their existence, but that libcroco doesn't support them at this
point.
Gotcha. I wonder if libcroco would accept a patch implementing that.
I'll ask on libcroco-list.
This also plays nicely with pseudo-class selectors:
GtkNotebook::tab:foreground {
font-weight: bold;
}
What is :foreground supposed to mean?
Maybe I should have spelled it :selected. In this case I intended it
to mean the tab that is in the foreground and whose contents are
visible. Is it the selected tab? I don't know the proper
terminology.
I just wanted a suggestive example; I didn't mean to presume any
existing functionality.
## Mapping Properties into CSS
To some extent, GTK _properties_ could be mapped into CSS just at XML
_attributes_ are.
This is already implemented.
Wonderful! It seems I am very under-informed. I will look through the
source code.
Rather
than aiming to invent vocabulary for vague descriptions we should aim
to
(1) Consistently apply system-wide base styling, e.g. GtkButton.
(2) Specifically refine the styling where needed, e.g. pick
prev/next/pause buttons by their stock ID.
What you describe addresses the separation of semantic structure from
presentation, but that approach is far more powerful if the semantic
information is sufficiently rich and sufficiently general. Currently,
writing a gtk theme feels like styling an html document made of
nothing but div and span and some id attributes. I want it to feel
like styling p, h1, nav, section, article, dl, blockquote, etc, with
lots of useful classes too. Picking a next button by stock ID is too
specific.
For example, what if an app has a new group of related buttons, say
local view and remote view, not accounted for by existing themes
that only pick buttons by their stock ID? There is no way to get the
proper look for that group of buttons.
Furthermore, how would a theme distinguish a solitary next button from
one that is part of a prev/pause/next group? A theme might
legitimately want those two next buttons to look different, but I
don't see how it can be achieved reliably.
Perhaps a hints property is flawed in detail, but I think the idea
is sound. I advocate denoting *well-defined* but *generic* semantic
structure.
Here is roughly the reasoning I used for the related hint:
* A theme might want to display prev/pause/next buttons in a visually
distinct group.
* A theme might also do that with icon/list/compact view buttons or
back/forward buttons or some other as-yet-unknown set of buttons.
* What semantic properties do all of those examples share?
* They are all groups of buttons somehow related to one another in a
meaningful way.
* This is a useful piece of information for themes.
* Unfortunately, there is currently no way to express this information.
* We should invent a way to denote this.
I had similar lines of reasoning for the other example hints I listed.
But maybe they should be handled on a case-by-case basis. Say, make up
a new property for each one. I didn't suggest that because I thought
it would have too much inertia. I want it to be easy for people to add
new semantic structural information to apps -- the more the better!
The margin property in gtk is not implemented like you assume above.
Also does GtkContainer not expose information about child widget
positions like you suggest using :first-child and friends. Work on
those limitations would break the way for more a more comprehensive
mapping of css onto gtk.
Okay. I only meant that example to suggest what a theme could do in
principle, even if it uses features that don't exist yet.
Would you accept a patch with work toward those things, such as margin
or first-child?
kr
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Thoughts on GTK+ and CSS
You can see progress of the Gtk css engine on a few places : http://blogs.gnome.org/theming/ and of course in git repository : http://git.gnome.org/cgit/gtk-css-engine/ it seems that you can contact Robert Staudinger if you want to help him on this matter. But is work seems already fairly advanced. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
