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

[Aaron J. Seigo]

On Monday 26 November 2007, Riccardo Iaconelli wrote:
> * 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.

the daemon should be provided by the desktop in question and take the d-bus 
interface when started. we'd ship one probably as a kded component.

there's also XSettings which has intended to do much the same sort of thing 
but using X itself rather than d-bus. perhaps its worth looking into.

> In a perfect world, this should lead to applications knowing in each moment
> the right thing to do and that automatically adjust their behiavour,

yes, this is a driving principle behind solid, phonon, decibel, sonnet, et al

> - bool visualEffectsEnabled() const;
>
> That is "hard" by definition to be added to the interface, because there is

i think it's more than just that. i'm not sure a boolean is enough. which 
sorts of visual effects? what constitutes a visual "effect"? are we talking 
animations or shade gradients or .... are some animations ok but others 
aren't? how does one know when to do each?

> - bool shouldConserveResources() const;
>
> Similar to Solid::PowerManagement::Notifier::appShouldConserveResources().

right, we already have this in solid via HAL.

> - 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.

take a look at the KPresentationControls class, which is internally incomplete 
due to knotify needing work last i looked; but it shows an example API. note 
that this is not just about full screened things, but all sorts of things 
that shouldn't get interupted.

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

presence management; one would almost hope this to be in decibel, but i have 
no idea if it is.

> - bool connected()
>
> Are we online?

we already have that in HAL.

> 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.

right; that's just a matter of putting the code in the Right Place for each 
stack. that's the point and purpose of KNotificationRestrictions when it 
comes to screensavers, popups, etc.

> Another problematic that could show up is applications that fight to
> set/unset some parameters.

the parameters probably need to "summed" across all requests. so if app A 
turns on "don't interupt me with messages" and app B does the same, when app 
A turns it off it still is on until app B also releases. you also need to 
have some sort of check for applications going away (e.g. crashing) to avoid 
dead states.

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

it's vegan! yay! =)

> 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? ;-)

unfortunately. ;-P

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20071126/4a9f9282/attachment.sig>