See also bug #702507 comment 24 for the background on this.

Created attachment 315713 [details]
script showing a forgetful vpaned

Slightly better script (clearer output and more checks).

I think I've pinpointed this to the maximization. If you unmaximize the window and size it around, you see that at some point the paned position is set correctly. But if you maximize directly from a state where the paned did not have enough space to be set to the correct position, the thing makes no sense whatsoever.

So for the bug to be worked around, you must start the script, unmaximize, size up the window until the position is set correctly, then maximize... it won't work if you maximize first and try to set the position from there.

I must say I have a hard time seeing the docs spell out clearly if a position set with gtk_paned_set_position is supposed to survive across changes of the paned size. Do you have evidence that this is the expected behavior ?

Well the problem is that this makes it impossible in practice to restore the UI state of a maximized application. If you look more closely at the behavior of the attached script, the issue is that no matter how many times you set_position, it totally ignores it as the window is maximized.

You'll just have to set the paned state after maximizing the window, I guess. 

If you think about it, it is not clear at all what the paned should do with the set position when its size changes. There's a wide range of different possible behaviors that all make sense, depending on circumstances.

If a position is set, then one would expect it remains set and if possible applied. There should be a difference between the desired position and the applied position.

> You'll just have to set the paned state after maximizing the window, I guess.

Isn't that what we've been doing all this time anyway? The fact that it's been set to a position before shouldn't prevent setting its position afterwards like what we're seeing...

I'll add to that the tangential fact that Pitivi does not even set the "maximized" state itself… Mutter does, whenever:
- it deems that the window size is "close enough to the screen size", or;
- the window is created without a predefined size (ex: blank user settings).

…so we don't even control when maximization happens, it "just happens".
It still seems to me that we're using the paned widget as expected.
We should be able to set its position whenever we want.

So, lets turn this into a feature request to make GtkPaned behave better in these situations.

Here is an api suggestion:

enum {
  GTK_PANED_RESIZE_NONE,         /* current behavior */
  GTK_PANED_RESIZE_CHILD1,       /* try to keep child2's size unchanged */
  GTK_PANED_RESIZE_CHILD2,       /* try to keep child1's size unchanged */
  GTK_PANED_RESIZE_PROPORTIONAL  /* try to keep the size ratio unchanged */
} GtkPanedResizePolicy;

void
gtk_paned_set_resize_policy (GtkPaned             *paned,
                             GtkPanedResizePolicy  policy);
GtkPanedResizePolicy
gtk_paned_get_resize_policy (GtkPaned *paned);


I'd gladly review a patch for something like this.

http://lazka.github.io/pgi-docs/#Gtk-3.0/classes/Paned.html#Gtk.Paned.pack1 lists a "resize" parameter:
resize (bool) – should this child expand when the paned widget is resized.

The resize parameter can already be used to enforce the resize policy you suggested:
GTK_PANED_RESIZE_NONE          w1.resize = 0, w2.resize = 0
GTK_PANED_RESIZE_CHILD1        w1.resize = 1, w2.resize = 0
GTK_PANED_RESIZE_CHILD2        w1.resize = 0, w2.resize = 1
GTK_PANED_RESIZE_PROPORTIONAL  w1.resize = 1, w2.resize = 1


I have the impression we are talking about different things. Maybe we were not clear in describing the bug we are seeing.

We are trying to set the position of a paned and it's overwritten for no reason:
- We are calling paned.set_position(250), position is set to 250.
- We are calling window.show_all(), position is set to 20!
- When window's configure-event is fired, we call again paned.set_position(250), position is set to 250.
- Then for some reason the paned's position is set to 1527!

In the attached script, only if the first widget is added with resize=False and the second widget with resize=True, the position=250 survives, otherwise the first widget takes up all the extra space not required by the second widget. But again, the resize info of the two children should be applied only *after the paned appeared*, when its size changes.

(In reply to Alex Băluț from comment #10)
> http://lazka.github.io/pgi-docs/#Gtk-3.0/classes/Paned.html#Gtk.Paned.pack1
> lists a "resize" parameter:
> resize (bool) – should this child expand when the paned widget is resized.
> 
> The resize parameter can already be used to enforce the resize policy you
> suggested:
> GTK_PANED_RESIZE_NONE          w1.resize = 0, w2.resize = 0
> GTK_PANED_RESIZE_CHILD1        w1.resize = 1, w2.resize = 0
> GTK_PANED_RESIZE_CHILD2        w1.resize = 0, w2.resize = 1
> GTK_PANED_RESIZE_PROPORTIONAL  w1.resize = 1, w2.resize = 1
> 

I don't think we can just change the meaning of resize for all the existing applications that are using it since gtk 2.x days.

Also note that the the docs state that 

w1.resize = 0 = w2.resize is treated the same as w1.resize = 1 = w2.resize

We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.

As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla.

If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab:

https://gitlab.gnome.org/GNOME/gtk/issues/new