Re: [orca-list] Orca & GSettings

[Juanje Ojeda <jojeda emergya es>]

Hi Trev,

2010/6/5  <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 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 easy:
http://library.gnome.org/devel/gio/unstable/GSettings.html

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

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.

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

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

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.

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

Sure that plain files are much easier than xml ones or a daemon
running, but it is just not scalable enough.
We have a lot of keys and values in Orca it is a huge amunt of pairs
to mantain and to check. 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.
But also it's not enough to big deployments like schools and so where
you could need profiles, or global changes and so on.

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.

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

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.
And the config system can deal with different apps asking or setting a
key concurrently, a plain file doesn't.

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

It sound to me that currently you can mess to much with the
user-settings, overwriting to much freely. 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 =
> > >  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.

Agree, but the part of the GUI which for me is a must.

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

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. 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...
Of course, it is just my opinion.

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

Well, here is were I end my focused on the very end users gnomerish rant ;-)

Greetings :-)

-- 
Juanje