Re: [gtk-list] Design problem in gtviewport+scrolled_window [long]




Patrice Fortier <Patrice.Fortier@aquarel.fr> writes:

[ explaination of the problem elided ]

> Ok, that's a design problem but cant't we stick with it until
> 1.0 is released?
> I don't think so.
> 
> As Raph said it a couple of weeks ago, we have a serious problem
> with viewport/scrolled_window -like widgets.
> Now consider that we're *few* using gtk (compared to after-1.0 
> should be) and watch this:
>  - For a mysterious reason I decided to rewrite scrolled_window 
> (note that I'm only interested by gtk, not appls).

Though that sometimes describes my attitude as well, I think we
have to design GTK for applications, not for the toolkit ;-)
.so files aren't very satisfying to most people.

>  - Raph wanted to have a more powerful scrolled_win, so he rewrote
> gtkviewport AND gtkscrolled_win to suit his needs.  This only
> thing proves that there is a problem with classes as the good
> solution is to subclass scrolled_win (or in extremis, rewrite
> only scrolled_win).

He also rewrote most of the rest of the widget heirarchy. While
we may well want to incorporate some of his ideas in the future,
it is going to require more radical changes 

>  - Jay Painter write his clist widget *without* using gtkviewport
> or the scrolled_win widget!!! and he's not a beginner...

There is a reason for that. Widgets are simply too heavyweight
to use in a list holding hundreds or thousands of items.

>  - In gtktest the scroll speed test is made *without* using 
> scrolled_win!

The point of that test is to test scrolling _without moving
an X window around_. (As in the text widget, or the GIMP display
windows, etc.) The point of the scrolledwindow widget is to
scroll a bunch of widgets around.
 
> Application writers shouldn't have to rewrite widgets like that.
> This is *our* task to provide a clean, powerful, and extensible
> widget set so they can use it directly or subclass it without
> too much work.
>
> Now consider this:
> I took a look at the gimp sources and the viewport widget is *not*
> used. I didn't look at gnome but I bet that it's not used either.
> Only gtkscrolled_window is used, never gtkviewport.
> 
> Why do we have 2 widgets, although only one is used?
> Is it so difficult to add a GTK_POLICY_NEVER for the use who will,
> one day, need a viewport without scrollbars?
> 
> 
> After all these critics, I must give some advices to avoid (most)
> flames :)
> 
>  - In gtkviewport, replace main_window with window, and window with
> bin_window (or another name). Problem: How can we make the child 
> widget to be drawn in bin_window instead of window, which is the
> parent->window (as everywhere else). This is *THE* problem.
>
>  - At last make gtkscrolled_window a subclass of gtkviewport, so
> people don't have to rewrite BOTH widgets :)
>
>  - Extend this, and have only *one* widget instead of 2?

As you've explained yourself, these are all impossible. A widget can't
have child widgets in two separate windows. Obviously, this could be
changed - e.g. by adding another parameter to gtk_widget_set_parent
and changing all widgets not to refer to parent->widget, but these are
major changes, and I'm not at all convinced of the utility of
such. They would do nothing towards resolving:
 
>  - Add important stuff in the whater-widget-result like +32k,
> and the speeeed expose handling of gzilla version (I didn't
> look at the clist, except that the "window" is at the correct
> place :)).

(That's because the clist isn't a container for user widgets)
Unfortunately, the +32k type stuff is going to take a major
rewrite of a lot of code and isn't suitable for GTK 1.0, which
is meant to go out _soon_, and to work with the GIMP 1.0.

> I consider that this problem is important enough to be solved 
> before 1.0, so I expect comments to find an effective solution.

Perhaps you should explain exactly what you want to do by
subclassing scrollbar and/or viewport. Then we can try
to think of a way of doing it. 

Regards,
                                        Owen



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]