Re: [orca-list] Orca & GSettings

[trev saunders gmail com]

Hi,

> > > (microsoft), gsettings, etc.  In fact, today is the first time I ever
> > > heard of gsettings.  How easy is it to verify values in gsettings?

verify? what do you mean?

> > 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 are a screen reader for gnome, or a 
general x11 screen reader that uses at-spi, and currently happens to work best with gnome.  If we are a 
screen reader for gnome then I gues we don't have much choice.  On the other hand if we aren't a gnome 
project then I believe we can handle our settings however we want.  Although I don't actually know I imagine 
the only real reason 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?

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

 Well, personally I've gotten to the point with gnome that being a bad gnome citizen almost means your doing 
something right.  As 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 =
> >  Preferences UI.

what about people who don't want to have this stuff installed? Is there a good reason for orca to require 
this stuff?

> > * Make the saving and loading of settings much more straightforward =

what's more simple than writing a bunch of option value pairs out to a flat file?  imho sending them to a 
daemon that writes them into xml is a *lot* more complicated, and introduces dependancies we otherwise don't 
need.

> >  (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 =
> >  write them all out

whats so bad about writing a file out? that shouldn't be a terribly slow operation.  Its significantly easier 
to write the whole file than just edit the one line, and talking to a daemon could also take significant time.

> > * Solve the problem where a screwed-up user-settings.py file completely =
> >  hoses Orca

this sounds like a bug in how we read the configuration file.

> > * Fix a bunch of quirky settings bugs y'all have discovered over the =
> >  years

> > * Other stuff I'm probably not thinking of at the moment. Need more
> >  coffee....
> > 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=EDos/Junta de Andaluc=EDa making it possible.

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.  However 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 orca be a general x11 at-spi screen reader, I'd say lets keeep 
the flat file and let gnome have fun with their xml.

> Joanie, you get the point about this transition. Orca will be hardened in m=
> any ways with only putting order in its settings handling.

While I like C I have trouble getting along with python, wich of course means I don't get much of a voice 
here what I would do if we want to organize or configuration code is the following.
1. remove the gui, editing a well commented config file is just as easy and requires far less code on our 
part.
2 reorganize the configuration code so we read it in at startup and again if requested.
3 at this point we should have very little code to deal with configurations and what is left that there 
should be very few bug possible. All we would need is a loop that reads options from a file and if they are 
valid sets the relavent variable.

ok, now I'll end my bearded unix hackerish rant. :-)

Trev