Re: [orca-list] Orca and plugins



Hi Voldymyr,

Nothing prevents to use gsettings in KDE, provided that the needed software are
installed. We are speaking about Orca settings, not KDE settings.

So, nothing would block to usage Orca in the context of KDE.

Cheers,
Didier

Le 12/01/2022 à 12:39, Volodymyr Dorozhinsky via orca-list a écrit :
Hi,


how about Orca and KDE? Are gsettings supported there? If not then do we realy
wont to block Orca support by KDE by introducing such a Gnome-like DEs limitation?



Best regards

Volodymyr


On 1/12/2022 10:39 AM, Didier Spaier via orca-list wrote:
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
_______________________________________________
orca-list mailing list
orca-list gnome org
https://mail.gnome.org/mailman/listinfo/orca-list
Orca wiki: https://wiki.gnome.org/Projects/Orca
Orca documentation: https://help.gnome.org/users/orca/stable/
GNOME Universal Access guide:
https://help.gnome.org/users/gnome-help/stable/a11y.html



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]