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

[Patrick ZAJDA <patrick zajda fr>]

Hi Chrys,


I've just tested on Debian Buster.

Unfortunately, when launching Orca, it crashes with the following error:


$ orca -r
Traceback (most recent call last):
  File "/usr/local/bin/orca", line 283, in <module>
    sys.exit(main())
  File "/usr/local/bin/orca", line 253, in main
    from orca import orca
  File "/usr/local/lib/python3.7/site-packages/orca/orca.py", line 917, 
in <module>
    orcaApp = Orca()
  File "/usr/local/lib/python3.7/site-packages/orca/orca.py", line 870, 
in __init__
    self.pluginSystemManager = 
plugin_system_manager.PluginSystemManager(self)
  File 
"/usr/local/lib/python3.7/site-packages/orca/plugin_system_manager.py", 
line 65, in __init__
    self._setup_extension_set()
  File 
"/usr/local/lib/python3.7/site-packages/orca/plugin_system_manager.py", 
line 149, in _setup_extension_set
    [plugin_iface])
TypeError: Peas.ExtensionSet.new() takes exactly 3 arguments (4 given)


Do you have an idea  about this?


Thanks and best regards.


Le 04/06/2021 à 23:41, chrys a écrit :
> Hello Joanie, Hello list,
>
> i know there are plans to create a plugin system for orca. i created 
> SOPS to work around a bit but it does not replace something "real".
> Joanie suggested libpeas. I just got some spare time to dive into 
> this. I read some documentation about libpeas and it sounds very 
> reasonable to me. it provides all the stuff what a plugin system need 
> already.
> libpeas plugin engine has the ability to load plugins wirtten python 
> 2, python 3, C, and Lua. what sounds very impressive. special C looks 
> like an benefit if we need to squeeze out every bit of performance.
> So i checked out how libpeas is working and started with an basic 
> plugin system for orca what i just want to introduce here.
>
> # Why i did this:
> - Orcas code needs IMO to be be cleaned. its a mixture of Object 
> Orientation and Procedual programming. Migrating things step by step 
> over to an plugin driven architecture would allow us to clean up thins 
> step by step and modernize it to an bright future :).
> - Users can easy share addons and additional functionality, well thats 
> the point of an plugin system :).
> - Users can overload orcas "core" plugins if different behave is 
> prefered or requred.
> - coding is fun
>
> # What i did:
> - I create a new Class PluginSystemManager what does all the plugin 
> handling and loading / unloading stuff
> - there are currently 3 types of plugins handled:
>     1. Core: the idea is to port in midterm orcas core functionality 
> to this plugin layer. it will provide the basic functionality what is 
> not allowed to be unloaded. its living in orcas install path
>     2. System: here we can deploy system wide plugins. those can be 
> activated and deactivated. its living in orcas install path
>     3. User: can be installed per user to be able to customize orca 
> individual or without root access. is living in the orca settings of 
> the user
> - an API class to share orcas API with the plugins. it contains the 
> API to fire signals and the signals itself. There are currently just 2 
> signals:
>     1. start-orca: is fired after orca is completly initialized
>     2. stop-orca: is fired while stopping orca
> - an APIHelper class with some common stuff needed by the plugins more 
> often. Lets say a collection of useful functions.
> - integrate into build system
> - create 2 core plugins  and 3 system plugins just for prototyping and 
> try out different things. i reused some code from SOPS. The idea is to 
> load all needed plugins on startup. the plugins can register keyboard 
> shortcuts or connect to signals while an do_activate and remove them 
> while do_deactivate.
>     - The core Plugins:
>         1. HelloOrca: startup notification of orca, consuming the 
> "start-orca" signal (so you will hear "screenreader on" now twice, 
> once still hard coded, once by the plugin
>         2. ByeOrca: stop notification of orca, consuming the 
> "stop-orca" signal (so you will hear "screenreader off" now twice, 
> once still hard coded, once by the plugin
>     - The system Plugins
>         1. helloworld: just prints some debug output and says hello on 
> startup
>         2. SelfVoice: starts / stops an listening thread when plugin 
> is enabled. it waits for incoming text using unix sockets. the text is 
> just spoken.
>         3. Clipboard: registers an keyboard shortcut Orca + w. it 
> announces the content of the current clipboard
>
> # what is currently missing:
> - A GUI for Plugin management - a plugin manager (Enable Disable 
> Configure). Currently just all available plugins are loaded. i 
> currently work on this.
> - The setting management is not done yet. (not important as there is 
> no plugin  manager to change the settings currently lol)
> - integrate more events (this could happen by migrate the current 
> functionality step by step)
>
> what do you guys think?
> @Joanie, what do you think?
> is this worth to be continued?
>
> you can find my work currently on github:
> https://github.com/chrys87/orca-plugin
>
> sorry that i just started without ask or something. I don't want to 
> make anybody angry. i just tried and played a little. it was something 
> like an "selfrunner" + it was really fun to me to do so.
> IMO its an chance to modernize the codebase step by step.
>
> 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
--
Patrick ZAJDA