After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 723061 - With the headerbar branch, mainwindow's vpanes/hpanes widgets positions always shift on startup
With the headerbar branch, mainwindow's vpanes/hpanes widgets positions alway...
Product: pitivi
Classification: Other
Component: User interface
Other Linux
: High normal
: 0.95
Assigned To: Pitivi maintainers
Pitivi maintainers
Depends on: 692980
Blocks: 682886
Reported: 2014-01-26 23:55 UTC by Jean-François Fortin Tam
Modified: 2015-10-20 13:18 UTC
See Also:
GNOME target: ---
GNOME version: ---

screenshots and comparisons (392.50 KB, application/x-tar)
2014-01-26 23:57 UTC, Jean-François Fortin Tam

Description Jean-François Fortin Tam 2014-01-26 23:55:42 UTC
I was wondering why I'm readjusting the position of panes so often... turns out they shift a little bit on every startup! So even if you neatly place your panes like the proposed default in bug #702507, they will eventually always end up with the viewer being tall and narrow, because the main+secondary tabs are "pushing" to the right and the upper portion of the UI is "pushing" the timeline down. This is super annoying.

On my end, on each startup,
- the timeline area is pushed down by 13 pixels
- the docked media library tab pushes to the right by 24 pixels
  (the docked contextual tabs notebook also pushes by 24 pixels)

- Undocked components get pushed down by 24px and pushed right by 1 pixel

Measurements were done with GIMP's measurement tool (Shift+M)
using the overlaid screenshots diffs.

Last time I looked, Pitivi was correctly saving the position values.

What the heck is going on here...
Comment 1 Jean-François Fortin Tam 2014-01-26 23:57:02 UTC
Created attachment 267265 [details]
screenshots and comparisons
Comment 2 Georges Basile Stavracas Neto 2014-03-11 15:03:38 UTC
I think this is related to Gtk+ allocation algorithm. After the UI setup, some widgets are (wrongly) reallocated. I can think of 2 solutions:

 - Calculate the ammount of space that will be shifted and load with that
 - Backtrack to the point that it started happening, and see what caused the changes

Note that the current master does not suffer from it.
Comment 3 Jean-François Fortin Tam 2014-03-11 15:41:25 UTC
Interesting... the movement/shifting for *docked panes* happens only on my headerbar branch with the commit that does the switch to the headerbar ("mainwindow: Replace the menubar and main toolbar by HeaderBar and MenuButton")

*but*... the shifting behavior of *undocked* widgets (ex: drag out the media library's tab to detach it) happens no matter the branch, I noticed that problem occuring months ago and it still affects master.

So we have two similar bugs, one of which only affect the headerbar version.
Comment 4 Jean-François Fortin Tam 2014-03-13 22:52:44 UTC
Okay so this bug report is now about the headerbar branch regression.

For the undocked utility windows positioning bug, see bug 692980 instead.
Comment 5 Jean-François Fortin Tam 2014-03-19 01:59:36 UTC
Another interesting detail: this happens only if the window is maximized. So, to summarize, it only happens:

- With the headerbar branch, and
- When the main window is maximized, and
- When utility windows are docked.

Result: panes shift a little bit on each startup.
Comment 6 Georges Basile Stavracas Neto 2014-03-19 13:39:31 UTC
After a whole bunch of tests, prints and etc., found that panels are not shifting, they are being loaded with wrong positions. It is not Gtk+ allocation algorythm fault!

The true error is actually when saving the values. At this point, I still don't know why the values are being saved incorrectly. Panels are changing their position on 'delete' event.
Comment 7 Jean-François Fortin Tam 2014-10-05 21:45:49 UTC
Hey Georges (or Alex, or anyone looking at this)... I'm wondering if it's a GTK/Window manager issue related to the "delete" event that Georges mentioned in the previous comment, maybe the components get a configure signal at the last minute when they get deleted?
Comment 8 Thibault Saunier 2015-10-20 13:18:54 UTC
This bug has been migrated to

Please use the Phabricator interface to report further bugs by creating a task and associating it with Project: Pitivi.

See for details.