[gtk-list] Re: [patch] range controls...

[Patrice Fortier <Patrice Fortier aquarel fr>]

Owen Taylor wrote:
> >   I also added 2 new datas in the range class:
> > trough_xthickness & trough_ythickness
> > These will be use to implement the different look&feels (ie win95,
> > NeXT, Mui-amiga...) for range controls.
> > For example a win95 or NeXT scrollbar has no (width 0) shadow on
> > trough, but still has a shadow for arrows and slider.
> > I modified scrollbar and scale widgets to use these datas.
> 
> I haven't seen your patch yet (still in incoming), but this doesn't
> sound right. When multiple look-and-feels are implemented, that
> should presumably be done using the GtkStyle mechanism. (Which will
> have to be much expanded and modified.) So, I think the widget 
> class structure isn't the right place for this type of thing.

Currently, you can't do anything with GtkStyle except changing
the default colors. I tried to do something with GtkStyle, but if
you want to change more than a simple thing (draw_shadow for all
the widget) it's useless.

There are a couple of problems with the range contol widgets:
The scrollbar (for example) is a composite widget. But if you
look at the code, it's coded just like a simple widget.
Scrollbar can be considered as a special case for look&feel
as it's both a simple and composite widget :(

Another thing is that range controls are not coded in a OO way.
The range widget includes features of the scrollbar like arrows
(which are not in scale), and features of scale like background
window to write digits (which is not in scrollbar).
range is the superclass of scrollbar & scale...


So, what's the problem with scrollbar (for ex.)?
I have 4 widgets in 1: the trough, slider and 2 arrows... and only
one GtkStyle.
We have several solutions:
 * Rewrite range widgets as composite widgets.
 * Add new resource to range widgets.
This is independant of the GtkStyle stuff (which will have to be 
done).

I took the easy solution.


> Basically, I don't think we should spend much time worrying about
> these things and modifying the code until we know how multiple
> look-and-feels are going to be done.

As said earlier, some points in range widgets are independant of
GtkStyle. Second scrollbar is a special case (composite coded as
simple).
I'm writting these patches so I (we?) can see what we'll need to
create the multiple looks for a widget. It seems I didn't choose
a good example with this widget ;).
Anyway I don't feel ready to make a major rewrite of the style 
stuff (anyone?).

Something to be done.
Do you have a better solution than mine for these widgets?


> (The rest of your patch sounds more reasonable, though it should
> be noted that Motif scroll bars (at least) behave the way GTK
> scroll bars do now, and this may be a more useful behavior
> than forcing the user to move the cursor once the slider reaches
> the pointer position)

Ooops. I should use Motif more often :).
Note that if you move the mouse, the slider moves again. You don't 
have to use the cursor.
I thought it was a bug, but it seems that it's "feel" problem.
I don't know how we will handle multiple feels like that ... 


I think I have a problem.
I've made some significant changes in the range/scrollbar widgets but
I don't know how I should give the patches. Some stuff is more useful
than other. I can post several patches (maybe with dependances), or
I can post one big patch (maybe involving several widgets).
arg.


Patrice.