Not really a gdk-level problem, I think. 
The screensaver should expose some dbus interface to control this.

"The screensaver should expose some dbus interface to control this."
Well, that would be a good solution if win32 screensavers used d-bus...

Created attachment 72853 [details]
GtkDesktop object header

Created attachment 72854 [details]
GtkDesktop object implementation

Here's a prototype, based on the code from Totem, to have an API for simple screensaver operations.

I've called it GtkDesktop to allow the addition of more hooks for other desktop features.

It is missing the Windows implementation, but just want to make sure, first, that it is ok to depend on D-BUS (optionally), and second, if the API makes sense or if it would make more sense in GDK

Thoughts - 
 - GtkDesktop is pretty broad, I liked my GdkSession, or since there are 
   four methods and a signal, maybe even GdkScreensaver
 - the code would ideally be set up to support multiple platforms without
   just using #ifdef, e.g. the way a lot of GDK works is that there's 
   an abstract base class or interface and then platform-specific 
   implementation classes
 - I think dbus-glib is a little API unstable / broken still, while dbus
   proper is in release candidate about to be 1.0 and fairly bombproof.
   I usually use just the main loop hook from dbus-glib and then use
   raw DBusConnection for that reason. Not that dbus-glib can't be 
   fixed, but it does not really have an active maintainer afaik.
 - should the enable/disable API be more abstract, like 
   set_showing_fullscreen_thingy(), and the GDK backend figures out that
   should involve disabling the screensaver plus possibly other stuff?

> - GtkDesktop is pretty broad, I liked my GdkSession, or since there are 
>   four methods and a signal, maybe even GdkScreensaver
>
the idea of using GtkDesktop is to add more desktop access functions there, like the equivalent to desktop_launch or any other things from the 'GNOME desktop integration lib' thread at d-d-l. I think the session management should still be in a separate GdkSession, and, maybe, have access to it from a gtk_desktop_get_session function.

Similarly for GdkScreensaver, if you think so, it can be a separate class in GDK, but I'd like to keep the GtkDesktop object as the way to access desktop-related services.

> - the code would ideally be set up to support multiple platforms without
>   just using #ifdef, e.g. the way a lot of GDK works is that there's 
>   an abstract base class or interface and then platform-specific 
>   implementation classes
>
yeah, #ifdef's suck, but we could still have a gtk-desktop-windows.c, gtk-desktop-unix.c, etc files with the implementation.

> - I think dbus-glib is a little API unstable / broken still, while dbus
>   proper is in release candidate about to be 1.0 and fairly bombproof.
>   I usually use just the main loop hook from dbus-glib and then use
>   raw DBusConnection for that reason. Not that dbus-glib can't be 
>   fixed, but it does not really have an active maintainer afaik.
>
oh, glib bindings are being used by gnome-screensaver itself, and totem. But yeah, if not maintained, we can change the code to use D-BUS API directly.

> - should the enable/disable API be more abstract, like 
>   set_showing_fullscreen_thingy(), and the GDK backend figures out that
>   should involve disabling the screensaver plus possibly other stuff?
>
maybe, what other screensaver-like things are used in other systems?

I like the idea of a desktop abstraction, kind of like the win32 shell API.

what about adding a signal like:

  void (*network_changed)  (GtkDesktop       *desktop,
                            GtkNetworkStatus  status);

to GtkDesktopClass, where GtkNetworkStatus is defined as:

  typedef enum {
    GTK_NETWORK_OFFLINE,
    GTK_NETWORK_CONNECTING,
    GTK_NETWORK_ONLINE,
    GTK_NETWORK_DISCONNECTING
  } GtkNetworkStatus

to avoid querying NetworkManager directly using D-Bus or through libnm-glib?  we could add a set of functions too:

  GtkNetworkStatus gtk_desktop_get_network_status (GtkDesktop *desktop);
  gboolean         gtk_desktop_is_connected       (GtkDesktop *desktop);

sorry for the spam, discard the previous comment: I did not read the bug title.

