Re: GTK+ Theming improvements
On 9/1/07, Benjamin Berg <[EMAIL PROTECTED]> wrote:
> On Fri, 2007-31-08 at 13:26 +0200, Lieven van der Heide wrote:
> > As for the general rendering of widgets, I think the current way of
> > letting the widget itself do the drawing, using a bunch of primitives
> > (ie. boxes, frames, etc.), and then letting the theme engines theme
> > just those primitives, instead of the whole widget, has shown to not
> > really work. What most theme engines seem to be doing now, is kind of
> > reverse engeneer those draw calls, and then render the theming in
> > their own way, which often is quite different from what the widget
> > actually thought is was drawing.
>
> Most of the time these are special cases as for example making certain
> corners rounded, but true.
>
> > I think it would be better if each widget just has it's own, specific
> > rendering class, which has a single function that should render the
> > complete widget at once. (this way, you kind of get a model/view
> > seperation inside controls). Themes can then override this rendering
> > class, and have complete freedom inside the render function of that
> > rendering class.
>
> This sounds a lot like how QT works (I have not had a very deep look
> though). However I don't think that any system should require build time
> linking. As desktop environments (GNOME, maemo) and/or applications will
> need custom widgets.
I don't really get what you mean with build time linking.
Custom widgets are perfectly possible with this approach. Even more so
than with the current approach. The thing is that the rendering
classes can query any other renderer of other widgets, to which they
forward their rendering. If you for example make a widget that's much
like a treeview, you should still make a specific renderer for that
widget, but make a default implementation that just forwards
everything to the treeview renderer. If a theme does not implement
this new widgets renderer, but it does implement the treeview
renderer, then the theming will still look good on both the treeview,
and on this new widget. If a theme engine decides that it does want to
have separate theming, it can implement the renderer of that new
widget, and render it in a different way completely.
> This is a general problem that I have not brought up earlier. But I
> wonder how to handle one widget that may have two different modes. An
> example that is annoying me right now is the radiobutton. It can not
> only be a drawn as normal radio button with an indicator, but also as a
> button without an indicator (in eg. GtkRadioToolButton).
> In the two different cases you may not only want to have some different
> style for the radiobutton, but also for the widgets (label) inside. I
> think that we either need to remove any case like this, have the
> possibility to style widgets (and their children) based on properties or
> need a second independent representation of the UI for theming.
>
> Hm, I don't see a way right now to handle the connected buttons in a
> button box with this approach nicely.
> http://futurepast.free.fr/buttonbox.png
I think that's pretty much orthogonal to it. It will not solve it, but
it won't prohibit us from using something like that css system for it.
The thing that that css system could do, is to just select the
appropriate renderer, using the appropriate settings, depending on the
widget that's being rendered, and the surroundings of that widget.
Note that a single theme engine can have multiple implementations of
the same renderer class (ie. it can have two button renderers). The
css system can then pick a different renderer if the button is for
example neighboring another button.
>
> > Each renderer should also have a default implementation, which renders
> > the widget in a default way, using lower level rendering classes,
> > which render things like edges and boxes. If a theme engine doesn't
> > implement a specific widget's rendering class, but it did implement
> > the lower level ones, then it will still be rendered using something
> > that fits your theme (basically in the same way it's supposed to work
> > now).
> >
> > It should also be possible for a renderer to use the renderer of
> > another (more basic) widget ,for example, a treeview could use the
> > button renderer as the default renderer for it's column headers.
> >
> > pseudo code for the default renderer of a checkbox:
> >
> > class CheckBoxRenderer
> > {
> > struct Params_s
> > {
> > int state;
> > string label;
> > }
> >
> > virtual void render(GdkDrawable target,Params_s params)
> > {
> > // default implementation that uses the generic renderer
> > GenericRenderer generic_renderer = get_renderer(GENERIC_RENDERER);
> > generic_renderer.render_box(target,Rect(0,0,16,16));
> >
> > if(params.state)
> > {
> >generic_renderer.draw_check(target,Rect(0,0,16,16));
> > }
> >
> > generic_renderer.draw_text(target,Point(24,0),params.label);
> > }
> > }
>
Re: GTK+ Theming improvements
On Sat, 2007-01-09 at 16:32 +0200, Mathias Hasselmann wrote: > Why not use the most obvious solution for the problem: Keep the theming > engine as is, but instead of using one single theming detail string, > let's attach a theming class property in the spirit of CSS class names > to widgets: > > const gchar** gtk_widget_get_style_classes (GtkWidget *widget); > > gboolean gtk_widget_has_style_class (GtkWidget *widget, >const gchar *class_name); > > Well, or for optimal speed let's use GQuarks instead: > > const GQuark* gtk_widget_get_style_classes (GtkWidget *widget); > > gboolean gtk_widget_has_style_class (GtkWidget *widget, >GQuark class_name); > > Now let's add the rule, that widgets have to provide a macro for each > style class they define, and we even get some easy way to document style > classes: > > #define GTK_STYLE_CLASS_TREE_VIEW_COLUMN_BUTTON \ > gtk_style_class_tree_view_column_button_get_quark () > > You might argue defining quarks for this purpose is quite some effort, > but Bugzilla and libegg contain the implementation of a G_DEFINE_QUARK, > respectively EGG_DEFINE_QUARK marco declaring *_get_quark functions: > > G_DEFINE_QUARK (GtkStyleClassTreeViewColumnButton, > gtk_style_class_tree_view_column_button); > > This approach might not be a big and final solution, but its an approach > that can be implemented right now without breaking much stuff. OK, this might solve some of the problems. But I see it much more important to have the possibility of matching against these classes in the gtkrc instead of an API for the engine to query them. Also I think that applications need to be able to add attach their own classes to a widget or removing ones that area already there. This is useful in server cases: * GtkComboBox can modify its classes to show if it is in appears-as-list mode (it could be using an comboboxentry class because it has a visible entry then). * Custom widgets may want to look like eg. comboboxes, or fake treeview headers. Adding classes is important for this. In my opinion it is very important that any implementation like this would right away have a complete set of classes. This is important as theming is already a complex issue with a large set of special cases and quirks, and adding more API will not make this better in the long run. This of course does not (and cannot) address issues like: * More complex layout support (eg. in the sugar theme widgets should be aligned to a 15px grid most of the time.) * Resolution independence * For example notebook corner rounding (bug #457087). (Corners should be rounded depending on the position of tabs) Btw. I don't only want to discuss what can we do now to improve the current situation in the 2.x cycle, but also how should theming could look like in GTK+ 3.x. Both discussions are important though. Benjamin signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Theming improvements
Why not use the most obvious solution for the problem: Keep the theming engine as is, but instead of using one single theming detail string, let's attach a theming class property in the spirit of CSS class names to widgets: const gchar** gtk_widget_get_style_classes (GtkWidget *widget); gboolean gtk_widget_has_style_class (GtkWidget *widget, const gchar *class_name); Well, or for optimal speed let's use GQuarks instead: const GQuark* gtk_widget_get_style_classes (GtkWidget *widget); gboolean gtk_widget_has_style_class (GtkWidget *widget, GQuark class_name); Now let's add the rule, that widgets have to provide a macro for each style class they define, and we even get some easy way to document style classes: #define GTK_STYLE_CLASS_TREE_VIEW_COLUMN_BUTTON \ gtk_style_class_tree_view_column_button_get_quark () You might argue defining quarks for this purpose is quite some effort, but Bugzilla and libegg contain the implementation of a G_DEFINE_QUARK, respectively EGG_DEFINE_QUARK marco declaring *_get_quark functions: G_DEFINE_QUARK (GtkStyleClassTreeViewColumnButton, gtk_style_class_tree_view_column_button); This approach might not be a big and final solution, but its an approach that can be implemented right now without breaking much stuff. Ciao, Mathias -- Mathias Hasselmann <[EMAIL PROTECTED]> http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Theming improvements
On Fri, 2007-31-08 at 13:26 +0200, Lieven van der Heide wrote:
> As for the general rendering of widgets, I think the current way of
> letting the widget itself do the drawing, using a bunch of primitives
> (ie. boxes, frames, etc.), and then letting the theme engines theme
> just those primitives, instead of the whole widget, has shown to not
> really work. What most theme engines seem to be doing now, is kind of
> reverse engeneer those draw calls, and then render the theming in
> their own way, which often is quite different from what the widget
> actually thought is was drawing.
Most of the time these are special cases as for example making certain
corners rounded, but true.
> I think it would be better if each widget just has it's own, specific
> rendering class, which has a single function that should render the
> complete widget at once. (this way, you kind of get a model/view
> seperation inside controls). Themes can then override this rendering
> class, and have complete freedom inside the render function of that
> rendering class.
This sounds a lot like how QT works (I have not had a very deep look
though). However I don't think that any system should require build time
linking. As desktop environments (GNOME, maemo) and/or applications will
need custom widgets.
This is a general problem that I have not brought up earlier. But I
wonder how to handle one widget that may have two different modes. An
example that is annoying me right now is the radiobutton. It can not
only be a drawn as normal radio button with an indicator, but also as a
button without an indicator (in eg. GtkRadioToolButton).
In the two different cases you may not only want to have some different
style for the radiobutton, but also for the widgets (label) inside. I
think that we either need to remove any case like this, have the
possibility to style widgets (and their children) based on properties or
need a second independent representation of the UI for theming.
Hm, I don't see a way right now to handle the connected buttons in a
button box with this approach nicely.
http://futurepast.free.fr/buttonbox.png
> Each renderer should also have a default implementation, which renders
> the widget in a default way, using lower level rendering classes,
> which render things like edges and boxes. If a theme engine doesn't
> implement a specific widget's rendering class, but it did implement
> the lower level ones, then it will still be rendered using something
> that fits your theme (basically in the same way it's supposed to work
> now).
>
> It should also be possible for a renderer to use the renderer of
> another (more basic) widget ,for example, a treeview could use the
> button renderer as the default renderer for it's column headers.
>
> pseudo code for the default renderer of a checkbox:
>
> class CheckBoxRenderer
> {
> struct Params_s
> {
> int state;
> string label;
> }
>
> virtual void render(GdkDrawable target,Params_s params)
> {
> // default implementation that uses the generic renderer
> GenericRenderer generic_renderer = get_renderer(GENERIC_RENDERER);
> generic_renderer.render_box(target,Rect(0,0,16,16));
>
> if(params.state)
> {
>generic_renderer.draw_check(target,Rect(0,0,16,16));
> }
>
> generic_renderer.draw_text(target,Point(24,0),params.label);
> }
> }
>
> In this example, overriding the generic renderer class will let you do
> theming in the way it's done right now, overriding the
> CheckBoxRenderer will give you complete freedom over the way you want
> to render the checkbox
>
> To still be able to set up some generic theming things, that will be used by
Something missing here?
Benjamin
signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Theming improvements
On Fri, 2007-08-31 at 21:41 +0200, Milosz Derezynski wrote: > On 8/31/07, Peter Clifton <[EMAIL PROTECTED]> wrote: > > > > On Fri, 2007-08-31 at 20:09 +0200, Milosz Derezynski wrote: > > > Hey Alberto, > > > > > > I thought about it further and it would be also possible with the > > > current Gtk+; the outer buttons would just need to render themselves > > > in a different way, and with current API and internals, the API user > > > would need to make sure of that; furthermore give the box a spacing of > > > 0px, and then it should (almost) work. > > > > > > Almost, because each button would still draw a border for itself, so > > > the border between the inner buttons wouldn't look exactly the same, > > > as in the mockup. > > > > Could a sensible (IE - like it is at present) tree-view header be > > constructed out of similarly conjoined buttons, or is there further > > themeing required? (Assuming we could switch off the corner rounding and > > pre-lighting at will). > > Nope. That's what Aaron's post is all about: > http://abock.org/2007/07/02/suboptimal-theming-in-gtk/ I didn't mean is it possible with the current code, rather - would getting support for "conjoined" widgets provide a sufficient interface for drawing tree view headers. Whilst the widgets don't know about rounding, the application programmer is in a unique position to specify via some API or "hint" that widgets belong together. (I think this is much less the case in the button example posted actually though, that case would be a theme decision I believe). By specifying - either at the theme level, or widget implementation / application level, that a particular widget expects to be drawn closely against another one should be enough to control the spacings and corner rounding. At the application (or widget implementation) level, we might add a flag to a button which makes it expect to be packed tight against another widget. This would turn off rounding on those tightly packed sides. Perhaps this hinting could be a properly of the container widgets were being packed into. My question was... is this enough to do everything a tree-view header special-cases? I'm not familiar with that widget's code. Kind regards, -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Theming improvements
On Fri, 2007-31-08 at 20:01 +0100, Peter Clifton wrote: > Could a sensible (IE - like it is at present) tree-view header be > constructed out of similarly conjoined buttons, or is there further > themeing required? (Assuming we could switch off the corner rounding and > pre-lighting at will). Maybe I am misunderstanding something here, but the headers of GtkTreeView are basically normal buttons with special theming applied to them. Also note that any kind of rounding is done on the theme level, and GTK+ and the application does not control or know about it. Benjamin signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Theming improvements
Nope. That's what Aaron's post is all about: http://abock.org/2007/07/02/suboptimal-theming-in-gtk/ On 8/31/07, Peter Clifton <[EMAIL PROTECTED]> wrote: > > On Fri, 2007-08-31 at 20:09 +0200, Milosz Derezynski wrote: > > Hey Alberto, > > > > I thought about it further and it would be also possible with the > > current Gtk+; the outer buttons would just need to render themselves > > in a different way, and with current API and internals, the API user > > would need to make sure of that; furthermore give the box a spacing of > > 0px, and then it should (almost) work. > > > > Almost, because each button would still draw a border for itself, so > > the border between the inner buttons wouldn't look exactly the same, > > as in the mockup. > > Could a sensible (IE - like it is at present) tree-view header be > constructed out of similarly conjoined buttons, or is there further > themeing required? (Assuming we could switch off the corner rounding and > pre-lighting at will). > > -- > Peter Clifton > > Electrical Engineering Division, > Engineering Department, > University of Cambridge, > 9, JJ Thomson Avenue, > Cambridge > CB3 0FA > > Tel: +44 (0)7729 980173 - (No signal in the lab!) > > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Theming improvements
On Fri, 2007-08-31 at 20:09 +0200, Milosz Derezynski wrote: > Hey Alberto, > > I thought about it further and it would be also possible with the > current Gtk+; the outer buttons would just need to render themselves > in a different way, and with current API and internals, the API user > would need to make sure of that; furthermore give the box a spacing of > 0px, and then it should (almost) work. > > Almost, because each button would still draw a border for itself, so > the border between the inner buttons wouldn't look exactly the same, > as in the mockup. Could a sensible (IE - like it is at present) tree-view header be constructed out of similarly conjoined buttons, or is there further themeing required? (Assuming we could switch off the corner rounding and pre-lighting at will). -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Theming improvements
Hey Alberto, I thought about it further and it would be also possible with the current Gtk+; the outer buttons would just need to render themselves in a different way, and with current API and internals, the API user would need to make sure of that; furthermore give the box a spacing of 0px, and then it should (almost) work. Almost, because each button would still draw a border for itself, so the border between the inner buttons wouldn't look exactly the same, as in the mockup. Ultimately, the theme rendering should take care of all this though; i don't really know the Aqua APIs for the tabs (yeah you're right the tabs on OS X look like this :), but i'm sure the API user (on OS X) doesn't need to create the outer tabs as different widgets than the other tabs (probably he doesn't create them at all in the simple version of the API, but the point is the same still). On 8/31/07, Alberto Ruiz <[EMAIL PROTECTED]> wrote: > > > 2007/8/30, Milosz Derezynski <[EMAIL PROTECTED]>: > > The point about spatial awareness hit it right on the spot really; > > just as a throw in, i think something like this here should (should as > > in, it should be a goal to make it possible) doable: > > > > http://futurepast.free.fr/buttonbox.png > > That would actually rock for the native Mac OS X theme (we need a theme for > the ongoing port though), since the tabs used in cocoa behave exactly like > that. It would allow to improve the highlight for multiple selections as > well. Do we need to break Gtk to achieve this? > > > -- > Un saludo, > Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Theming improvements
On Fri, 2007-31-08 at 02:42 +0100, Alberto Ruiz wrote: > > > 2007/8/30, Milosz Derezynski <[EMAIL PROTECTED]>: > The point about spatial awareness hit it right on the spot > really; > just as a throw in, i think something like this here should > (should as > in, it should be a goal to make it possible) doable: > > http://futurepast.free.fr/buttonbox.png > > That would actually rock for the native Mac OS X theme (we need a > theme for the ongoing port though), since the tabs used in cocoa > behave exactly like that. It would allow to improve the highlight for > multiple selections as well. Do we need to break Gtk to achieve this? As the engine gets the widget that is passed in you can do crazy hacks based on that. I have actually implemented a hack like this for the toolbar once. But to get this right what one needs is a way for applications to hint where it makes sense to draw buttons connected, or where it should not happen. So this is something that I think needs a generic API to set hints (to some extend attaching data to the widget could work today), and a carefully designed specification that both themes and applications can implement independently. Benjamin signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Theming improvements
As for the general rendering of widgets, I think the current way of
letting the widget itself do the drawing, using a bunch of primitives
(ie. boxes, frames, etc.), and then letting the theme engines theme
just those primitives, instead of the whole widget, has shown to not
really work. What most theme engines seem to be doing now, is kind of
reverse engeneer those draw calls, and then render the theming in
their own way, which often is quite different from what the widget
actually thought is was drawing.
I think it would be better if each widget just has it's own, specific
rendering class, which has a single function that should render the
complete widget at once. (this way, you kind of get a model/view
seperation inside controls). Themes can then override this rendering
class, and have complete freedom inside the render function of that
rendering class.
Each renderer should also have a default implementation, which renders
the widget in a default way, using lower level rendering classes,
which render things like edges and boxes. If a theme engine doesn't
implement a specific widget's rendering class, but it did implement
the lower level ones, then it will still be rendered using something
that fits your theme (basically in the same way it's supposed to work
now).
It should also be possible for a renderer to use the renderer of
another (more basic) widget ,for example, a treeview could use the
button renderer as the default renderer for it's column headers.
pseudo code for the default renderer of a checkbox:
class CheckBoxRenderer
{
struct Params_s
{
int state;
string label;
}
virtual void render(GdkDrawable target,Params_s params)
{
// default implementation that uses the generic renderer
GenericRenderer generic_renderer = get_renderer(GENERIC_RENDERER);
generic_renderer.render_box(target,Rect(0,0,16,16));
if(params.state)
{
generic_renderer.draw_check(target,Rect(0,0,16,16));
}
generic_renderer.draw_text(target,Point(24,0),params.label);
}
}
In this example, overriding the generic renderer class will let you do
theming in the way it's done right now, overriding the
CheckBoxRenderer will give you complete freedom over the way you want
to render the checkbox
To still be able to set up some generic theming things, that will be used by
On 8/29/07, Benjamin Berg <[EMAIL PROTECTED]> wrote:
> Hello,
>
> So here finally an E-Mail about the GTK+ theming discussion we had at
> the start of GUADEC and some things I picked up.
>
> In the discussion CSS had been mentioned a lot of times to a large
> extend because of the matching abilities that it has. It is possible to
> match on the hierarchy and also neighbours. Neighbour matching is
> impossible in GTK+ currently and it would with theming paddings between
> widgets. Also in CSS/HTML an item can have multiple classes.
>
> Here are some of the main points/ideas:
> * Multiple themes in one application (eg. theme preview, glade)
> * Instead of having the support directly in GTK+ create a common
> library that can be used by Firefox, OpenOffice and maybe even
> KDE/QT
> * Don't use pixel sizes -- The maemo people designed the interface
> in millimetre, however this is not that useful on a desktop
> machine.
> * Separating positioning of widgets out of the application, and
> into the theme.
> * No non-transparent X windows if possible
> * 3D widgets, eg. lighting effects, or when rotating workspaces
> * Solid animation support and transition effects. (imagine eg. an
> animation when a menu item is activated, or handling an opening
> expander)
>
> There is also http://live.gnome.org/GTK%2B/NewThemeApi (which needs to
> be updated) but I this is a pretty complete list.
>
> I think an interesting thing to discuss is the scope of any system. It
> was suggested that the theme should be able to handle large parts of the
> UI design. Other things that could be handled by themes include
> application graphics (eg. nautilus disk usage pie chart) or the metacity
> window frames.
>
>
> As a way forward it is important to know what a CSS based theme format
> might look like. Andreas Nilson has said he could help in this area.
> Other than this any ideas and comments are of course welcome.
>
> To help the overall process, I can try to keep the wiki in sync with any
> arguments that are brought up.
>
> Benjamin
>
> ___
> 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: GTK+ Theming improvements
2007/8/30, Milosz Derezynski <[EMAIL PROTECTED]>: > > The point about spatial awareness hit it right on the spot really; > just as a throw in, i think something like this here should (should as > in, it should be a goal to make it possible) doable: > > http://futurepast.free.fr/buttonbox.png That would actually rock for the native Mac OS X theme (we need a theme for the ongoing port though), since the tabs used in cocoa behave exactly like that. It would allow to improve the highlight for multiple selections as well. Do we need to break Gtk to achieve this? -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Theming improvements
The point about spatial awareness hit it right on the spot really; just as a throw in, i think something like this here should (should as in, it should be a goal to make it possible) doable: http://futurepast.free.fr/buttonbox.png On 8/30/07, Rui Tiago Cação Matos <[EMAIL PROTECTED]> wrote: > On Qua, 2007-08-29 at 21:15 +0200, Benjamin Berg wrote: > > Neighbour matching is impossible in GTK+ currently and it would with > > theming paddings between widgets. > > Sorry, I can't follow you on this sentence. > > > * Separating positioning of widgets out of the application, and > > into the theme. > > This is very interesting. IMO the programmer shouldn't need to worry > about UI design or things like the HIG. If there was a means by witch > the programmer could specify the actions and associated data (the > semantics) then another layer could apply a style sheet to it to > generate the interface. Maybe there should be two types of style sheets, > one specific to the program (analogous to a glade file) and a general > one which would encompass what we today call a theme and which could > enforce the HIG. > > > I think an interesting thing to discuss is the scope of any system. It > > was suggested that the theme should be able to handle large parts of the > > UI design. Other things that could be handled by themes include > > application graphics (eg. nautilus disk usage pie chart) or the metacity > > window frames. > > This is something that I've thinking of lately: why can't applications > be in control of their window decorations? The window manager could be > there doing all it's non visible work anyway but the app (of course I'm > thinking the toolkit here) could do all the drawing and thus be in > complete control over it's interface, meaning that the functionality and > the appearance of the decorations could be much more integrated with app > itself. > > Anyway I often drift into over-engineering :-) BTW, all of this is > obviously 3.0 material. I believe these theming improvements are also? > > Rui > > > ___ > 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: GTK+ Theming improvements
On Qua, 2007-08-29 at 21:15 +0200, Benjamin Berg wrote: > Neighbour matching is impossible in GTK+ currently and it would with > theming paddings between widgets. Sorry, I can't follow you on this sentence. > * Separating positioning of widgets out of the application, and > into the theme. This is very interesting. IMO the programmer shouldn't need to worry about UI design or things like the HIG. If there was a means by witch the programmer could specify the actions and associated data (the semantics) then another layer could apply a style sheet to it to generate the interface. Maybe there should be two types of style sheets, one specific to the program (analogous to a glade file) and a general one which would encompass what we today call a theme and which could enforce the HIG. > I think an interesting thing to discuss is the scope of any system. It > was suggested that the theme should be able to handle large parts of the > UI design. Other things that could be handled by themes include > application graphics (eg. nautilus disk usage pie chart) or the metacity > window frames. This is something that I've thinking of lately: why can't applications be in control of their window decorations? The window manager could be there doing all it's non visible work anyway but the app (of course I'm thinking the toolkit here) could do all the drawing and thus be in complete control over it's interface, meaning that the functionality and the appearance of the decorations could be much more integrated with app itself. Anyway I often drift into over-engineering :-) BTW, all of this is obviously 3.0 material. I believe these theming improvements are also? Rui signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Theming improvements
On mer, 2007-08-29 at 21:15 +0200, Benjamin Berg wrote: > As a way forward it is important to know what a CSS based theme format > might look like. I'm sure it would look a lot like XUL's chrome files. http://www.mozilla.org/projects/xul/ Xav ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Theming improvements
The thing I miss from your list is how to make sure themes' code does not crash the innocent application into which they get loaded. There have been several rounds of obscure bug reports for Gnumeric that basically came down to theme code bugs. Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GTK+ Theming improvements
Hello, So here finally an E-Mail about the GTK+ theming discussion we had at the start of GUADEC and some things I picked up. In the discussion CSS had been mentioned a lot of times to a large extend because of the matching abilities that it has. It is possible to match on the hierarchy and also neighbours. Neighbour matching is impossible in GTK+ currently and it would with theming paddings between widgets. Also in CSS/HTML an item can have multiple classes. Here are some of the main points/ideas: * Multiple themes in one application (eg. theme preview, glade) * Instead of having the support directly in GTK+ create a common library that can be used by Firefox, OpenOffice and maybe even KDE/QT * Don't use pixel sizes -- The maemo people designed the interface in millimetre, however this is not that useful on a desktop machine. * Separating positioning of widgets out of the application, and into the theme. * No non-transparent X windows if possible * 3D widgets, eg. lighting effects, or when rotating workspaces * Solid animation support and transition effects. (imagine eg. an animation when a menu item is activated, or handling an opening expander) There is also http://live.gnome.org/GTK%2B/NewThemeApi (which needs to be updated) but I this is a pretty complete list. I think an interesting thing to discuss is the scope of any system. It was suggested that the theme should be able to handle large parts of the UI design. Other things that could be handled by themes include application graphics (eg. nautilus disk usage pie chart) or the metacity window frames. As a way forward it is important to know what a CSS based theme format might look like. Andreas Nilson has said he could help in this area. Other than this any ideas and comments are of course welcome. To help the overall process, I can try to keep the wiki in sync with any arguments that are brought up. Benjamin signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
