The funny part is that it doesn’t appear to work. Otherwise:
If this isn’t mis-reported by my window manager, can this be at least an option (can’t see a setting for this in preferences)
It might be that GIMP is displaying a dialogue box asking if you want to save changes, and KDE/plasma (i assume?) doesn’t let the system go to sleep until it’s answered, OR, can’t lock the screen if GIMP is showing a modal dialogue box.
From a quick look, gimp only inhibits logout (alias shutdown) action as shown below:
cookie = gtk_application_inhibit (app, window,
GTK_APPLICATION_INHIBIT_LOGOUT,
reason);
Source: master/app/gui/gui-vtable.c#L1079-1081
So, it’s not clear why this should happen on sleep / lock.
Can you check with other apps (gedit etc) with unsaved changes which perform inhibit ?
Yes I confirm, we only inhibit logout. There is a separate flag for suspend which we don’t use, since the only point here is to remind people they have unsaved work when trying to log out or switch off their system while GIMP is still opened with “dirty” images (i.e. it had modifications since opening which were not saved). Because logging out would just kill GIMP and therefore any unsaved changes would be lost.
As far as I can tell, it works fine on a Fedora 40 with GNOME 46. This is what it looks like when trying to log out:
If on Ubuntu, it also prevents sleep (did you check it does by the way? I.e. that it’s not just an error in the message text), then either there is a bug in GTK or a bug in your desktop system, I’d say. I would suggest to report to Ubuntu first.
KDE shop here so can’t test with Gedit.
Two other apps where I could expect at least a disabled logout are Kate (editor) with an unsaved file, and Firefox while a download is in progress. But neither elicits such a warning in the power management popup nor in the logout procedure.
Perhaps a KDE bug (but then Gimp was the new kid on the block, so the more likely culprit)
It may also be a GTK bug. I don’t know. But for sure, this comes exactly from this place of the code (the “There is one image with unsaved changes!” is recognizable and definitely comes from this) and I double-checked. We only set the LOGOUT flag, as pointed out by @Sid, which is documented in GTK docs as:
Inhibit ending the user session by logging out or by shutting down the computer.
So it should not inhibit sleeping for sure. It doesn’t look like we have a bug in there (well maybe — there can always be bugs! 
—, but relatively to this specific issue of inhibiting sleeping, I don’t see where it could be in this small piece of code).
We could also remove the feature altogether, but on the other end, inhibiting logout while there were unsaved changes has been requested to us for years. 
So that would make other people unhappy.
I looked a bit further. There are only 2 implementations on inhibit in GTK: dbus (Linux) and quartz (macOS). This is the current dbus implementation gtk_application_impl_dbus_inhibit(): gtk/gtkapplication-dbus.c · main · GNOME / gtk · GitLab
It calls the org.freedesktop.portal.Desktop portal and in there the Inhibit method of org.freedesktop.portal.Inhibit object.
Note: I see it does try to reach the org.gnome.SessionManager or org.xfce.Session.Manager portals (I’m unsure of semantic, are they portals? Services? Anyway!) first if they exist, which I assume won’t for you. You can check with a software like D-Feet or similar.
Anyway so the docs for this freedesktop portal is there: Inhibit - XDG Desktop Portal documentation
Now you should be able to test it with D-Feet (apparently now there is a new tool D-Spy too), but the syntax to set arguments always eludes me. There seems to be no basic usage tutorial after all these years. I usually can find it after a hour of search or something, but not today. I tried stuff like ("", 1, {"reason":"hello world"}) (1 would be logout inhibition, cf. the docs for further info), but anyway no much time today. I’ll let you take it from there.
Basically I would have liked you to test, if you can find the correct syntax to send to the portal (if you do, please paste it here; I’ll bookmark this as D-Feet docs! 
). The goal would be to verify if you can simply reproduce the sleep inhibition notification you got. In any case, this is a cross-desktop protocol which should work the same everywhere.
This topic was automatically closed 45 days after the last reply. New replies are no longer allowed.