(In reply to comment #2)
> "The screensaver should expose some dbus interface to control this."
> Well, that would be a good solution if win32 screensavers used d-bus...

How about making a win32 screensaver helper, then?

DBus seems to be the right way to do this with our platform, and if Win32 doesn't fit, then make it fit!

Yes, making a win32 screensaver helper is on the plan, so if you can provide that part in a patch I'd add it to my code :-)

In the form of some kind of windows-screensaver-daemon that follows the FDO screensaver DBus API and translates calls into Win32 calls?

No, just the win32 calls would be enough. See that the code uses DBus to talks to gnome-screensaver, and there should also be support for xscreensaver, so the DBus part is just one of the implementations, that's why it probably makes sense to split the gtkdesktop implementation into gtkdesktop-dbus|windows|macos|etc.c files.

IIRC xscreensaver's commandline tool disables it for an hour only, and it's up to the applications to call it again in time...  The idea is to not risk leaving the screensaver turned off if an application crashes.  Something to have in mind in this bug.

The code in Totem pokes the screen as if you were typing, which I guess is a bit better than switching off the xscreensaver altogether...

(In reply to comment #15)
> The code in Totem pokes the screen as if you were typing, which I guess is a
> bit better than switching off the xscreensaver altogether...

I know.  Please, don't suggest that approach be used in Gtk+.  That's why for months when I was playing a video using xine and also working, holding shift for a few seconds caused my keyboard layout to be switched to Persian, yeah...

(In reply to comment #16)
> (In reply to comment #15)
> > The code in Totem pokes the screen as if you were typing, which I guess is a
> > bit better than switching off the xscreensaver altogether...
> 
> I know.  Please, don't suggest that approach be used in Gtk+.  That's why for
> months when I was playing a video using xine and also working, holding shift
> for a few seconds caused my keyboard layout to be switched to Persian, yeah...

How is xine-ui's code brokeness relevant here? :)
I didn't see any such reports against Totem...

(In reply to comment #17)
> (In reply to comment #16)
> > (In reply to comment #15)
> > > The code in Totem pokes the screen as if you were typing, which I guess is a
> > > bit better than switching off the xscreensaver altogether...
> > 
> > I know.  Please, don't suggest that approach be used in Gtk+.  That's why for
> > months when I was playing a video using xine and also working, holding shift
> > for a few seconds caused my keyboard layout to be switched to Persian, yeah...
> 
> How is xine-ui's code brokeness relevant here? :)
> I didn't see any such reports against Totem...

Xine seems to emit synthesized Alt-Left keystrokes, and I used to use left Alt+Shift to switch keyboard layouts.  Can't reproduce it right now though.

See also bug 338889 comment 6 and below to see some comments about the API.

Code to disable the screensaver on win32:
http://www.codeproject.com/KB/system/disablescreensave.aspx
Quartz code:
http://developer.apple.com/samplecode/FullScreen/

To be compatible with Windows, we'd need to use an API tied to a window.

Windows will send WM_SYSCOMMAND to the window, which should return 0 if the command matches SC_SCREENSAVE, or SC_MONITORPOWER, and screensaver is disabled, see src/video/win32/SDL_win32events.c in SDL.

For MacOS X, the trick is to update the activity counter, and tell the screensaver to stop (and do that on a regular basis. See http://gitorious.org/xbmc/xbmc/commit/715eb4e

Methods:
GtkScrsaver *totem_scrsaver_new       (GtkWindow *window);
void gtk_scrsaver_enable              (GtkScrsaver *scr);
void gtk_scrsaver_disable             (GtkScrsaver *scr);
void gtk_scrsaver_set_state           (GtkScrsaver *scr, gboolean enable);

Properties:
char *application_name ; /* Only used on X11 with dbus*/
char *reason; /* Only used on X11 with dbus*/
GtkWindow *toplevel; /* must be non-NULL */

I'd make this bug depend on dbus bindings getting into glib, but can't find an open bug about it.

We have most of the proposed items here now, I think, with
gtk_application_inhibit and GNetworkMonitor