Re: [orca-list] Plugin system gsettings Migration

[Didier Spaier <didier slint fr>]

Howdy Chrys and All,

here is my take as a distribution and packages maintainer.

Generally speaking (beyond the plugin system) I am 100% in favor of being able
to access Orca preferences through gsettings in addition to the GUI, if done
upstream. It is up to upstream developers like Joanie and you to assess the
feasibility. Assuming that the answer will be "yes" I see several benefits to
being able to access Orca (and plugins) settings through gsettings.

1. Settings can easily be queried and done from the command line. For some users
it is easier than from  a GUI. For non-programmers end-users it is certainly
easier than to edit a JSON file. And for me too <smile>.
2. As there is a command line interface it is easily scripted.
3. For who prefers it, settings can also be accessed through dconf-editor.
4. We already use it in Slint for several settings mate and gtk related. So zero
additional work for me, only some XML schemas to add. We of course already ship
glib2 (for gsettings itself among many many other usages),
gsettings-dektops-schemas dconf-editor and GConf (it is very easy to convert
GConf keys to GSettings keys back and forth using gsettings-data-convert or
gsettings-schema-convert, associated with glib-comile-schemas).

Answer to some objections in other messages of the thread:
1. As already said, gsettings is way more regular-user friendly to use than
editing a JSON file. Maybe a flat .ini file would be even easier, lol.
2. Not well implemented by Ubuntu? I am not in concern as I don't use Ubuntu.
3. Using gsettings would not make Orca dependent of a desktop environment. In
Slint I don't ship Gnome, and gsettings is used for Mate. And also for other
stuff not tied to a specific desktop and would stay desktop agnostic.
4. To share settings between computers one would have to just query the settings
using "gsettings get" then reproduce them with "gsettings set...". You just have
to know which schemas are in concern and the associated keys.
5. Would using gsettings add to the payload of a light system. I fail to see in
what respect. It only adds one big dependency: glib2. But glib2 is already a
dependency of many software including speech-dispatcher, so even if only using
ratpoison it is certainly already there.
6. Would we loose the ability to tweak Orca settings on the fly? Quite the
contrary typing (and possibly scripting) gsettings commands.

@Chrys: Do not forget your other mission: make KDE as accessible as Mate from
logging in ;)

Le 17/12/2021 à 21:09, Linux A11y a écrit :
> Howdy List,
>
> Nope i did not give up on bring a plugin system to orca. I was very bussy the
> last couple of weeks but i need a project for christmas vocation ;).
>
> I‘m currently looking for an concept to move the  Settings storage from the JSON
> like file to gsettings. Well i never used gsettings til now. Its very laborious
> to handle. You need to create a XML scheme for each setting you have (and xml is
> IMO not very human friendly lol) but anyway. I stuck having another Problem.
>  Orca supports „per Application configuration“. So you van have a set of
> different settings per application. Seems there is no „nice“ way to handle this
> in gsettings but creating lists in lists (what would make it awful to handle in
> dconf (as well later in our new more generic preferences dialog) and
> programming, and loose many of gsettings benefits AFAIK) or copy schemes on the
> fly as new copy on filesystem (not sure if this is possible)
>
> Seems gnome-terminal had an similar issue:
> https://gitlab.gnome.org/GNOME/glib/-/issues/312
> <https://gitlab.gnome.org/GNOME/glib/-/issues/312>
> What never got really solved but worked arround by nesting lists everywhere.
>
> So before i start something stupid or ugly, maybe someone here has experience
> with that? Or maybe an good idea? What do you think?
>
> Cheers chrys