Installed 5.1.6-1 over 5.1.2 for “just me” on W10, and the following came up in a console window before any load db dialog:
2023-07-06 22:57:04.390: WARNING: dummydb.py: line 1420: database is closed
Looking at the Github file, there appear to be a multitude of conditions as to the generation of the message, narrowing down on them might help, if it is indeed related to this issue at all.
I like the console reporting, and as it has been some years, obviously, between takes, it would be more explanatory if the first console message was in fact something like:
*** Gramps Console Ready to Report ***
When Gramps is running in the background against other Windows applications, the following are frequent:
(gramps.exe:5992): Gdk-WARNING **: Failed to OpenClipboard on window handle 00000000001207f0
As this is all of very minor severity, the feature request simply amounts to a way of filtering the messages so that an important Gramps related warning won’t be hiding in a jumble of clipboard warnings, for example.
This is a warn, not an error. The warning occurs every time a view or Gramplet tries to initialize with data from the current tree but a tree is not yet loaded. In other words, a LOT of warnings while the users is loading or changing trees.
To reduce new user alarm in the 5.2 version, the dummy.db message will be re-routed to the log instead of the console. see MantisBT request 12492
I do not recall discussion of the clipboard warning be re-routed to the log. Seems like that would be a reasonable change.
Just a follow up to the above installation, closed the console window (without closing Gramps), and the Gramps window was now not visible, and consequently not found.
Ran it again, and broke the lock on the previously loaded database, no console window on this, or subsequent loads of Gramps. Will report if the console appears again on Gramps load after a fresh Windows boot.
When starting from the CLI (or from the Gramps console GUI icon), the console is the control process for launching Gramps and for receiving feedback messages. And both remain intimately linked. Closing the console kills the child… the Gramps process.
And Gramps does not die cleanly. Cached transactions might be lost and the tree is left ‘open’. This will cause an error (“parsing arguments”) the next time to try to load the locked tree. You will have to remove the lock to close the tree. Fortunately the Manage Family Trees dialog has GUI for breaking a lock.
Thanks, and noted.
After a clean boot, on starting Gramps, the console window first flashed in and out, and then appeared no more. Thus we can conclude it’s more in play wen first launched after a fresh Gramps installation.
There’s lots happening on first use. All the Pyhton source modules are being compiled & cached for your system. So the first launch is massively slower than subsequent ones. Several things need the console in case the GUI fails to complete initializing.
