Considering ConsoleKit and GSettings/DConf

[Halim Sahin]

Hello,
On Mi, Aug 11, 2010 at 05:14:00 +0200, Hynek Hanke wrote:
> * Why do we need ConsoleKit
> 
> Speech Dispatcher needs to obey the rules for nice
> behavior of user session daemons. Most important:
> 
>      1) Free resources when session is not active

If this happens, will speechd only suspend or exit completely.
If it only suspend, this will end in wasting resources for handling
several speech-dispatcher instances running at the same time.
This wouldn't increase performance on netbooks etc.

>      2) Do not consume CPU when session is not active

See 1.

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

Yes this is correct because the _mainstream_ soundserver uses the
hardware directly and doesn't communicate over alsa's dmix
infrastructure.
If someone would add this options to the distros main soundconfiguraton,
this wouldn't be a problem.
Tested here.
On my machine pulseaudio runs in gnome, where speechd uses libao over
it's alsa output.
I use pulse for  all kind of playback and voip under gnome.
It doesn't make any difference here if it uses dmix or not.


> Consider the current audio fallback mechanism ,,pulse, alsa''.
> If for any reason (e.g. because early in the bootup process)
> this mechanism starts Dispatcher with ALSA, this breaks
> Pulse Audio output for any user on the system unless they kill
> that Speech Dispatcher. This is completely unnecessary.

Well, pulseaudio neededs to be extended that it checks if the default
hw0,0 could be opened.
If not, it should fallback to dmix.
This would avoid all changes in all a11y related apps.

> (Audio fallback needed to be disabled for 0.7.1 as this is
> a real problem with BrlTTY.)

Yes it's a problem for other screenreaders as well.

> We also consume CPU unnecessarily. Speech Dispatcher will
> synthesize any incoming text regardless of whether the
> current session is active or not. That synthesis produces sound
> which will never be heard.

Wouldn't be a problem see my previous comments.

> This is all also important for running Speech Dispatcher
> in the ``idle session'', as we discussed before, to enable
> reading startup messages, login etc.

> Using ConsoleKit, Speech Dispatcher will always know,
> whether it operates in a session which is currently active.
> When the session is inactive, it will detach from resources
> (such as blocking audio) and will not waste CPU time
> for speech synthesis.

BTW.: have you even tried to use pavucontrol in gnome when speechd uses
pulseaudio?
If not please do.

> * Why do we need DConf/GSettings
> 
> 1) While text based configuration has its advantages for
> advanced users, it is a problem for less experienced users.

Yes.


> It is very easy to make errors in syntax or in the content
> of the settings themselves (like there is no way to enforce
> enumeration values etc.).

Let's see:
Q: Which settings does the enduser frequently change?
A: addmodule directives

All other settings like speechsysnthesis params etc should be set by the
used screenreader.
Other advanced stuff will not be touched by any enduser.

> It is difficult to maintain an up-to-date configuration file
> on target users computers across different releases of
> Speech Dispatcher. Removal of old config file and installation
> of a new one is not trivial if settings should be maintained
> and typically must be done by the user by hand. If users do not
> update their config file when asked to, this often leads to
> problems.

Ok, this is the fact of broken speech-dispatcher release in popular
distros.
Remember the pulseaudio problems!

> 3) Commentaries in text based config files are in English
> and not possible to localize.

If we avoid the manual module handling and try to ship working packages
with mainstream distros, this would not be a problem.

> 4) Current DotConf settings implementation in Speech Dispatcher
> needs a lot of code, even though we simplified it by using
> macros which generate the code.

hmm, It works :-).

> 5) It is not possible in text based configuration to get
> notification on configuration changes.

Well restarting the server wouldn't be a dificult task in my opinion.
Why not provide an easy shell skript for reloading the config by sending
a signal to speechd?

> 6) As Tomas pointed out, a more dynamic configuration
> mechanism will allow us to do very interesting things,
> like settings profiles, which can become a major improvement
> and simplification in the whole AT chain.

I am not sure.
Can you provide an useful usecase where a user needs this in real world?
speechd supports several messagepriorities, which were implemented as
great usefull thing.
Who uses it?

> Whether DConf is the right way to address these issues
> and whether it is acceptable for platforms other
> than Gnome must however be investigated.

There are afaik only graphical editors available for it.
So a console user can't make changes to speechd when he didn't
install a graphical environment?

> Best regards,
 
Thx for your response!
Regards
Halim

> 
> 
> _______________________________________________
> Speechd mailing list
> Speechd at lists.freebsoft.org
> http://lists.freebsoft.org/mailman/listinfo/speechd

-- 
Halim Sahin
E-Mail:                         
halim.sahin (at) t-online.de