Could a loader progress window be created when starting Gramps?
A number of the negative Reviews on Gensoft trace back to attempting to double-launch Gramps.
With all of the Python modules being loaded (including Gramplets), the delay between double-clicking the application and the icon appearing is long. (29 seconds on my Windows10 box and another 15 seconds registering the plug-ins.)
New users often think the application failed to launch and double-click again… and again.
Some sort of fast appearing tiny progress dialog would alleviate that particular confusion.
Gramps totally ceases up mys win 10 system to the point that a ’system ‘crash’ and cold boot is necessary to resume operations.
When I try to open the program it says it is already running, although it does not appear so on either the screen or tray and the base of the screen.
Gramps for Windows Review by J, Jan 11, 2017
Rating
I am very frustrated. I don’t know whether this is just awful software; nobody has tried it on Windows 10 or I am doing something dumb. I have uninstalled it about 10 times. My computer says it is successful uninstalled. I restart. I download again. I select the option for the program to be used by anyone using my computer.
When I reinstall, I get an error message saying “Gramps is already running.” If so, I can’t see it and it should not be running. Then I see all the old trees I can’t open—that’s why I reinstalled! I try to import a GEDCOM. (I’ve also downloaded that about 10 times from a different site.) It says it’s locked by me, even though I selected the option for anyone using my computer to be able to use the program. It says to use the “force unlock” option. I can’t find such an option. The links on the dashboard to the Gramps site do not work at all. If I go to the site and use the wiki, half the links are to things different from what is indicated. I can’t find the force unlock option anywhere.
Biggest Pro: It’s free
Biggest Con: It doesn’t work; the manual is useless; the links in the dashboard don’t work, etc.
You could say one already exist that is if you are using the old portableapps.com version of Gramps so the question is could the Gramps project use that same method or code?
The technical name for the loader progress window is the Splash screen.
Launching the first time, Gramps takes about 24 seconds to display anything on my system. (Older MacBook Pro with a Core i7 and spinning drive). A second launch takes less than 3 seconds. Not knowing anything about Python, GTK, etc, I can’t say what that means. On the first launch, it is about 12 seconds before the Python interpreter even appears in the OSX Activity Monitor.
A splash screen sounds like a good idea. However, is there anything that Gramps is doing at launch that could be deferred to later?
Does Gramps launch a lot faster on systems with an SSD?
One of the problems with a loader progress window is that the usual slowdown is actually the Gtk libraries and their dependencies getting started. So the loader window could not be shown until most of the time had elapsed.
If everything is working normally Gramps should be showing a window with 5 sec of startup; about 3 sec on my machine. Getting everything shown might take a bit linger, depending on the number of items shown in the view selected.
One issue we have had in the past is font scanning, done by the fontconfig library on behalf of Gtk. If you have a lot of fonts, this can take a while, minutes even. The library tries to cache the results so it doesn’t have to scan each time it starts, but sometimes the cache files get corrupted or cannot be written. In this case it takes a long time to start Gramps every time. It will also take that time if a change to the installed fonts occurs. On Windows, during the installation, the installer performs this scan with its results displayed in the installer window, which usually avoids the need to do it during subsequent startups.
If you have a utility to monitor file usage on your OS, you can see what files are accessed during Gramps start; this will give an indication if some problem is in this area. The Process Monitor https://docs.microsoft.com/en-us/sysinternals/downloads/procmon can do this for Windows. If you see every font being accessed, this may be an issue.
The libraries & dependencies would be a problem. I think it is probably the reason that projects like Lightweight Cross-Platform (Windows/Linux/MacOS) Splash Screen exist. (That one is a BSD 2-Clause License. But other projects may exist.) However it is unclear how such a Splash Screen should be integrated into the launch sequence.
In the old DOS days, instead of a launching the .exe application, we’d link the application icon to a .bat batch file. The batch would spawn a lightweight Splash Screen thread, then launch a loader program. Finally, it would kill the Splash thread only after the loader reported a successful initialization.
I’ve gotten accustomed to latency in loading behavior and can ignore it. This kind of Splash screen suggestion is just about the first impressions of new users. I don’t know if it is worth the vetting process.
However, I do have hopes that someday I could distribute our Family genealogy WITH Gramps… WITHOUT hearing back that they gave up in frustration.
The second launch is quicker because the system has a bunch of the files cached after the first launch.
Related to this topic is the amount of time gramps takes to quit. I understand what it’s up to (I think), but it would be nice to have some graphic feedback in the form of a changed cursor. Otherwise I wonder whether I’ve actually told it to quit.
The progress bar for the ‘backup on Exit’ in the lower left of the status bar IS pretty small. But that process is multi-threaded. You can do tasks in other application while Gramps is doing a backup. (I’ve changed Views during backups but haven’t tried deliberately Modifying the Tree in the midst of a backup.)
But I’m pretty sure changing the cursor to a Busy is only for operations that don’t permit any other action.
On a Mac, when you quit, you definitely can get a changed cursor while the app does whatever it needs to in the interim. And I have to retract my claim that Gramps doesn’t do that. At least sometimes, I do get the watch cursor.
The other thing that happens normally is that the app menu gets highlighted, to indicate that a menu item has been selected (“Quit”). This occurs even if you do a CMD-Q to quit. That does not happen in Gramps.
On my Ryzen 3900x with 2 SX8200 Pro NVME SSDs, 64GB of RAM.
English Windows 10 Enterprise, Norwegian input language but English System language, and with any of this shortcut:
%comspec% /c set LANG=en_US.UTF-8 && start grampsw.exe"
%comspec% /c set LANG=no_NB.UTF-8 && start grampsw.exe"
Connecting to a sqlite database, it takes 10 seconds from I push the shortcut to anything seems to happen, it takes another 8 sec before my small database is loaded, and it takes nearly 20 more sec to load my database with 32000 place names…
(Both are small datasets in compare to many others)
That is for first time load of Gramps, second time load is blasting fast, les than 2 sec. as long as the libraries and database is in memory.
But it only use one logical CPU on load.
This Workstation are brand new with clean installed OS and all software is also clean installed.
I think most of that time is unpacking the libraries… the 10-30 sec load time (Inncluding data) is not a big problem for me, but the question is if it would go faster with multi thread and maybe without the zipped archive of libraries… I don’t know the impact that has on the file load…
For new users I really think it would be a good idea to get better feedback when both starting gramps and closing, even if the starting splash screen only comes up halfway of what it takes gramps to start up currently, it would be better than nothing.
There is also no feedback when gramps is closing, it just seem like it becomes non clickable and then a while later it gone. Would be nice if it at least came up some popup with “Closing gramps…” or something that was easy to see.
It seems like a Splashscreen might also have a Prerequisites branching.
It could offer the option to abort launching Gramps and launch an installer (that has been fed the current list of missing prerequisites) where that installer can request Administrator rights.
However, this Splashscreen option should be offered with the assurance that the missing prerequisites only prevent auxiliary features, not basic functionality. And that Administrator rights are only temporary and will be revoked before Gramps is launched again.
