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

Adam Tlałka atlka at pg.gda.pl
Fri Nov 20 09:11:33 CET 2009


On Wed, 2009-11-18 at 18:55 +0100, Michael Niedermayer wrote:
> On Sat, Nov 14, 2009 at 06:43:47PM +0100, Reinhard Tartler wrote:
> > Attila Kinali <attila at kinali.ch> writes:
> > 
> > > Hoi Reinhard,
> > >
> > > On Sun, 08 Nov 2009 20:25:31 +0100
> > > Reinhard Tartler <siretart at tauware.de> wrote:
> > >
> > >> 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.
> > >
> > > What would that reason be? I've fought enough with screensavers myself
> > > to know that the mess we have is to a big part because people are
> > > unable to read the X standards. Especially the gnome guys have quite
> > > a history of that.
> > 
> > g-s-s features 'fading' to black, so that you can abort the activation
> > by moving the mouse.
> > 
> > I'm not convinced that it is not possible to integrate this with
> > MIT-SCREEN-SAVER, but that extension alone is certainly not enough to
> > implement that.
> > 
> > > IMHO, patch the gnome-screensaver directly, not all the other apps
> > > to _follow_the_standard_that_everyone_else_agreed_to_.
> > 
> > I obviously haven't followed as many multimedia applications as you
> > have, but alone the fact that xscreensaver has made the MIT-SCREEN-SAVER
> > integration optionally makes me wonder how relevant this "standard"
> > actually is.
> > 
> > Anyway, the argument to stick to a given standard is as limited as the
> > technical merits of it. E.g. MIT-SCREEN-SAVER doesn't offer inhibiting
> > power policy managers, at least not gracefully. But don't worry. I feel
> > that this is not even properly implemented or thought of about enough in
> > gnome itself. So no need to hurry right now, IMO.
> 
> ive not followed this thread but if a standard is bad, improve the standard
> (in a compatible way and in one that is easy to use for everyone and document
> it well and somewhere where everyone can find it)
> If one cant improve a standard then one should write a better standard.,
> that is easy to use
> for everyone and document it well and somewhere where everyone can find it
> 
> if i understood above correctly gnome uses some propriatery system to
> interact with their screensafer (let me guess, their leader is called bill
> gates nowadays?)
> 
> Ahh and if an incompatible screensaver is detected that doesnt follow the
> standard, print a warning about the broken screensaver and suggest the
> user to install a differnet screensaver or use killall
> 
> above is my oppinion of course not some kind of request to do this though
> i would be happy if one did
> 

I did some patches according to screensaver issue. Hiding mouse cursor
and doing fake mouse movements in the area of mplaer window worked with
every desktop environment (Gnome, KDE, etc) or even clean X11.
Maybe it is some kind of hack but working just out of the box.

Another, proper IMHO, way is XResetScreenSaver(dpy) X11 Xlib function.
It resets DPMI counters and should deactivate any compatible
screensaver ;)... . So calling XResetScreenSaver(dpy) periodically
should do the job. There is one but - the screensaver program should
check DPMI counters (or properly use X11 extension).
So xscreensaver, gnome-screensaver, KDE screensaver should be corrected
to use this method.
Usind DBUS, dcop or other sophisticated method is just overkill and not
portable.

I suggest implementing the hack and also proper method and give an
option to choose desired method.

Regards

-- 
Adam Tlałka <atlka at pg.gda.pl>




More information about the MPlayer-dev-eng mailing list