Re: Patch to Gtk?Pane

[Owen Taylor <otaylor gtk org>]

Benjamin Dauvergne <feanor@easynet.fr> writes:

> [1  <text/plain; US-ASCII (7bit)>]
> 
> Hello all!
> 
> I have made a patch that allow to move a pane with all the handler.
> I have redone the allocation code too.
> 
> There is some bug when your child is a NO_WINDOW widget and it wants some 
> events(i have removed the handle window frome GtkPane, so paned->window is now
> receiving button and motion events). I don't know how to deal with events
> repartition and I think some gtk gurus could find the matter.

Good work. These are things people have been asking for. 

On the other hand, I'm not sure I quite agree with everything
you've done.

 - With the old panes, the user can tell that it is a paned
   window, because it:
 
     a) has a groove
     b) has the handle
     c) The cursor changes when it is over the handle.

   In your patch, it looks just like two frames next to each other.
   The user has to guess that they can drag the bar. Which will
   either result in users not realizing that they can move the bar,
   or users trying to move things that aren't moveable. 

 - With your changes, the area the user can click on is very narrow.
   I have to try two or three times before I click successfully.

   I personally much prefer paned windows that have a tab, which
   provides a larger area to click on. (Which is why I did it that 
   way to begin with)

What I was planning to do was to leave the handle there, but allow the
user to drag everywhere on the gutter as well. I wanted to change the
cursor when the pointer was over the gutter so the user know that they
could drag there.

(Changing the cursor is a little bit tricky. It can be done
 two ways:

 1) Create another window for the gutter, which has the alternate
    cursor set.

 2) Track the position of the pointer (and Enter/Leave events), and
    change the cursor accordingly.

The first method is simpler, but it restricts the area with the 
changed cursor to the size of the gutter, while the second
method is more flexible.)

Regarding expanding the panes according to the ratio of their
sizes: when this subject came up before, good points were
made on either side.

One conclusion was that the current behavior is how panes
behave on almost every system. So I'd like to leave it as
the default. However, it is not appropriate for every program.

My proposal was:

========
[...], what I've been thinking of doing is adding an "expand" variable
for each pane, like the Box widgets. 

(For backwards compatibility, this would be set in a separate call,
and/or by creating new 

 gtk_paned_pack1 (paned, widget, expand);

to replace:

 gtk_paned_add1 (paned, widget))

There is some question of whether the excess should be given to
both widgets equally (which is what Boxes do) or in proportion
to the existing ratio. 
=======

So if only the second pane was set to expand, it would duplicate
the current behavior; if both panes were set to expand, it would
duplicate your behavior.

If you want to modify your patches in this direction, that
would be appreciated. Otherwise, I'll probably get to this
myself sometime fairly soon.

Regards,
                                        Owen