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

[Per Lewau <perle lysator liu se>]

On Sat, 7 Mar 1998, Tim Janik wrote:

> On Sat, 7 Mar 1998, Per Lewau wrote:
> 
> > Hello,
> > 
> > I'm trying to patch gtk scrollbars to work like the Motif ones (that is,
> > button 2 moves directly to the clicked spot; try it in Netscape for
> > instance) and I'm stuck.
> > 
> > It appears as though it would be quite easy, but I need to translate the
> > xy position clicked to an adjustment value. Now there is a dummy function
> > gtk_range_calc_value that, by the sound of it, would do this. Two problems
> > though. First, the value of the adjustment depends on the type of
> > scrollbar, thus a subclass of gtkrange. Second, gtk_range_calc_value takes
> > only one gint parameter position (beats me what that means) instead of x
> > and y.
> 
> 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.

> > 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.
 

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.

> 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?

> 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?

[Patch cut]


-----------------------------------------------------------------------
Per Lewau (perle@lysator.liu.se)Student of Computer Science at the 
				University of Linkoping, 
				Sweden. 
"Why waste time learning, when ignorance is instantaneous?"
						- Hobbes