[MPlayer-dev-eng] removing rc2 from mplayerhq.hu

[Reinhard Tartler]

Reimar Döffinger <Reimar.Doeffinger at gmx.de> writes:

>> The problem is that this doesn't work anymore with gnome-screensaver
>> since (I think) 2.24.
>
> Well, I see you are trying your best, so it's unfair but you know what
> really annoys me? Once again everyone has to live with annoyances like a
> mouse pointer that wiggles around like drunk (yes, I know it only
> happens when it's hidden, but it is still noticeable) just because the
> gnome-screensaver guy _still_ can't get their act together - this kind
> of thing is going on since _years_.

I fully agree with you here. And, you're not the only one that is
annoyed.

What annoys me most: While the API is in my eyes indeed a technical
improvement, it leaves all non-gnome applications in the code.
Seriously, I do not expect KDE or XFCE applications to send a dbus
message on the session bus to the adress "org.gnome.session.Inhibit".
This just feels more than odd.

While there is the MIT-SCREEN-SAVER extension, it is not implemented in
gnome for a couple of reasons that I can understand to some extend.

> I'm tempted to suggest that you just patch gnome-screensaver to not run
> when there's a program named "MPlayer" or "VLC" running, that puts the
> hack at least where the stupid code is (and if this list was
> configurable, that would actually make it a useful feature - it could
> even be done in gnome-session if the gnome people think that's where the
> screensaver handling belongs - though I heartily suggest that just for
> once the _first_ design the API and the implement it instead of
> implement something an notice the need a new one a few months later with
> nobody bothering to keep the old one working).

Your idea is actually pretty similar to something I'm considering:
Writing an inhibiting wrapper. That wrapper would be started instead of
the real mplayer binary, inhibit the screensaver and call mplayer with
all arguments. I'm still pondering if this idea is just a brainfart or
actually a real option.

But anyway, I would expect that if no video is played or playback is
paused, the screensaver and power managment is *not* inhibited. Neither
your original idea nor my wrapper approach addresses this.

The first idea I had was to check if XScreenSaverSuspend (this is what
mplayer is currently doing if compiled with XSS support) resets the
IDLETIME counter. It turns out that it doesn't. I'm still pondering if
it was a good idea to make it to do so. On the one hand it would
instantly resolve problems with currently existing applications like
mplayer and vlc. On the other hand, resetting the IDLETIME counter
(too) aggressively defeats its purpose.

I'm currently looking at xscreensaver, and want later to look at
kscreensaver how they implement MIT-SCREEN-SAVER to get more insight how
this side of the protocol is implemented. Perhaps gnome-screensaver can
be extended to implement that extension /in addition/ and proxy it to
gnome-session.

Anyway, I'll keep an eye on this new inhibit API and see if and how it
is being adopted by other desktop environments. Because I still think
the general idea isn't too bad after all.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4