Re: [orca-list] Orca and plugins

[Colomban Wendling <cwendling hypra fr>]

Not that I really have a strong opinion on this, but…

Le 11/01/2022 à 19:29, Илья Пащук via orca-list a écrit :
> I'm sorry, but why settings should be stored in gsettings?
>
> yes, I tried gsettings cli tool, and it is convenient.
>
> but somebody wrote that with profiles and per app settings we will need
> nested list to store the settings.

Relocatable schemas seem a better approach for both profiles and app
settings, and they are basically meant to solve this kind of problem.

> will gsettings cli tool remain so convenient in this case?

With relocatable schemas, it's just a matter of knowing the schema and
path, otherwise it's just as easy.

> and in the opposit, json parsing and writing may be done in any modern
> programming language.

Yes, but who wants to parse another app's setting file that don't even
have a documented format?  I myself have had to actually deal with
reading and (God forgives) writing Orca settings from outside Orca, and
it's not very nice nor robust.  Sure it's JSON, which is easy to read
and write in most languages, but the way things interact with one
another is not trivial, and there is zero safeguard: if you incorrectly
update the file, in the best case Orca ignores the setting, in the worse
case it crashes.

> and people wrote about other cons of gsettings before.
>
> so why don't leave json in place?

For me the very nice thing one would get for cheap is setting update
notifications.  This means that one could change an Orca setting through
GSetting, and Orca would know about it, and could react.
This is something I had to try and do to adjust some simple settings
from outside Orca, and unless I really missed something, there's not way
short of restarting Orca for it to use the new values.

Sure, Orca could monitor the JSON file and reload whenever it changes,
but it would have to be implemented and it's a bit less cheap than
letting GSetting to that for you.

> NVDA screen reader also don't uses windows registry for it's configuration.

If you really don't want the dconf registry, you can force another
GSetting backend, e.g. file.  It basically comes with all the same
features from the app point of view, and you get a simple INI-like
configuration file.  No easy gsetting CLI tool usage, but maybe you
could even point it to the right file, not sure.

Regards,
Colomban