gramps
gramps copied to clipboard
gramps-project
Fix issue with view bottombar separator creeping upward
fixes #11973
Second attempt; it seems I didn't get this completely the first time in https://github.com/gramps-project/gramps/commit/1a48e8a03e7252d60ba5eeb329ef297a33003f04 It still seems to creep about 2 pixels every time a db is opened.
This time I just don't save changes unless there are at least 10 pix of difference.
I am curious about the creep of windows in Windoze. Whenever I open Gramps, the application window is offset and the very bottom of the StatusBar is offscreen. And when closing Gramps, this offscreen area is where the Backup progress bar is displayed. So to see the progressbar and understand where the Close in its progress, it becomes necessary to move the window or maximize it. EVERY single time Gramps is run.
Is this what happens for everyone? [Doesn't happen in macOS or dual monitor Windoze. Still need verification in Linux and by another Windoze users.]
I don't see this on my machine, although I usually run Gramps on the second monitor.
I don't see this on my machine, although I usually run Gramps on the second monitor.
Good info. Yes, it is OK when I've dragged the Gramps window to my 2nd monitor. (That might be because I never maximize on the 2nd monitor. And that screen has no OS taskbar affecting the positioning of window creation.)
Do you think it might be related to Gramps being maximized when closed?
So that Gramps updates the Gramps.ini position but then does not support Maximized windows when starting the application? Plus I suspect that the OS prefers to draw windows where they will not obscure the OS menus.)
I've discovered that the Windoze titlebar for Gramps is significantly shorter when the Gramps window maximized than when floating. Below is a snip of showing the Maximized Gramps window with a Preferences window aligned at the top. Note that the Preferences titlebar is significantly taller than the Gramps titlebar. (When the Gramps window is not maximized, it has the same height as the Preferences.) This is with Adwaita theme, restored to defaults. (My eyes handle 12 point better than the default 10pt but this is set to default for testing.)
Note that the statusbar is taller than either. And the progressbar is drawn at the very bottom rather than centered or at top.
I think the PR issue is fixed. The concern by emyoulation is a different issue, unrelated to this one. So it should be redy to merge, although it has not had the usual 10 days to evaluate.
@prculley I can't see why this is necessary. I don't see any creep after your fix in PR #1122.
Otherwise, we can relax the 10 day evaluation period to get this into the release.
On my system the creep is about 2 pix upwards for each restart or tree close/open cycle. The creep may depend on the theme and/or version of Gtk as well, as it seems to depend on the size of the icons in the top toolbar; when icons are added as the view opens, the bar seem to change slightly. This is not exactly critical, so use your own judgement on if it is needed.
@prculley I think this needs further investigation. I'm surprised that your original fix didn't work in all cases.
So I figured out where the 2 pix creep is coming from. When Gramps is first opened, only a few icons show in the top toolbar, all of them are provided by Gramps in the 22x22 size. When a db is opened in a view, other icons appear, some of them provided by Gtk. These Gtk icons are only available in 24x24 (and 16x16, 32x32 etc.) size in my installation. Gtk (3.18.9) appears to be selecting the 24x24 icons and increasing the toolbar height by 2 pix accordingly.
In a newer version of Gtk (3.24.14) the toolbar buttons seem to be done a bit differently, they are always the same size despite the difference in icon images sizes. And they appear to be rendered smaller than for the earlier version of Gtk. So this creep issue doesn't show up.
The pane separator that is being stored by Gramps gets adjusted by Gtk as the items in the top half of the pane get resized, and Gramps current code sees this and stores the updated value. Since in my system I open to a closed db with the ftm, the loaded separator value from the ini-file is set with the smaller toolbar height, and then gets adjusted upward as the tree is opened and the full icons set appears.
I think that we need to come up with a better fix. Some users may try to make a small adjustment to show a complete row in a table for example. Their change would not be saved and I can see this being reported as a bug.
Can we just use a newer Gtk version in Windows?
This is not just a Windoz issue, it occurs in many of the older Gtk versions. I'm not sure exactly where it got fixed either. Windows AIO currently uses 3.18.9. Our prerequisites say we should be able to work with 3.12 or newer.
Getting to a newer Gtk for Windows has been difficult, until 3.24 or thereabouts there were a lot of issues with the Gtk Windows adaptation. While I think those are mostly fixed now, the MSYS2 MING64 system I use has built Gtk/GIO etc. for Python 3.9 (I think). I had a short term test build of the AIO out there using all reasonably updated libs, only to discover some other new issues. Like the blobs getting pickled with a new Python version, which made Gramps db modified by the new libs version unreadable by the older libs versions. There were some other window layering issues that were still unfixed also. (I had rebuilt 3.18.9 with code from a Gtk PR to fix these for current AIO. That PR was still not accepted for Gtk last time I looked.) I had tentatively planned on switching to new libs for the 5.2.x releases, where we could spend more time dealing with new potential bugs.
I judged the pixel creep to be more annoying than the possibility that the user would try to make fine adjustments and have them not stick. As usual your judgement may differ.
Windows AIO currently uses 3.18.9. Our prerequisites say we should be able to work with 3.12 or newer.
Using 3.18.9 is a sensible choice. It is used by Ubuntu 16.04LTS Xenial. However Xenial has now reached the end of its standard support so we may wish to move to 3.22 used in 18.04LTS Bionic for v5.2.
When Gramps is first opened, only a few icons show in the top toolbar, all of them are provided by Gramps in the 22x22 size.
What happens if you delete the 22x22 icons? I'm not sure why we still ship them. 22x22 is considered legacy in Gnome, but was part of the Tango icon theme specification.
Since Gtk 3.22 and older versions are now at end-of-life I will close this now. This problem does not occur on Gtk 3.24.
Gramps 5.1.6 for Windows has GTK+ 3.18.9. does this mean that the bottom bar creep returns? I just checked, and yes, the problem has returned, so this patch is still needed.
Version 5.1.6 was the last expected maintenance release in the gramps51 branch.
I am working on the 5.2 release now. This will probably require python 3.8 and Gtk 3.24. The latest policy means that at the time of release we only support of dependency versions that are have not reached end-of-life.