Re: [orca-list] Pluginsystem for Orca using libpeas



Something similar to NVDA's addon layout would be nice. Basically, the NVDA addon consumes an API that NVDA 
exposes. Aside from that, we have to setup a specific addon structure. Otherwise, everything works.


-----Original Message-----
From: orca-list <orca-list-bounces gnome org> On Behalf Of chrys
Sent: Saturday, June 5, 2021 7:44 AM
To: orca-list gnome org
Subject: Re: [orca-list] Pluginsystem for Orca using libpeas

Howdy Kyle,

Quick question: how will application scripts be handled if the plugin 
modular design is in the codebase?

in short term maybe this would not change at all. I would concentrate iron out the plugin system and add the 
missing pieces.
Mid to long term, well, the scripts are basically imitating some "plugin" behave. So i would say we can move 
them to the plugin "system" 
plugins. we can activate and deactivate them on the fly automatically while we detect a other script is 
needed. like lets say we switch from GTK to an QT app. We can unload the GTK "back-end" plugin and load the 
QT "back-end" plugin. from there orca gets its events from the QT  plugin.
Will scripts now just be core or system plugins? 
there can be a base "backend" plugin in core, what all system back-end plugins can consume and have as 
dependency. in fact libpeas already can define dependencies for plugins. So System:QT and  System:GTK can 
consume some basic functionality what Core:"Base Backend" provides. ( similar to the default script we 
currently have). but this is very detailed and i didn't thought about all the details yet ;).
Will the user be able to override a script if they know how and want 
to do it?

well, overloading plugins would be cool. and very doable. i would say yea, that should be the way :). fenrir 
does the same for custom commands and drivers.

the separation between core and system was just an idea from mine and might not be nailed for now. we can 
change this if it leads to confusion. if a plugin is loadable or not is just configurable in the *.plugin 
definition file

cheers chrys

Am 05.06.21 um 01:18 schrieb Kyle via orca-list:
Quick question: how will application scripts be handled if the plugin 
modular design is in the codebase? Will scripts now just be core or 
system plugins? Will the user be able to override a script if they 
know how and want to do it?


In any case, this concept really does look good. I would certainly 
like to test newer versions that incorporate the new code, although 
because the changes are so major, I will probably switch back to 
releases when I need to work, as breakage during major code 
refactoring are pretty much unavoidable. Thanks very much for the 
work. I look forward to running some tests.

~Kyle

_______________________________________________
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



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