On Sun, 27 May 2007 18:55:52 +0200
Raphaël Jacquot <[EMAIL PROTECTED]> wrote:
> Attila Kinali wrote:
> > Simple example, why this is bad: the gnome screen saver
> > requires a communication path over dbus to disable it
> > (for something like presentations or video applications).
> > This means that if app A wants to disable the gnome
> > screen saver it has to implement dbus support although
> > it doesn't need, nor supports gnome. Not only that,
> > app A has to run on the same machine like the gnome
> > screen saver. Thanks a lot for this well thought off design!
>
> at the same time, running something like mplayer on machine A to display
> on machine B is rather pointless...
This is excatly the way of thinking that I hate with most of
these desktop system developers. The inherent assumption
that their usage of a program, protocol or system is the
only one and noone other is possible.
To use your example of MPlayer, you wouldn't believe
what mind boggling uses of MPlayer i've seen and heard of
over the years. I think the sickest was a system that
delivered video streams to a number of rooms, with a streaming
server as central distribution that delivered a network
stream using TCP sockets(!) to pass a huvyuv streams around,
which go to each room computer, that would run multiple
MPlayer instances, each using the x server on a different
display computer (ie kind of a x11 thin client, just with
out the "thin") with multiple graphics cards in it.
Yes this worked. And given the constraints it was one of
the better solutions.
And video player are not the only applications that need
to disable screen savers. Anything that does some form of
presentation that is user triggered but normaly has to
prevent the screen from burning in is a candidate for this.
Beside, screen savers are not the only application/system that
are suffering from the short sightednes of desktop developers.
Attila Kinali
--
Linux ist... wenn man einfache Dinge auch mit einer kryptischen
post-fix Sprache loesen kann
-- Daniel Hottinger
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
