Quick questions

[Havoc Pennington]

On Sat, 2005-01-15 at 12:13 +0100, Ikke wrote:
> > You don't need the .DAL. in there, because there's nothing DAL-specific
> > about this. It's just a regular interface.
> Doesn't org.freedesktop.Screensaver supply not enough information?
> HAL also uses org.freedesktop.Hal.Device (etc), which is more logic
> IMHO.

HAL is a daemon and feature separate from dbus. "DAL" is just dbus, or
maybe a convenience library that wraps well-known dbus services.

> > I'm not sure what org.freedesktop.DAL.Screensaver.Event would do.
> It'd be a signal sent out when a screensaver event happens, with one
> additional parameter, a string being ScreensaverStarted or
> ScreensaverStopped.

Signals don't have names like this though.

> 
> > You might want something like this:
> > 
> > service org.freedesktop.Screensaver
> > object /org/freedesktop/Application
> > interface org.freedesktop.Screensaver
> >   method setEnabled
> >   method getEnabled
> >   signal EnabledChanged()
> The enabled stuff should not be necessary. I was thinking of a way where
> an app could do a broadcast request like "is there any screensaver
> application running", after which all (well, normally only one, but you
> never know) will report they're active.

You don't want to stop the screensaver process in order to run a
presentation, just disable the saver. Stopping the process isn't
compatible with how xscreensaver works really. At least I don't think
so.

This kind of demonstrates a crucial point: you shouldn't bother
documenting any interface until you have at least one concrete app that
implements it. Otherwise you're just writing down speculations.

> > Or something like that. The set/get/changed thing needs standard
> > conventions which aren't documented yet. I was thinking of using the C#
> > approach (an attribute implies methods set_Enabled/get_Enabled and I
> > forget what signal)
> C# get/set methods are not implicit ;) You have to define them
> explicitly on public objects. In fact, they aren't even real objects:
> 
> private int a;
> public int A {
> 	get {
> 		return a;
> 	}
> 	set {
> 		A = value;
> 	}
> } or something alike.

My memory is that when an attribute like this is compiled to CIL,
methods get_A and set_A are generated on the bytecode level.

> > The convention that all apps implement an /org/freedesktop/Application
> > object is one that we haven't written down yet but sounds plausible to
> > me.
> That's what should become a part of DAL: when an app starts or stops,
> this should be reported on the session bus, including a definition of
> what the app *is* (an email client, a music player,...). This way
> applications that want to use other apps dont have to maintain a list
> like "XMMS is a music player, Rhythmbox too, Evolution is an email
> client,..."

D-BUS already tracks stuff starting and stopping, and when an
"org.freedesktop.TextEditor" appears you get a notification.
XMMS would own all of a unique ID like :3214, an app-specific name like
org.xmms.XMMS, and a generic name like org.freedesktop.MusicPlayer.
Other apps can communicate with it via any of those names depending on
what they are trying to do.

Please read the D-BUS source code for a while and try writing some
concrete apps on the session bus. Then you'll have a more complete
understanding of how it works.

Havoc