Recently a user entered a bug that we blamed on our older version of the Gtk library used for our Windows release. There are several of these in the Gramps bug tracker.
I decided to create a new Windows release that uses all the latest libraries available in the MINGW64 ecosystem we use for Windows releases.
The Gramps code is identical to 5.1.2, and it will report itself as such.
I regard this as somewhat experimental, I’ve tried it out and it appears to be working, but I certainly have not tested everything. If you find bugs using this which don’t appear in the regular release, please report them on the bugtracker. And report here if it seems to be better or is fixing something that has bothered you.
If this goes well, I may use this as the base for future releases.
This uses Gtk 3.24.14 (the old one was 3.18.9).
Python is also upgraded to 3.8.2 from 3.6.2.
almost everything else was upgraded as well (except bsddb).
I’m seeing some more deprecations that I will submit a PR for; and so far one crash (also due to a deprecation/removal in a Python 3.8 library) in Quiltview. I can fix this in addons right away.
I’m nearing the point where I’ll be forced to uninstall this version of Gramps because of the priority/stacking problems. It is becoming too frustrating to use.
The windows stacking order was a problem when I first started using Gramps. I remember filing a bug about modal dialogs being behind other Windows & that was addressed… but I can’t find that bug report now.
My workaround (before it was fixed) was to toggle to another application & back. Gramps would refresh the window order correctly. Hitting the ‘Escape’ key would also dismiss the dialog.
(The App toggle trick is what I continued to do because the Clipboard often loses its ‘always on top’ priority.)
But now, even after toggling between apps, the active Edit Event or Person window/dialog often remains visually pushed behind its parent Gramps window but the gadgets seem to invisibly accessible.
Where I see incorrect stacking/priority behavior most consistently is when adding an Event to a Person while in the Relationship View. Clicking in the Description field causes the Edit Event dialog to retreat behind the Edit Person or Edit Family dialog. Clicking a 2nd time in the same spot (even though that spot now shows a different dialog) restores the order AND sets the insert point into the Description field.
That’s a different flavor of bug that is controllable procedurally. That is a “Doctor, doctor, it hurts when I do this… and the doctor says - So don’t DO that!” type of bug.
The reporter was clicking on a button outside the active window and starting a series of unfortunate events. ('OK’ing a parent window discards unsaved data in the spawned window. And I certainly HAVE done that by accident. It is arguable that Gramps should require a confirmation of a Close that loses data. Like the confirmation when closing a browser with multiple tabs.)
On the other hand, my problem is a refresh error. While the GUI redraws like the focus is on one window, the active area definitions are focused on another window.
I too have seen the problem and most notably when adding a place from the event edit window. And it might be compounded because when adding a place I will have the place’s Wikipedia’s page open and trying to navigate between Gramps and the browser. Even if I can see the Gramps window behind the browser, it takes going to the Gramps icon in the taskbar to bring up the active Gramps window. Doing this will often not display the full stack of open Gramps widows but enough to start clicking OK to work back through the stack to where I am back to the person’s window.
When you have paid in-house alpha testers, you can justify putting them through the wringer … and you can enforce continued working of the test plan… up to the point of discovering catastrophic failure bugs. (Those that threaten to eat the computer.)
But beta testing for the field is different. We don’t have a test plan. So we’re doing ‘use’ testing. When there’s a useability flaw the quality of testing drops precipitously.
Since this is a not an emergency update, why not suspend testing if we find such a major usability flaw? We can pick it back up when there is a patch.
All true. But we chose to use Gramps and not Family Tree Maker.
@prculley said that the upgrade to the underlying library structure may solve other issues users are seeing. So far I have not seen any issues other than this window/focus issue and the loss of the backup thermometer. Bug 0011642. I am not seeking out issues, just seeing what crops up as I go about my work.
And my current work is catching up on a source that I can do with the Covid-19 shut down of activities. As I already said, the window/focus issue seems to occur when I am adding a new place so is not happening enough to abandon this new install. But we each do what is best for ourselves. After all, there are some users still on 3.4.9.
I was transcribing a newly identified branch of the family but haven’t had to add any new places to that hierarchy.
But the focus & redraw issue sounds similar in that it affects an Edit floating window.
I’ve had other problems (including a spontaneous exit & apparent endless loop during a mass tagging) but those occur in the main version in similar situations. It seems normal to have problems if Gramps isn’t allowed to finish refreshing the interface before requesting the next action… I got impatient. And Tagging became much slower with ver 5.1
Also, I deferred testing @SNoiraud 's genealogical symbols patch to look at this libraries update. (There were a number of people responding in the symbols project but nobody had responded to Paul yet. I already owed him Paul a number of fixes, workarounds & great responses.)
But now I’m overdue on providing some feedback for the symbols interface patch and need to get back to that.
I’ve looked into some of these issues. The progress meter issue I understand; I still think this is a bug in Gtk (or at least a change in ‘feature’) but I understand it. It would be non-trivial to work around it.
The Windows stacking issues are much more problematic. Gramps itself is not involved in how windows are stacked, (Except when using the ‘Windows’ menu to bring something to the foreground). This seems to be entirely handled in Gtk. It is not clear to me yet, if Gtk is handing some of this off to Windows itself to manage the stacking/redraw, or if Gtk/Gdk is operating a mini-window manager and letting the win32 API think all of Gramps/Gtk is a single application. Either way it seems as if Gtk or its win32 adapter code is responsible for getting this right.
As I said when this was posted, I regard this as experimental; if you don’t like it, re-install the standard version with the older libraries. Sometimes it is better to have the bugs you know that the ones you don’t.
A new issue with this has come up. It turns out that due to the most recent Python 3.8 version, the data stored in the bsd db is incompatible with data stored by prior versions. So it may not be possible to open your db with a prior version without error. You can still export to XML with this version and open with the standard version. This doesn’t affect sqlite dbs.
Because of this, I have removed this Windows release from the web site.
Note for those interested: the underlying problem is that Python 3.8 has upgraded the pickle protocol to version 5, which prior versions of Python cannot read. We store pickled data in the db, which is why this affects users who might want to switch between this new libraries version of the AIO and the standard version.
