Re: [orca-list] Orca & GSettings

[trev saunders gmail com]

Hi Juange,

> > > > > (microsoft), gsettings, etc. =A0In fact, today is the first time I ev=
> er
> > > > > heard of gsettings. =A0How easy is it to verify values in gsettings?
> >
> > verify? what do you mean?
>
> I guess he means to get the value for a specific key setting and maybe
> verify if there is a valid value, or if it's empty or the list of
> posible values...
> If the question was something like that the awnser is the it will be very e=
> asy:
> http://library.gnome.org/devel/gio/unstable/GSettings.html

ok, but thats a silly question if you can't that from any configuration system its horibly broken.

> > > > I'll leave this question to the more knowledgeable folks (i.e. the guys
> > > > from Emergya).
> > >
> > > > > But if that is the direction to go, I guess we haven't
> > > > > much choice, do we.
> >
> > well, I think this depends on the question I asked earlier about if we ar=
> e a screen reader for gnome, or a general x11 screen reader that uses at-sp=
> i, and currently happens to work best with gnome. =A0If we are a screen rea=
> der for gnome then I gues we don't have much choice. =A0On the other hand i=
> f we aren't a gnome project then I believe we can handle our settings howev=
> er we want. =A0Although I don't actually know I imagine the only real reaso=
> n we re so relted to gnomewas Sun, so after Sun I wonder if there is stil a=
>  reason to be so relate to gnome? What do poeple think?
>
> I guess we could ask us this question but right now (AFAIK) Orca is a
> GNOME project. In fact, Orca uses the GNOME stack and is part of the
> GNOME core.
> This doesn't mean Orca shouldn't be nice with others desktops, but
> IMHO Orca should be nicer and better integrated with GNOME.

I don't see how integrating it with any desktop helps anyone.  If some desktop provides a package that 
provides us with very useful functionality then I'm fine with using it, but if it doesn't I don't think we 
should require it just for the fun of it.

> > > > Well, we (Orca team) have caught flack over the years for not being a
> > > > "good GNOME citizen." Good GNOME citizens don't roll their own setting=
> s.
> > > > Good GNOME citizens are also no longer using gconf but are migrating to
> > > > gsettings as part of GNOME 3.0. So ultimately that's where things are
> > > > going. And ultimately, I'm not convinced we do have that much of a
> > > > choice.
> >
> > =A0Well, personally I've gotten to the point with gnome that being a bad =
> gnome citizen almost means your doing something right. =A0As to what choice=
>  we have I believe it depends on the question I raised above.
> > > > Having said that, I think that this conversion is going to prove to be
> > > > valuable to us in ways far beyond earning the respect of our fellow
> > > > modules. In particular:
> > > > * Make it possible for us to work better with the new Universal =3D
> > > > =A0Preferences UI.
> >
> > what about people who don't want to have this stuff installed? Is there a=
>  good reason for orca to require this stuff?
>
> My guess is that the good reason is to be well integrated with the
> rest of the desktop and to bring to the user a easier and better way
> to configure their configs.

how can / is it better or easier than opening your favorite editor and changing the values you want?  Other 
than the fact that creating a UI means you get to spend time writing it, and then next year when gnome 
decieds to change again, without a implementeted replacement before they deprocate it of course getting to 
rewrite it yet again.

> I know that not all the users need/want GUIs and so, but we must think
> about the users that need that. The powerusers will be able to
> disable/avoid/hack/whatever the GUI or the global preferences or
> whatever thing could annoy them, but the others users don't...

Not to be elitist, but if a user can't follow directions to open a text file find the setting that says 
"key_echo yes" and change it to "key_echo no" for example, I don't think we know how to help them since that 
is about the simplist way to configure something I know of.  THe only help I can provide at that point is to 
go buy a mac or a windows install cd, but that won't really help because any configuration there will be just 
as hard, and probably hidden in some really obscure place instead of ~/.appname.  As another note on this 
part, The standard unix philosophy that your only a noob once applies here, since this is simple to learn, 
and will make your life much easier for a long time it is well worth learning what little you have to 
configure programs through text files.
Second, yes people like to claim you can edit things without the UI, but my experience is that it tends to be 
*very* hard.  You don't know how to do it, and we don't even yet have a python api to this 5 months before it 
is supposed to be in production!  What here doesn't scream danger?

> But there are more reasons, like be able for another apps to know this
> options and doing anything they need about. Maybe gnome-mag or another
> app could ask to GSettings the values of a configs you already have
> been selected on Orca so they don't have to duplicate configs (which
> could be inconsistent). And viceversa.

What if the user wants the settings to be different?  In any case I don't see this actually happening.  I 
just don't see much overlap between the options for what to speak / braille for a screen reader and what to 
magnify for a magnifier etc.

