Considering ConsoleKit and GSettings/DConf

[Trevor Saunders]

Hi,

On Thu, Aug 12, 2010 at 11:08:13AM +0200, Hynek Hanke wrote:
> 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 haven't looked much for the 'technical concerns" behind session stuff, however
I'm sceptical that there either is much of one, or that the current solution is
what is needed.  In any case, I never said I personally cared about the
"desktop' any way, a light weight wm is much more what I want personally.  if
what you mean by the desktop is gnome / kde then sure, but they aren't the
world, just a big section of it, that from here looks like it could use some
redesign :-)  however if you want to support session integration, in a clean 
way that's
great.

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

Yes, I've talked with Luke about it a little too, but remember this is *ubuntu*
and *Gnome* not the hole world.  If they want to support this in a clean way
that's fine, I'm just not interested.  The problem here is that gnome and ubuntu
sometimes Force a configuration on users, and make it hard for them to change
this, which to me is troubling.

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

true, we probably shouldn't actually send sound to the sound card anyway in this
case.  what I was refering to more is the issue I mentioned in the other thread
that pulse should fall back to using dmix if it can't get an exclusive lock on
the sound card.

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

Ok, it wasn't clear from what you said if speech dispatcher would have a
non-consolekit mode like this.  Yes, I would see this as pretty much a system
service mode, although it might run as a normal user instead of a system one.

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

I've never looked at this either.

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

there is *always* a posibility for such an error, its just that with dconf its
caused by a binary file getting broken in some strange way wich will be very
hard for anyone to fix.  On the other hand with a text file I find it hard to
believe that anyone would actually be stupid enough to use the wrong type, and
if they somehow manage to it will be pretty clear what they got wrong.  It may
be difficult for a user the first couple times they ever encounter the idea of
figuring out what when wrong from logs, but after that its a lot easier than
trying to get a gui to tell you what went wrong.

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

As a user my point of view is that I updated, and the update included new config
files, I have to reconsile the differences.  Any decent package management
software makes the user aware of this, both portage in gentoo and apt in debian
etc do.

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

I'd need to look into how gettext etc works, I've never needed to deal with it,
but I note that 1 and plenty of applications mange to do this, and 2 its just
not that complicated we chose which string we insert based on what language we
want.  My first rough idea would use autogeneration of the config files,
basically we'd have a tag for each comment for each option like
option-name-config-desc, and we'd look up what that tag mapped to in the current
language when we generate the config file.

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

Clearly its fine for plenty of other servers, but any way.  Any configuration
interface, can automatically do this.  Also people will probably have terminals
open already, they're just too useful.   The most important reason I don't think
this is a big deal is that I don't believe anyone actually bothers to change
speech dispatcher settings anyway, and the few who do will be sys admin types
who can run kill, or use an init script.  If you really wanted to, you could
poll the update times on the file to see if its been updated, but I don't think
this makes sense.

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

Personally I believe that "reasonably skilled users" can use a terminal and
know sending sighup is a reasonable way to get config files reread, and I think 
that
if they don't, teaching them is a good thing.  However I think we're worriing 
far
to much about user friendliness in something users will never think to go near
anyway.

Trev

> 
> Best regards,
> Hynek Hanke
> 
> 
> _______________________________________________
> Speechd mailing list
> Speechd at lists.freebsoft.org
> http://lists.freebsoft.org/mailman/listinfo/speechd