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

[chrys <chrys linux-a11y org>]

Howdy Joanie,

puh, i hoped you like it :).
yea its currently a very mixture of procedural programming and object 
orientation. we should go IMO the straight OOP way.

> I'm not sure what all falls under the heading of "Core". Could you list
> some more examples?
well i thought those are stuff what should not be able to unload.
- orcas initialization process
- basic keyboard handling
- basic setting handling (maybe - depends how far we want go)
- some basic  "backend" (like a slimed down, restructured version of the 
"default.py" script), what could be reused by other system plugins like QT.
stuff like that. technically, they can all live in a single folder. It 
could be defined in the plugin definition if a plugin is hidden (not 
manual loadable using the plugin manager) or build-in (not unloadable, 
as it provides basic functionality) But i thought its an good idea to do 
some separation. in fact libpeas supports as many plugin folders we 
want. is a one liner of code to add a place to search for plugins.
if core does not make sense, we can just all move them to system.

> Would system also include speech, braille, maybe flat review, mouse
> review, etc.?
Yes. all of them are quite optional. if you use braille you might not 
need speech. and the opposite. if you don't use a mouse, you don't need 
mouse review.

> 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.
yes, the idea is that every plugin provides its own UI elements, Key 
Bindings, settings.
maybe we can even have settings plugins. maybe gnome can use gsettings, 
KDE can use JSON. just as an example. Just an idea. lets start with 
gsettings.

> 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.
let me try the date-time stuff. sounds like something i can get handled 
without bother you :).
> 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?
well, my idea would be some kind of generic GUI interface. so we can 
have a QT and a GTK gui. maybe the gui could be created in an generic 
way just from the settings. maybe with category, name, description and 
value.
so the plugins provide its settings, and the GUI plugin uses the 
settings to create the UI by its own? do you understand what i think? 
then the UI grows by itself without any extra overhead.
if we get this done in an generic way, we can just implement an type 
ahead filter for settings as well (what i planned before my ERP project 
started, what locked me for several years, but comes to an end now).
if you disagree, IMO for sure, the plugins should handle its UI its own 
then. otherwise we hard-code plugins in an ugly way on the preferences 
window. and this  should not happen.

well, but what comes to my mind, if we wanna do this, how should we 
behave in development?
sending every single patch for an huge undertaking like that could be a 
huge overhead for you to review. whats the best way here?
or should i continue my branch on github ( i can give you write access 
as well of course) and we can review it on an given day? an merge all 
changes back then? just asking, because it might require a lot of 
changes in height frequency.
what do you think?

cheers chrys


Am 05.06.21 um 11:50 schrieb Joanmarie Diggs:
> 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