Proposal of a crossdesktop interface to query several properties about the state-of-the-desktop

[Riccardo Iaconelli]

DISCLAIMER: You might think this is just a creation of we drinking too much 
beer one night or some crack smoking. Still, we kindly ask you to go on 
reading, since we're in a really embrional phase where we're just a little 
point below brainstorming, and we need *YOU* and *YOUR* ideas. Please 
contribute! Your help is very very much appreciated! =)

Hi all, this is Riccardo (ruphy) and Rafael (ereslibre),

We have been talking lately about changes on KGlobalSettings class on our
beloved mailing list :). Following the thread, Riccardo had an idea (this is 
not really true, he had it indipendently and caught the occasion of the 
thread to write a private mail to Rafael, but indeed putting it like this 
gives much more drama to the e-mail :P) about expanding the possibilities to 
check the general status of the desktop (several crossdesktop proprieties) 
from any application.
That way applications that are not based on the desktop environment which is 
currently running can know about major events or statuses of the system.

So, for example, if Totem is displaying a movie full-screen, Plasma knows it
doesn't have to start the screensaver.

Right now, this is only a rough idea, and we could think about what are our 
needs for this interface, and also if this is an idea sane enough to be 
exposed to the public without us being pointed-and-laughed-at for the next 
decade.

You already know that we're insane, so we won't ruin too much our reputation 
with first telling our idea here, and if it turns out to be good, we'll be 
ready to take all the fame and glory. ;-)
In any case it's posted here to be discussed and improved.

So the steps of the plan to conquer the world would be:

* Write a useful-and-reasonable D-Bus interface and propose it as a draft for
 a freedesktop.org standard, using their mailing lists.

* Write a deamon (shall this be just for KDE or crossdesktop?) implementing
 those features.

* Let (KGlobalSettings?) ask for the needed stuff to the daemon, extending
 this class with further API as needed.

* Push this to gnomers more and more.

* Bomb the main cities of the world until we get its control.

Oeps, sorry, the last point didn't mean to go public (yet).


Of course, our current state on that is 0 (a.k.a the-very-first-point). Now,
what we would like to know is what you guys think about this proposal.

- Do you think this is necessary ?

- Do you think this is TheRight™ approach?

- Do you have any more interesting ideas of what could be added to this 
interface?

To be honest, we think this is a very useful step in order to create a better 
crossdesktop experience, with applications behaving in a coherent way not 
depending on the desktop they're currently running on, and all knowing about 
events generated by other applications so they can modify their behiavour 
accordingly.

In a perfect world, this should lead to applications knowing in each moment 
the right thing to do and that automatically adjust their behiavour, without 
requiring to duplicate a lot of code for the same goal (think for example of 
auto-away), and where the user doesn't have to replicate over and over the 
same configurations.

Well, the number of benefits that being a platform brings. =)

This discussion started because of the previous mail on this mailing list with
subject "KGlobalSettings and eyecandy on open/save dialogs". Obviously this 
introduce some new API as well. We would like to introduce for example:

- bool visualEffectsEnabled() const;

That is "hard" by definition to be added to the interface, because there is no
effects to consider from the gnome guys. Still, other projects (say compiz)
could use these to adjust the level of flashiness. OTOH there are other 
proprieties that can be deeply interesting for both desktops:

- bool shouldConserveResources() const;

Similar to Solid::PowerManagement::Notifier::appShouldConserveResources().

- bool fullScreenBusy() const;

This could help Plasma to know whether to start the screensaver or not for
example, or the inverted situation, in which a user is running Kaffeine on 
gnome.

- bool away() const;
Whether the user is or not in front of the computer.

- bool connected()

Are we online?

- ...

Many more to come... (suggestions are very appreciated)

This also introduces a problem: we assume that someone (the libraries or
the apps) when executing actions that modify these parameters tell the DBUS
interface about the change.

Another problematic that could show up is applications that fight to set/unset
some parameters. Think for example of the away status.
What do you think we can do to solve this problem? Maybe some policies so
that some of these proprieties can just be set by the D-Bus daemon?
Or you think that maybe it's better to just get rid of functions like away(),
and have each application handle it its way? (nooo.. booo! this is bad!)

Please just ask if something is not clear in this mail, the concept atm is not
really clear even for us. So it's understandable that you didn't get some 
points,
and even you stupid bikeshedder fools this time won't be called stupid or
bikeshedders or fools. ;-)

Thanks for the incredibly long attention! =)

Bye,
Rafael and Riccardo.

P.S.: This is obviously meant for 4.1 heh, don't worry, we already are in
release mode! ;-)

P.P.S.: Rafael would like to point out that no animals were harmed during the
composition of this mail.

P.P.P.S.: Whoah, gobby rocks for composing mails!

P.P.P.P.S.: I actually wonder how many of you guys managed to reach the end of 
this mail... did anyone seriously read it all? ;-)
-- 
GPG key:
3D0F6376
When encrypting, please encrypt also for this subkey:
9EBD7FE1
-----
Pace Peace Paix Paz Frieden Pax Pokój Friður Fred Béke 和平
Hasiti Lapé Hetep Malu Mир Wolakota Santiphap Irini Peoch
Shanti Vrede Baris Rój Mír Taika Rongo Sulh Mir Py'guapy 평화