Considering ConsoleKit and GSettings/DConf

[Hynek Hanke]

On 11.8.2010 18:11, Trevor Saunders wrote:
> personally I don't care about session integration, but if you want to add 
> support for it that's fine.
>    

Well, I think it's crucial for us to care about session integration as
this is where the rest of the desktop is going. It's based on technically
valid concerns. If free accessibility technologies are to keep working
and stay usable, we must care. We do not live in a separate world
of our own.

I have been talking about this with Luke Yelavich in Prague.
As an Ubuntu maintainer, he has a pretty good picture of where
things are going. Me and some other developers from Brailcom
have also seen and discussed that on Guadec, early this month.

>> Speech Dispatcher is currently not sticking to these rules.
>> With Pulse Audio, detaching when in inactive session is not
>> so important, but with ALSA and other audio output methods,
>> it's crucial since we block everyone else.
>>      
> This shouldn't be a problem we shouldn't be taking exclusive locks on any of 
> the
> alsa files so others should still be able to use them.
>    

I don't know what you mean exactly, but once we are sending sound
to a one channel soundcard, noone else can access it. So we must
prevent this in inactive sessions. There might be other ways to
achieve that. Please write more, if you have an idea.

> another issue we'd have to deal with is since sd is network transparent what
> exactly the importance of the session on the local machine is.

ConsoleKit has a notion of remote sessions. What you speak about
however, I think, is a remote Speech Dispatcher server, which is
not integrated in a session, but running in a kind of system mode,
so this talk about ConsoleKit is not relevant to it.

Another thing is remote SSH logins, when screen reader is
part of your session on the remote machine. Like you use any
computer with speakers to connect to your home computer.
You are expecting to get audio to your local machine you are
sitting at, not play on the remote machine. I think we do not need
to do anything special as Pulse Audio already tries to do that (don't
know how well it works) and it uses exactly ConsoleKit for that
purpose.

> there is a perfectly good way to deal with this, report the error and use the
> default, then the user can fix it.
>    

This is waste of time and difficult for the users. I'd prefer a way
where such kind of errors cannot even be generated.

>> 2) It is difficult to maintain an up-to-date configuration file
>> on target users computers across different releases of
>>      
> yes, and that is there fault, and they will realize the problem and fix it.
>
>    

This is our point of view as developers. The point of view of users
is simpler: I did an update which should make it better and instead,
it stopped working.

>> 3) Commentaries in text based config files are in English
>> and not possible to localize.
>>      
> No, I can't see a reason that they can't be localized.
>    

Can you please propose a good way to do it?

>> 5) It is not possible in text based configuration to get
>> notification on configuration changes.
>>      
> no, it is possible, see ssh / openttsd / other daemon, sending them SIGHUP 
> will
> cause them to re read the config file.
>    

Speech Dispatcher implements SIGHUP from long time ago for
this purpose. This is however not triggered automatically, the user
must find his way to send the signal. And AFAIK, the only feasible
way to do so is via starting a terminal and executing an killall
command with a specific argument. This is overcomplicated.

I'm not saying your point of views are not valid for certain
types of users, but we shall aim for reasonable ease of use
by any reasonably skilled users.

Best regards,
Hynek Hanke