> > > > * Make the saving and loading of settings much more straightforward =
> =3D
> > what's more simple than writing a bunch of option value pairs out to a fl=
> at file? =A0imho sending them to a daemon that writes them into xml is a *l=
> ot* more complicated, and introduces dependancies we otherwise don't need.
>
> Sure that plain files are much easier than xml ones or a daemon
> running, but it is just not scalable enough.

no, First there are far more complicated daemons and services that use text files.  Second lets do so rough 
numbers.  Currently wc reports my user-settings.py has about 170 lines, alot of which are comments.  It 
shouldn't be a python file in my view, but that's a different issue.  So lets say we had 300 configuration 
options I believe this is far more than we'll ever have but anyway lets assume each line is 50 characters 
that should be plenty for a  "setting value" that gets us roughly a 15 kb text file, not that I care about hd 
space that is perfectly acceptable I read much larger files into vim all the time absolutely fast enough.  As 
for code lets assume it takes a 10 line function to deal with each setting, this seems high to me but lets go 
on that means a total of 3000 lines of code wich is a fare chunk, but remember that once written we won't 
have to touch most of it ever again because its so trivially correct if value is valid var = value.  So we 
have 3 k lines of code
  we will only touch to change options which will be easy either add a function or change one.  TO me this is 
very managable, flexiable and is a worst case projection.

> We have a lot of keys and values in Orca it is a huge amunt of pairs
> to mantain and to check.

what do you mean check?  we won't need to do much maintainance since it is clearly correct.  What will take a 
lot of maintainance is interacting with a nother program through a library that will change once, and will 
will probably change again in a few years, and again who nows how long we'll have to change over.  See how 
currently there is no way to talk to gsettings in python and all the gnome python apps are supposed to be 
doing this production stable in 5 months.  As I asked before how is this a good idea?  How does it not scream 
danger?

>  And if you have all the config you need on a
> file, you'll need duplicate configs you're sharing with other apps and
> the desktop itself.

you said this before I believe.  I would argue that if we and the desktop have a option for the same thing 
something is wrong.  Orca is a screen reader, therefore its options should be about and only about how it 
produces speech, braille, what to read and what keys it acts on, and anything else screen reader specific we 
come up with.  Non of which is something anybody else needs to deal with.

> But also it's not enough to big deployments like schools and so where
> you could need profiles, or global changes and so on.

I don't see how who deploys software is relavent, its up to the sys admin to configure things, but presumable 
the sys admin would configure things system wide on a master node and pushthe  changes with an update to all 
the slave machines.  What do you mean by a profile here?  Should system wide updates need to be made I can 
think of several standard tools that can act on text files, rsync and scp, come to mind.  This could also be 
done with local package repositories wich many such institutions would have anyway or clonzilla would work, 
but is overkill.  Who knows gsettings may provide some thing, but its easier to just run a shell script to 
rsync to all the machines than to find out how to do it with gsettings.  Anyway this is a problem best 
handled by a sys admin who knows his own requirements.

> Anyway, GSettings is not based on xml files. GConf is, but that's one
> reason we move to DConf/GSettings, because to maintain, read and write
> all those GConf xml files is a mess and very bad for the perfomance.
> But this is just a temporary step in the meantime.
> When GSettings be ready, we'll migrate to it. And this migration
> shouldn't be traumatic.

so what is gsettins then? It uses schemas right? I hope somebody has atleast implemented that part, but I 
wouldn't be suprised if not.  Why not wait on this til gsettings is ready then? and work on actually useful 
problems in the mean time.  I know Mike G knows of some intermittant bugs in at-spi2, that stands a resonable 
chance of being ready, can activily increase access, and helps more people?  There are plenty of actual bugs 
related to access, what is the hurry to perfect the UI?  We already have more work than hours to do it, so 
why not let a sub optimal UI be and attack real problems?

> > > > =A0(which in turn will give us things like fast language switching)
> >
> > maybe I don't understand, but how are these at all related?
> >
> > > > * Make it possible to change settings on the fly without having to =3D
> > > > =A0write them all out
> >
> > whats so bad about writing a file out? that shouldn't be a terribly slow =
> operation. =A0Its significantly easier to write the whole file than just ed=
> it the one line, and talking to a daemon could also take significant time.
>
> Actually it is less efficient (in terms of perfomance) makes writes
> and reads to the disk that querys to the daemon which is already
> loaded on memory.

I wasn't thinking about time, I was thinking about code complexity.  However, I believe you are incorrect 
about time.  Yes, the daemon is loaded, but we still have to do ipc, and go to basicaly the same places in 
the kernel either network or file system to talk to the daemon as to read / write the file.  The file as I 
estimated above will be relatively tiny, so it almost certainly won't be fragmented, and we can read it in 
one shot, which will be reasonably fast.  Even if reading the configuration file takes .2 seconds it 
shouldn't really matter, we won't do it very often.

