Re: [orca-list] Orca and plugins

[Didier Spaier <didier slint fr>]

I wholeheartedly concur with what Colomban said.

For the blind with no technical background among Slint users, reading a JSON
file is uneasy, editing it is out of reach.

Typing a gsetting command instead is doable, and to ease that one can provide
simple instructions with examples, including for Orca settings. I am willing to
add that to the Slint HandBook.

This will well integrate in the Mate desktop for instance, as many of its
settings are already doable this way.

PS and unrelated: Colomban, congrats for Geany, it rocks and I use it all the
time! I couldn't upgrade to 1.38 yet by lack of a  C++17 compiler, but we will
do in next Slint release.

Cheers,
Didier

Le 12/01/2022 à 10:00, Colomban Wendling via orca-list a écrit :
> 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