Hi,
This PR causes Geany to save the project whenever a file is opened or closed.
The main issue it has is when opening/closing multiple files it saves the project file between each file. This does not happen on startup or when quitting but could still be an issue.
It should fix https://github.com/geany/geany/issues/1826 You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/1860
-- Commit Summary --
* Save project when opening or closing files * Don't try to save project if none is open
-- File Changes --
M src/document.c (17)
-- Patch Links --
https://github.com/geany/geany/pull/1860.patch https://github.com/geany/geany/pull/1860.diff
As discussed in #1826 please add an option so this is not forced on all users. Perhaps in Project->Files would be a good place.
IMO this is is a bad workaround. We should simply support session managers (there was a development branch on that topic a long while ago), then we could also synchronize other settings.
I'm especially negative if it adds a weird setting, by demand.
Also, the same issue applies for the default session (no project open)
Agree that we should support session managers, `GTKapplication` says it supports session management, but I can't see how.
We don't use GtkApplication.
- It's GTK3-only isn't it? - Does it support multiple instances? I think it doesn't, at least not by default
Perhaps @codebrainz knows better
@kugel- The previous session support PR used an X11 only library which was out of date even back then, and thats why it never got committed (IIRC).
My quick google didn't find any other portable session management libraries, thats why I looked at gtk_application, but don't know exactly what its capabilities are for session management, seems to have no documentation. I do remember a previous discussion where the multiple instance issue was mentioned. GTK3 only is fine IMO.
Even if we do find gtk_application is the way to go, I expect it isn't going to happen tomorrow, so a cleaned up version of this PR may be useful in the interim.
We should simply support session managers
We kind of do, we handle `SIGTERM` and shutdown cleanly when received. In the usual case, the 10 seconds or whatever that `shutdown` gives, should be enough time to save everything and finish closing. I think on modern systemd systems, it additionally sends `SIGHUP` and gives 90 seconds by default[citation needed], which would should be lots of time for network shares and such, even with a slow link. If this code isn't working, we should probably fix that first.
It's GTK3-only isn't it?
AFAIK it is.
GTK3 only is fine IMO.
It is not. GTK+2 is still the runtime used for Windows, Macos, and by default for the source release. Given that it would probably require fairly invasive changes to some of the code, I don't think it would be the kind of thing we want to guard-out using `#ifdef` stuff all over the place for GTK+2. I could be wrong though, maybe it would be simple enough to abstract it out with a our own GeanyApplication class that can adapt to the GTK+ version.
Does it support multiple instances? I think it doesn't, at least not by default
If you mean independent processes, you could probably get it to do that, but I believe the main operating mode is that it supports multiple main/top-level windows, which in well encapsulated code bases is effectively the same thing (minus the process isolation).
People might also get annoyed by adding a dependency on DBUS, and AFAIK it isn't well supported and is effectively disabled for GtkApplication for Windows.
We kind of do, we handle SIGTERM and shutdown cleanly when received. In the usual case, the 10 seconds or whatever that shutdown gives, should be enough time to save everything and finish closing.
Probably not, the callback calls `main_quit()` which asks about unsaved files, so unless its a fast user or everything is saved, even longer is probably not enough.
IIUC the systemd timeout only applies to services it starts, interactive GUI processes get theirs from the session manager, which IIUC is only required to give time to apps that registered for a "save yourself" call, which Geany is not.
Probably not, the callback calls main_quit() which asks about unsaved files, so unless its a fast user or everything is saved, even longer is probably not enough.
Like I said, we should fix this code then. At the very least Geany could save anything that doesn't require user-intervention, like the list of open files, preferences, etc.
IIUC the systemd timeout only applies to services it starts, interactive GUI processes get theirs from the session manager, which IIUC is only required to give time to apps that registered for a "save yourself" call, which Geany is not.
I'm certainly no expert here, but as I understand it, the "session managers" in X, Win, Macos, etc. are to allow applications to inhibit shutting down until the user can respond to request to save work (or some timeout expires, presumably). But I do not believe that they, even in the absence of any special hooks, just `SIGKILL` every process immediately. Graphical environments like X would presumably try to close the windows (as if the user clicked the X button), allowing them to save some state, or at the very least send a `SIGTERM` and give them N seconds to cleanup. Again, not an expert here, but the `SIGKILL` seems like the least likely thing "session managers" or any sane user-space process manager would do on shutdown (on a desktop/server/etc).
are to allow applications to inhibit shutting down until the user can respond to request to save work (or some timeout expires, presumably)
I looked at the Gnome session manager docs which say (in bold) __applications should not assume they can block logout or shutdown__. Qt says something similar. So no, its not guaranteed that they will have any time available.
Essentially session management (especially at shutdown, but also logout) seems to be impossible since the session manager can also be overruled by the shutdown process.
Really the only way of saving stuff is to keep everything saved as we go, and hope that its never killed half way through the save :(
Users can use the save actions plugin to save files, all we need to add is project and user sessions, maybe save actions could be extended to periodically save them too?
So no, its not guaranteed that they will have any time available.
Right, but it's their entire purpose, so presumably they usually work. Moreover, I'm not talking about "session managers" as such, but rather just well-behaving Linux systems.
I just whipped up a simple test application that sleeps for some time in an infinite loop and logs signals. I tested in a VM with a modern systemd-using distro (Elementary) and it indeed seems to wait around 90 seconds before truly killing the process. I also made it voluntarily quit after around 10 seconds after receiving the signals and the system waited around 10 seconds, and then rebooted.
Of course none of it means it's guaranteed, but it shows that the system does as expected in the common case.
@codebrainz I wasn't meaning to imply no systems work none of the time, I'm sure some systems work some of the time, it just can't be guaranteed that all systems work all of the time.
And if there is an unsaved file the user needs to be paying attention to action the dialog or the timeout will expire anyway.
And if there is an unsaved file the user needs to be paying attention to action the dialog or the timeout will expire anyway.
Right, but their session file list (and preferences, etc) will get saved even if they aren't paying attention, which is what this PR, #1416 and #1826 are about, and why it might be worthwhile to fix the bug in Geany that prevents saving other stuff because it's waiting for human confirmation about the unsaved files.
Yes, saving the project and user files before saving edited files is another option.
Does saving the project involve saving the current line:column position? (#1117)
@dandv line/col is saved for open files, not for recent files.
Random idea: maybe use a signal like "project modified"? Would allow to save projects somehow "soonish", when needed/wanted according to preferences and with freeze-thaw be able to easily dedup the signal when opening or closing multiple files.
Closed #1860.
Should be implemented via #2114.
github-comments@lists.geany.org