Re: [orca-list] Settings concept for plugin based orca

[Devin Prater <r d t prater gmail com>]

This would be really nice. We could even make a CLI method to reset settings and such. Do all desktops honor GSettings though?

Devin Prater

r d t prater gmail com

On Fri, Feb 11, 2022 at 9:53 AM Linux A11y <chrys linux-a11y org> wrote:

Howdy List,

I thought about how to implement the gsetting backend and the preferences dialog.

The basic concept looks like the following:
1. the plugins bring its own settings. Orca as application does not know what settings a plugin will need. Otherwise we have to implement any plugin setting into the current preferences dialog. This is not what a plugin architecture is. This makes the current preferences dialog obsolete. Its too static and hard to extend in a useful way.
2. the new preferences dialog is isolated by the orca process. This is possible because gsettings support signals when settings got changed. In that way we can run the configuration dialog also when orca is not running at all or have alternative implementations like QT for KDE based desktops later. Orca itself, is just an background service then.
3. of course i will still make the settings dialog available as plugin at runtime. The possibility of running the dialog without orca running, doesn’t mean we won’t integrate it.
4. the preferences dialog becomes generic. It will be a list or better tree like structure.
5. the dialog should figure the datatype of an plugin by its own and add checkboxes, slider and menu buttons by its own to build up the UI. This will reduce the maintenance the plugin settings.
6. for more complex Menus like: shortcuts, string substitution, formatation details, speech (hierarchy of buttons TTS->language->voice->accents) and others, the generic handling could be overwritten with custom widgets
7. we can implement a search for settings in a list.
8. the most upper structure is the plugin name, in deeper levels you find its settings
Example:
Level 1: Orca (main application)
Level 2: profiles
Level 2: active profile
Level 1:speech
Level 2: enabled
Level 2: tts
Level 2: voice
Level 2: speed
Level 1: mouse review
Level 2: enabled
Level 2: read only text
Level 1: Braille 
Level 2: enabled
Level 2: braille table
Level 1: date
Level 2: shortcuts
Level 2: format

Well i think you get the idea.

9. the settings dialog should have a export / import for a an application specific setting a single profile or all profiles
10. the settings dialog should have the possibility to change between profiles, add and remove them.
11. the settings dialog should have the possibility to change between application specific settings, add and remove them.
A profile contains a set of getneral and application specific settings
12. orca will provide the unified gsettings API but the plugin are responsible to handle them.
13. gsettings provide events when settings got changed. So orca can react even if the preferences dialog is separated to the orca process.
14. the settings Dialog should manage the plugins (enable, disable, install, remove them)

What do you think? Ideas? Feedback? Questions?

Cheers chrys



_______________________________________________
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