Plugin / Extension Support

[Jab2870]

Not an issue but rather a feature request.

Do you plan on supporting plugins to extend functionality.

Obviously, Sketch, inkscape and gimp all have plugins that add a lot of functionality.

[Alecaddd]

Yes, a built-in pluggable system is being considered. It won't happen before the release of v1, but we will explore the technical implementation aspect as soon as possible. Allowing users to extend Akira's behavior with plugins is a vital aspect for the health of this application. Cheers

[Jab2870]

Excelent! Thanks

[gdelazzari]

Are you thinking about a native plugin system or one based on an embedded scripting engine like Lua, Python, Wren, Gravity, etc...? (here for more). I strongly vote for the second option for lots of reasons. I can elaborate if needed.

I would personally like to see Lua, Wren or Gravity, but there are other really lightweight, fast, simple and powerful languages to embed

[albfan]

Surely it will be based on https://gitlab.gnome.org/GNOME/libpeas, so gtk bindings in any possible known language will be available.

https://stackoverflow.com/a/18602339/848072

[Alecaddd]

@gdelazzari Nothing is set in stone right now, so, all of this is based on speculations and personal preferences. I'd love to have a system which allows the user to use their favourite scripting language. As corerctly pointed out by @albfan, Libpeas is currently the best choice as it supports C, Lua 5.1, Python 2, and Python 3, at it seems to be the most versatile option out there. But as I said, we didn't define anything yet and this is totally open for discussion and proposals.

[gdelazzari]

Oh okay, this changes my perspective then. I didn't know about libpeas since I'm not that into the Gnome ecosystem (which is way bigger than I originally thought at this point :smile: ). While I was assuming an implementation from scratch of the plugin system, my list of reasons was something like this (I'm crossing out stuff that libpeas definitely solves):

• ~having native plugins is more "fragile" because of ABI (using C this is solved, but it would be nice to go higher level)~ (but libpeas should be well designed and tested)
• ~a native plugin system is harder to implement~ (libpeas has the work already done)
• native plugins are less secure/can cause bad stuff if there are bugs inside (this depends on how libpeas works, I didn't have the time to go into the source code: does it load the native plugin code in executable memory and provide function pointers to there or does it sort of run a separate executable/process making it communicate with the main app through a messaging/RPC mechanism or something like that?)
• plugins made as scripts allow for faster development re-iteration when making changes but, more importantly, integrating a scripting language at the core of Akira would also allow to access a REPL which is really powerful for a developer testing ways to interact with the app before writing the real thing. See Blender for a good example of this. Could also be a feature for "power-users" that may find commands online (forums, etc...) to do special things (like duplicating objects in spiral patterns, etc... I know that's not a great example but I hope you get what I mean) without installing plugins and simply opening the REPL panel and pasting in.
• native plugins may get more troublesome if Akira is ever made cross-platform (I hope it will, so I'm also considering this point myself) - (again, not sure if libpeas here helps).

In any case libpeas seems a really good option, especially considering it's well tested and used in other places. Having multiple languages is also cool. Even if I'm in favour of scripting languages I can't deny that some day the need of native performance for some specific plugin may arise, so we would be covered.

I just want to add a note on Python here. If libpeas is used, I would vote for not including its runtime IMHO. Don't get me wrong, Python is amazing (it's my main language) but it's also a bit heavy for the kind of stuff it would be used to do here. I can see Python being used in a bigger and more complex software like Blender, but for something like what I'm imaging Akira will become, I think Lua (or Wren/Gravity) would fit better being more lightweight and also faster (Lua and Wren for sure, IDK about Gravity).

My original idea was to simply statically link with the {Lua/Wren/Gravity/...} interpreter, create a context for each plugin, inject lots of Akira API calls into it and let the plugin script file run and do its job (super rough, there are clearly better ways, but that was a starting point). Wren in particular is quite fast and really lightweight (the source code is really small considering what it offers).

[Alecaddd]

I'm not that into the Gnome ecosystem (which is way bigger than I originally thought at this point)

That's one of the many reasons behind our stack decision, super flexible and compatible with many different languages :smile:

does it load the native plugin code in executable memory and provide function pointers to there or does it sort of run a separate executable/process making it communicate with the main app through a messaging/RPC mechanism or something like that?)

I haven't played with libpeas enough to know the perfect answer, I only created plugins to an already enabled interface, but for what I know, libpeas gives lot of flexibility, allowing to create dedicated GInterfaces and extension points for the plugin to use, having full control on which aspects of the application can be touched and when.

We will have a series of tests in place, not sure if we'll have a 100% test coverage, but I'd like to aim to at cover at least 90% of the core features, and we won't accept any plugin which breaks a test.

Plugins will be manageable with a simple UI to activate/deactivate them accordingly (like it happens in elementary Code), and we won't hard code any of them out of the box. We will probably have a public repository of approved and actively maintained plugins, which Akira will be able to connect to and let the user decide which one to download and install, but we won't have any native plugin shipped inside the main app.

For the rest, it will come down to a thorough human review and writing tests to identify bottlenecks and performance issues.

I'm sure this workflow will take a better shape and will evolve with time after we open up Akira to accept plugins and extensions, but for now, as a first approach, this seems like a decent plan.

[dannycolin]

I would vote for not including its runtime IMHO. Don't get me wrong, Python is amazing (it's my main language) but it's also a bit heavy for the kind of stuff it would be used to do here. I can see Python being used in a bigger and more complex software like Blender, but for something like what I'm imaging Akira will become, I think Lua (or Wren/Gravity) would fit better being more lightweight and also faster

Wouldn't it be possible to add each languages support separately in term of dependencies. Because even if Python is heavier than Lua, I'd prefer to use it since I wouldn't need to dig into the documentation of yet another language. Saving time is definitely more important IMHO than saving a few MB of RAM or disk space especially knowing that Python 3 is already installed on most of the Linux distro vs. Lua.

Also, since Akira target designer, graphist and web developer, I think having a binding for JS (Gnome has something for that IIRC) would make a lot of sense because lots of us use it daily.

[Alecaddd]

@dannycolin these are all great suggestion we will definitely explore. For now, since the Plugin implementation is still further away, we haven't yet made a final decision, so every opinion matters.

Regarding JS, I think we will most likely have it out of the box for when we'll implement a Prototyping section, since we want to offer a scripting section to control the animation of shapes and SVGs, adding javascript since like a decent approach.

Once again, these are just speculations and random thoughts based on nothing concrete, so, don't quote me on that :smile:

[12people]

Another point in favor of JavaScript is that Sketch, Adobe XD, and Figma all use JS for their plug-ins. A developer of a plug-in for one of those would have a much easier time porting over their plug-in to Akira if it supported JS as well.

(Right now, I'm making a simple Sketch plugin, so this would be very relevant for me as well.)