[orca-list] UI concept

[chrys <chrys linux-a11y org>]

    Howdy Joanie, Howdy List,
    just thinking about an UI concept for our new plugin driven orca.
    lets take a look at the current concept:
    
    the current design is mostly "hard coded" in an formular based
    layout with tabs and sections. very statical but functional. you can
    switch between tabs (lets name them categorys) tab til you get the
    setting you need.

• its kind of static
• no way to search for functionality or settings
• currently integrated into orcas core functionality

    I had an idea some years ago (before my ERP project interrupted my
    work) what i want to bring on the table. lets think about the
    following:
    what if, we move away from that card based layout to an list based
    layout.
    this would bring several benefits:

• we can create the UI in a generic way. as every setting could just be an entry in the list. this is very handy if we work with an plugin driven architecture.
• Plugins can add new "elements" dynamical very easy
• we could implement an search for settings and patterns
• it will provide a more unique way to configure orca. so an unique user experienc

    be concrete:
    lets think about in categories, gropus and settings. 
    we have a category i.e. general, keyboard, speech, braille, plugins
    if you open the main menu now, you get a list what looks like the
    following:
    
    general
    keyboard
    speech
    braille
    plugins

you want to change the speech rate, so you navigate with up / down arrow to speech and press return, the category opens

    enable
    voice
    rate
    pitch
    volume

you navigate with up / down arrows to rate and can increase / decrease the rate by pressing left / right, pressing return will open an input box, so you can just enter 80 for 80%.

instead of doing all above we can just start typing: "rate" or just a part of that text "ra" and you will get all results of settings what starts with ra. doesnt matter what category. the search results will be separatec by an category headline.

lets take a look at the very technical aspect:

we will be able to create the menu in an dynamic way if we know the datatype. based on an dict. the key is used for translations as well. i only show category speech here in detail. the others looking as the same.

{

    general: {...},
    keyboard: {...},
    speech: {
        enable:  {value:True, min: None, max: None, validValues: [True,
    False], widget: Gtk.switch, defaultValue: True},
        voice: {
            None: {value:'de', min: None, max: None, validValues: ['de',
    'en', 'fr', 'es'], widget: Gtk.combobox, defaultValue: 'en'},
            'gnome-terminal': {value:'de', min: None, max: None,
    validValues: ['de', 'en', 'fr', 'es'], widget: Gtk.combobox,
    defaultValue: 'en'},
            'firefox': {value:'de', min: None, max: None, validValues:
    ['de', 'en', 'fr', 'es'], widget: Gtk.combobox, defaultValue: 'en'}
        },    
        rate: {None: {value:80, min: 0, max: 100,
    validValues:[10,20,30,40,50,60,70,80,90,100], widget: Gtk.scale,
    defaultValue: 50}},
        pitch: {None: {value:50, min: 0, max: 100, validValues:None,
    widget: Gtk.scale, defaultValue: 50}},
        volume: {None: {value:80, min: 0, max: 100,
    validValues:[10,20,30,40,50,60,70,80,90,100], widget: Gtk.scale,
    defaultValue: 100}},
        },
    braille: {...},
    plugins: {...},

}

in this example for speech voice, there is an app specific value for gnome-terminal and firefox. None is the default

there is a baseline of settings, this could be extended using the plugins. the widget is set by the plugins as well. if a plugin is not loaded, a setting does not get a widget, so its not shown at all. but still stored (as you dont want to loose your settings if you reenable the plugin again. maybe we can add group elements as well to have some "submenus"

so we can easy extend, store and manage the menu. its created by its own just based on its keys. its searchable and flexible.The concept also means, there is no UI needed at all. if we dont load the UI plugin but want to controll the settings above using an dbus interface or similar we can provide an dynamic interface here as well.

its just an rough draft. What do you think?