Hello,
On Sat, Jul 25, 2009 at 2:04 AM, Keith Rarick<k...@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
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.
Best,
Rob
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
