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
