Re: Thoughts on GTK+ and CSS



On Fri, Jul 31, 2009 at 7:28 PM, Tristan Van Berkom<tvb 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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]