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

From: Linux A11y <chrys linux-a11y org>
To: Andy Borka <sonfire11 gmail com>
Cc: orca-list gnome org
Subject: Re: [orca-list] Pluginsystem for Orca using libpeas
Date: Sat, 5 Jun 2021 21:49:35 +0200

Hi Andi,

You develper toolkit looks very cool :).

I did a quick look and found a little typo in

https://github.com/ajborka/nvda_developer_toolkit/blob/master/addon/globalPlugins/developerToolkit/shared.py

message = „Copy faildd.“

should be

message = „Copy failed.“

What does not lower your work!

Very good idea to have something like that :).

Cheers chrys

Am 05.06.2021 um 16:06 schrieb Andy Borka via orca-list <orca-list gnome org>:

I like this idea. If anyone needs help, let me know. You can find some of my python work for NVDA at www.github.com/ajborka/nvda_developer_toolkit.
Let me know if it is worth having me help out.

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

Two words: Woo hoo!

Yes, I think this is worth continuing and I'm super happy you've found time for this! Totally agree also that Orca's code needs a major refactor (several actually). There's just not enough time in the day.

I'm not sure what all falls under the heading of "Core". Could you list some more examples?

Would system also include speech, braille, maybe flat review, mouse review, etc.?

And I assume that as part of this work we can slowly but surely move keybindings and settings management to these plugins rather than have Orca itself manage them centrally. Is that your understanding as well?
If so, maybe we can *finally* move things over to gsettings as part of this work.

A couple of hopefully easy to port things would be Orca's day-time commands, and the notifications list. I need to totally rewrite Orca's flat review find support. But once I get that working, hopefully it should also be easy to port.

Lastly, for the GUI, we'll obviously need to add GUI in Orca to manage the plugins. But then can we move all the other GUI (e.g. the current page tabs in Orca's preferences) to the plugins themselves?

Anyhoo, you just made my day. Thanks!
--joanie

On Fri, 2021-06-04 at 23:41 +0200, chrys wrote:
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
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

_______________________________________________
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

Follow-Ups:
- Re: [orca-list] Pluginsystem for Orca using libpeas
  - From: Andy Borka

References:
- Re: [orca-list] Pluginsystem for Orca using libpeas
  - From: Andy Borka

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