> And the config system can deal with different apps asking or setting a
> key concurrently, a plain file doesn't.

While we could implement locks we don't have to because as I said above there is no reason to share 
configuration files.

> > > > * Solve the problem where a screwed-up user-settings.py file completel=
> y =3D
> > > > =A0hoses Orca
> >
> > this sounds like a bug in how we read the configuration file.
>
> It sound to me that currently you can mess to much with the
> user-settings, overwriting to much freely.

This is where my issue with it being a python file comes in.  We shouldn't be importing the settings file as 
a piece of python, I gues this works, but it has the weakness mentioned above that we can hose orca.  If we 
had a way to source the file that didn't do this that would be fine basically the same as bash you can source 
a file but bad syntax won't kill the shell.  IF we can't then it should be a config file and we read it.
So you'd like to remove control from the user, and make them take whatever the developer decides is correct? 
imho more configuration options that aren't reduntant never hurt, and removing choice is *not* ok.

>  I think that to have a
> structured and well definide set of keys and values will help a lot.
> Obviously this can be done with GConf/GSettings but also with a well
> defined plain file.
>
> > > > * Fix a bunch of quirky settings bugs y'all have discovered over the =
> =3D
> > > > =A0years
> >
> > > > * Other stuff I'm probably not thinking of at the moment. Need more
> > > > =A0coffee....
> > > > So I for one welcome our new gsettings overlords. And I'm extremely
> > > > grateful to have Emergya doing this work, and the support of the
> > > > Consorcio Fernando de los R=3DEDos/Junta de Andaluc=3DEDa making it po=
> ssible.
> > well, if what people want is a screen reader for gnome, this is fine with=
>  me since for whatever reason gnome has decided to go this way, we might as=
>  well go along. =A0However personally as someone who isn't a big gnome fan =
> (my ideal "desktop" is a bunch of shells and a firefox window) If it weren'=
> t for orca I probably never would have used gnome I'd really rather see orc=
> a be a general x11 at-spi screen reader, I'd say lets keeep the flat file a=
> nd let gnome have fun with their xml.
> > > Joanie, you get the point about this transition. Orca will be hardened i=
> n m=3D
> > > any ways with only putting order in its settings handling.
> >
> > While I like C I have trouble getting along with python, wich of course m=
> eans I don't get much of a voice here what I would do if we want to organiz=
> e or configuration code is the following.
> > 1. remove the gui, editing a well commented config file is just as easy a=
> nd requires far less code on our part.
>
> Agree, but the part of the GUI which for me is a must.

why do people have it in there head that it is so much easier?  Even if the text file is harder, I'd agree 
it's different from windows / mac, but different and harder are not the same, The comment about learning 
being worth while applies, so there really is no point to the gui.  If gnome wanted to implement something 
for orca that was an optional added gui configuration tool that work with what I'm proposing  I would be fine 
with that.  I don't think this would be very hard to do.  I'm not sure how well that could work with 
gsettings, but whatever.  imho the correct way to do gsettings would be to do a gui with a plugin to 
configure each app, that way we don't have this dependancy issue, but gnome can still integrate things.  This 
would even allow gnome to integrate in configuration of installed kde apps.

> > 2 reorganize the configuration code so we read it in at startup and again=
>  if requested.
>
> Agree.
>
> > 3 at this point we should have very little code to deal with configuratio=
> ns and what is left that there should be very few bug possible. All we woul=
> d need is a loop that reads options from a file and if they are valid sets =
> the relavent variable.
>
> That's right for a simple and small app or tool, but I think is not
> good enough for a complex piece of software like Orca is.

Well, it's good enough for apache and any number of other far more complicated pieces of software.  
Personally, I think the whole gsettings thing is way over engineered solution looking for a problem.  As 
above, unless you have a really good reason its not good enough I say take the unix answer of the simplest 
solution that does the job, and to date while some redesign may be in order I think your trying to solve a 
small problem with a huge hammer.

 And it will
> be leave Orca isolated from the rest of the desktop, which I know is
> your desire, but lots of users need the oposite...

I simply can't see how it helps them in any meaningful way accept perhaps that they never learn a more 
effecient way to configure things.

> Of course, it is just my opinion.
 
ok, well I really hope orca stays, and tries to become more desktop independent.  I'm not sure what I'll do 
in the future, I'm not thrilled about the idea of forking orca for my own use, or writing a screen reader to 
talk to at-spi, but at the same time I don't like what I have to deal with using gnome.

Sorry about ending on this tone, but I'm tired :(

Trev