When the Desktop::~Desktop singleton is destroyed , it re-enables the screensaver. (setScreenSaverEnabled(true)). If it was previously set to false, it causes the XWindowSystem singleton to be re-created , which leads the DeletedAtShutdown class to jassert , and then (sometimes) a crash indicating memory corruption.
(Btw I think the setScreenSaverEnabled is useless on linux, it uses an api specific to xscreensaver only, which I think nobody uses anymore, so maybe the simplest think is just to remove it).
(Btw I think the setScreenSaverEnabled is useless on linux, it uses an api specific to xscreensaver only, which I think nobody uses anymore, so maybe the simplest think is just to remove it).
xScreenSaverSuspend is still entirely valid - it’s the only long-standing method to control this sort of thing in X11.
Yes but it has no effect, as far as I recall, if one does not use xscreensaver. For example it does nothing on ubuntu, it does not prevent the screen from going blank. There is another way using “dbus org.freedesktop.ScreenSaver.Inhibit” which works, I think, but depending on dbus is really ugly…
Yeah, I recall looking into that before, even for embedded set top boxes. It’s definitely ugly and weird to work with! I think a small wrapper can be configured to cope with dbus… assuming there’s value in doing so.
Do you know if dbus could be a wider spanning solution? How would we find out?
I think it would work on more distributions – but I’m not sure if it is a silver buller: If you look at the xdg-screensaver script (which is, I think, available almost everywhere), it tries different strategies, it seems to mostly call dbus with various arguments such as ‘org.gnome.ScreenSaver.GetActive’ ‘org.mate.ScreenSaver.GetActive’ ‘org.freedesktop.ScreenSaver.GetActive’
so maybe just calling that script is the best solution, but…
I recall trying (a few years ago) to use the ‘/usr/bin/xdg-screensaver’ script in order to temporarily disable the screensaver but it turned out that forking a new process while outputing sound (in the same JUCE application) triggered ugly clicks on my application, so I did not investigate further.
