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

[Patrice Fortier <Patrice Fortier aquarel fr>]

Some of you may remember that a couple of months ago I asked why
the scrolled_window widget was not a subclass of the viewport
(they're both container widgets - well, almost).
As the answers didn't satisfy me, I dicided to rewrite the 
scrolled_window as a subclaas of viewport... 

And I've found my answer...

There is a nasty design problem in the viewport widget, and its 
side effect is that you can *not* subclass it :(

First let me explain how the viewport widget works.
It's composed of 3 windows, and 1 widget (the child in the viewport).


   +--------main_window------------+
   |                               |
   | +-----view_window---------+   |
   | |                         |   |
   | |  +------window----------|- -|- - +
   | |  |                      |   |    |
   | |  |                      |   |
   | |  |                      |   |    |
   | |  |  child widget in     |   |
   | |  |    window            |   |    |
   | |  |                      |   |
   | |  |                      |   |    |
   | |  |                      |   |
   | |  |                      |   |    |
   | +-------------------------+   |
   |    |                          |    |
   |                               |
   +-------------------------------+    |

        |                               |
	+- - - - - - - - - - - - - - - -+


the main_window is just this, the main window of the widget.
the view_window is used to clip the content of window, which 
contains the child widget, so you see only the right part.

So, what's the problem with that?
The problem is that main_window should be called window, and
window should have another name (let say child_window).

Why is it so important? That 's just a naming convention problem.
No.
Remember that there are widget with no window (flag NO_WINDOW)?
Which window do they use? The parent (main) window.
And what is the parent window? it's window (widget->window).

As noone can tell if the the child widget is a NO_WINDOW widget,
the window in which it is draw *must* be "window".

Now, if I want to add a widget in the viewport widget (like 
scrollbars), where will they be drawn? in window like every
other widget... That's definitly not the place thay should be!
So you can NOT subclass viewport or add something to it except
*inside* the child widget.


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).
 - 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).
 - Jay Painter write his clist widget *without* using gtkviewport
or the scrolled_win widget!!! and he's not a beginner...
 - In gtktest the scroll speed test is made *without* using 
scrolled_win!

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?

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


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


Patrice,
going to take a beer after writing so much :).