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

[Reinhard Tartler]

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

> On Sun, Nov 08, 2009 at 03:48:27PM +0100, Reinhard Tartler wrote:
>> Reimar Döffinger <Reimar.Doeffinger at gmx.de> writes:
>> >> http://git.debian.org/?p=pkg-multimedia/mplayer.git;a=tree;f=debian/patches
>> >
>> > Your mktemp patch at least seems to miss deleting the created directory
>> > again.
>> 
>> Which is not a problem introduced by the patch. So the patch clearly
>> doesn't make the situation worse.
>
> That's certainly wrong, the original configure script does not create
> any directory and it deletes all the generated files (except e.g. on
> CTRL+C, but if that is good or bad is up to discussion).

oh, I'm sorry, you're right. The patch indeed introduces leftover
files. I'm looking into improving it.

>> > The problem with the gmplayer man page is that the command-line for
>> > gmplayer does not work reliably - it works for some options, won't work
>> > for others and for yet others it will overwrite the settings set in the
>> > Gui, permanently.
>> 
>> Again, not a problem by the patch. It has been proposed to remove
>> mplayer-gui in the past, but since it seems to work for some people,
>> removing it is, or at least was, considered to do more harm than just
>> leaving it as it is.
>
> You missed my point: linking to the mplayer man page for gmplayer might
> give the wrong impression that gmplayer can be used the same way as
> MPlayer.
> But I notice that the MPlayer man page is written that way...
> So I guess that makes that change a good idea after all, and I added
> a small sentence about possible issue to the man page.

so you agree to have it applied to trunk/ and rc3/?

If yes, let's commit it then.

>> > Well, and I hope my opinion about the screensaver mess has been said
>> > often enough. My solution to the problem on my PCs is to make sure I
>> > don't have any installed, it's the only one actually working properly
>> > currently.
>> 
>> I have made some research on this topic, but I'm still investigating.
>> You're right and the current situation is indeed a big mess. I don't
>> agree with your conclusion to just ignore gnome-screensaver but am
>> interested in a proper integration. The current patch in the package
>> clearly isn't, and of course needs improvment.
>
> Well, -heartbeat-cmd can work with gnome-screensaver.
> It may have some issues I know of and some I don't, but I can't see how
> you can call it "just ignore gnome-screensaver" when we have that line
> in the man page:
>> EXAMPLE for GNOME screensaver:  mplayer -heartbeat-cmd "gnome-screensaver-command -p" file
> and
>> If your screensaver supports neither the XSS nor XResetScreenSaver API please use -heartbeat-cmd instead.

The problem is that this doesn't work anymore with gnome-screensaver
since (I think) 2.24.

See for details:
 - https://bugzilla.gnome.org/show_bug.cgi?id=579430
 - https://bugs.launchpad.net/ubuntu/+source/gnome-screensaver/+bug/428884

In short: The gnome guys thought that it might be a good idea to invent
a new "inhibit" API that covers:

 - inhibiting the screensaver
 - inhibiting DPMS
 - inhibiting suspend policy
 - inhibiting ejection of removable media (CD, DVD, etc.)
 - does not break applications that monitor the IDLETIME counter (think
   of instant messangers like pidgin that set you away if you are inactive)

The current patch breaks the last point, btw.

anyway, the bug I've referred above means that applications that call
'gnome-screensaver --poke' as you propose do no longer inhibit the
screensaver. This makes -heartbeat-cmd in the end rather useless with
gnome-screensaver.

The new API allows the application to choose what should exactly be
inhibited. You can indeed use this API on the commandline, but unlike
the --poke command, the new --inhibit switch *blocks* and inhibits the
screensaver as long as it is running.

As said, the whole situation is a severe mess right now, and I'm still
thinking about how to solve this properly. I see several options how to
solve this, but I want to investigate them further before actually
proposing any change.

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