Re: [gtk-list] Re: Motif scrollbar patch attempt

[Tim Janik <timj gimp org>]

On Sun, 8 Mar 1998, Per Lewau wrote:

> On Sat, 7 Mar 1998, Tim Janik wrote:
> 
> > On Sat, 7 Mar 1998, Per Lewau wrote:
> > 

[..]

> > hm, first gtk_range_calc_value is a *dead* function, that means it is
> > a) nowhere used in gtk and
> > b) will always   return 0.0;
> 
> Yes, I noticed that. It just sounded as though it was intended for this in
> the first place.

seems more like a left over to me...

> > > So the way I see it I have to add a new abstract method to GtkRange
> > > (gfloat gtk_range_calc_value(GtkRange *range, gint x, gint y)) and leave
> > > it up to subclasses to define it. 
> > > 
> > > Is there a better way? I can't seem to find one. Everything seems to boil
> > > down to setting the correct adjustment value without knowing anything
> > > about the type of scrollbar. 
> > 
> > yep, actually gtkrange just needs to support absolut postitioning as well.
> > while looking at the code i just figured i might try it out and hacked
> > something up to support the button 2 jump behaviour, patch appended.
> > 
> > the problem with this thing is, it requires a minor api change, that is
> >   gint (* trough_click)    (GtkRange *range,
> >                             gint      x,
> >                             gint      y);
> >   gint (* trough_keys)     (GtkRange *range,
> >                             GdkEventKey *key,
> >                             GtkScrollType *scroll,
> >                             GtkTroughType *trough);
> > from GtkRangeClass need to have support for an additional argument gfloat*
> > which introduces an api change and falls under the feature freeze for 1.0 ;(
> 
> That is _bad_ news. The scrollbars as they are today are completely
> useless for large lists. Try adding 10000 entries to the CList example in
> testgtk. You either have to scroll forever to get to, say, the 9000'th row
> or try to drag off with a miniscule rectangle.
> 
> I had hoped I would be able to get this patch in before 1.0, but that may
> not be so then. So I guess gtk+-1.0 will have a usability bug.

if none else is strongly going to object i tend to put it in then.

> Anyway...now for the solution. I didn't really dare to change the API, and
> thus I concluded that a new method was required. The change to the API is
> easier, though.

it is actually straight forward with the scheme used in gtkrange.c and imho
The Right Thing to do.

> > note that the bahaviour is still somewhat different from motif, because
> > the slider just jumps to the specified position and then does nothing.
> > it actually requires a server grab at this point because the xserver
> > wouldn't report motion hint masks now cause those are not set for the
> > trough window.
> 
> I don't follow you here. What should the scrollbar do, apart from jumping?
> What's with the grab? Why motion hints?

after the trough is pressed at a certain position, the slider will jump
there, that is quite fine. then, the slider should automatically grab
the button so you can click-jump-drag it, that's the motif behaviour and
actually more intitive than click-jump-release-click-drag.
click-drag works with a click on the slider since its GdkWindow has 
GDK_BUTTON_MOTION_MASK | GDK_POINTER_MOTION_HINT_MASK set, but the
trough hasn't. maybe we are just set with setting GDK_BUTTON_MOTION_MASK
and GDK_POINTER_MOTION_HINT_MASK for the trough as well but i haven't
tested that, anyways this change would need to go into the realize
function of all widgets derived from GtkRange (scales and scrollbars),
which is why i haven't bothered testing it.
if this doesn't work, we need to do a server grab on the slider after
it jumped, but that's ugly since the current code doesn't need to do it,
and it shouldn't really be neccessary... needs further investigation.

> > but it think this should give you a nice start.
> 
> Thanks for the patch, I felt a bit lost. I still have to fix a few things,
> but it's a start.

> One other thing I noticed about the gtkrange class subtree. Why does
> gtkrange know anything about h- or vmotion? Shouldn't these go into the
> respective scrollbars?

it does not know everything about it, actually it deferes a lot of the
implementation dependant stuff to the children via the GtkRange::trough_click
and GtkRange::trough_keys GtkRange::slider_update GtkRange::motion and else
signals. it just happens to provide default handlers for the most of those,
so to avoid code duplication and to ease code maintainance where possible.

you should run a diff gtkhscrollbar.c gtkvscrollbar.c on gtk versions
from last years july on or so to get an idea how many things introduce
bugs and how assymetrically code gets fixed for duplicated code portions.

> Per Lewau (perle@lysator.liu.se)Student of Computer Science at the 
> 				University of Linkoping, 
> 				Sweden. 

---
ciaoTJ