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

[Didier Spaier <didier slint fr>]

*right, not tight, lol.

Le 11/02/2022 à 19:08, Didier Spaier via orca-list a écrit :
> Howdy Chrys;
>
> So:
>
> 1 Your proposal include completely *replacing* the current Orca Preferences GUI,
> tight?
> 1 But will users be able to use the gsettings command to do these settings (both
> exiting one and for plugins?).
>
> Do make a comparison the same settings can be done using either the gsettings
> command or the dconf-editor application. Something like that?
>
> Cheers,
> Didier
>
> Le 11/02/2022 à 18:45, chrys a écrit :
> > Howdy Didier,
> >
> > 1. No, this is not an alternative way to do the same we currently do. This is a
> > new design concept. The current approach is designed that settings almost
> > managed by orcas authority.
> > All settings here are a mixture of hardcoded or defined as static XML . As
> > plugins bring new settings with them, but the preferences window is not able to
> > show them (or only very hard), we need more flexibility here.   the new concept
> > is more generating itself as the result of all available plugins with settings
> > with some additional core settings. this will increase the flexibility and
> > reduce the maintenance by light years plus offers new possibility like a search.
> > 2. with "the settings dialog" i refer to the orca application settings or
> > preferences dialog whatever you get by pressing orca + space. maybe this is a
> > bad wording here. in Germany we say the word dialog also just referring to an
> > application window where i can enter data (and this does not only command line
> > but also for UI).
> >
> > cheers chrys
> > Am 11.02.22 um 18:17 schrieb Didier Spaier via orca-list:
> > > Hi Chrys,
> > >
> > > I am kind of lost.
> > >
> > > 1. I thought that gsettings backend would be an alternate way to do the same
> > > settings as currently using the Orca preferences GUI, which would remain as is
> > > (maybe with the addition of a "plugins" tab" allowing to list/enable/disable
> > > plugins?). is this correct? Or will you propose a completely different layout of
> > > the Orca preferences GUI?
> > > 2. I am not sure to understand what you mean mentioning "the settings dialog".
> > > Is it a dialog to set the plugins? In my understanding a dialog application is
> > > presented as a GUI or a TUI (like the ones built with ncurses). But do we need
> > > that if using gsettings which is a command line application?
> > >
> > > Cheers,
> > > Didier
> > >
> > > Le 11/02/2022 à 16:52, Linux A11y a écrit :
> > > > 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
> > > _______________________________________________
> > > 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
> >
> >
> > _______________________________________________
> > 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
> _______________________________________________
> 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