Plugin improvment

[Grum999]

Hi,

From this post: Calling Filter dialog in Python Script - #7 by tiar

@tiar

how many people use and want to use Python plugins definitely made it seem much more important than it was before

I open a new topic to not pollute the original topic

I don’t really know how it was “before” but I have to admit that current way plugins are managed doesn’t incite to develop and use them:

• Installing a plugin is very complicated:
  – First of all, to find plugins, you need to go to #develop:plugins section or Krita resource page documentation (I have to update it with my plugins )
  – Download and unzip manually and/or use the Python Plugin Importer (if you’re lucky, plugin developer has provided a how-to, otherwise good luck…)
  – And then go to settings > configure > Python Plugin Manager
  – And then need to activate the plugin
  – And then need to restart Krita
  None of this is intuitive

• Using plugins is not really attractive; apart from the installation process:
  – The Tools > Scripts menu is not intuitive
  – The Tools > Scripts sub-menu is really discouraging (I hate going in this menu, it’s like a mess)

• Plugins proposed by default are, sorry, not really attractive about what you can really do
  I’m trying to create plugins with attractive interface because for most users (I think) it’s important to have something that is visually attractive (just look how active is the topic Krita UI Redesign started by @fullerhill_art and how people are interested by UI design)
  Also @EyeOdin and @Kapyia made plugins with attractive visual which provides good examples of what can be done (when I discovered their attractive plugins, it made me want to create my own plugins, before that…)

• And the most important I think, the pure developer point of view:
  – It’s currently very hard for a new comer (I don’t imagine for a beginner) to understand how to create a plugin (it took me time to create the first one)
  – PyKrita API has a good base, but there’s too much thing that don’t work or that don’t work as expected
  I don’t want to critique anything because I know all the work made behind to provide the API (I already took a look to C++ source…) and I know there’s more important priority before improvement of API…

But to get more plugin for Krita, with more users looking for them and more [potential] developers looking for them, here some idea to improve it:

1. Rename Tools menu by Plugins, it will be more attractive and easier to understand for everyone
2. Remove Scripts sub-menu and propose a predefined list of sub-menu to categorize the plugins (developers, utilities, filters, layer management, user interface, …)
3. Review entirely the plugin installation process
   3.1. Remove it from settings
   3.2. Create a dedicated window in Plugins menu (Plugins > Manage plugins)
   3.3. Review the interface and include natively in to this window the Python Plugin Importer feature
   — create a list of available plugins for download, with a button Install
   — once downloaded and installed, the plugin is checked as Active
   — avoid restart of Krita when a plugin is installed/activated/de-activated/de-installed
4. Review current proposed plugins (yes, they’re not attractive!)
5. Write a documentation easier and more complete
6. Improve PyKrita API (I know that some developers ask for better API but I’m not sure that’s the most important for now)

There’s no urgency about all of this, but this is things I started to think about some time ago, and @tiar comment decide me to start a topic.
There’s might be more idea to develop and clarify before starting anything, and determinate if the subject is really interesting or not…
(I unfortunately don’t have all the time I want to currently participate more, I’m still stucking with git and made me )

Grum999

[EyeOdin]

I agree for sure but as you said priorities

I kinda think there are not many Python addons around just because how hard it is to implement it and mostly lack of documentation to know what is available when you start. The way I learnt most stuff was literally by openning others scripts and see how they did it. I always felt I was stealing going this route.

Considering how few addons are around it means you don’t always find what you need as a reference. So you just have to download every possible addon because you might get lucky that one of them will respond to your question some time in the future.

If I had to vote of what I think is more important for Python and their users to use them I would say:

• Having to restart Krita after activating it - Very disruptive for the user as they feel they are actively going back on what they are doing. Gimp had the same thing and I really disliked it. in Krita it seems less distressful I don’t know why, maybe the loading screen or something, but it is still a full stop.

@Grum999

Rename Tools menu by Plugins , it will be more attractive and easier to understand for everyone

I always thought something more than “Scripts” would appear in this menu over time.
I do agree if nothing else would be added there besides Plugins.

@Grum999

Review current proposed plugins (yes, they’re not attractive!)

I agree there for sure…
The only ones I like are “Hello World” (good starting point learn even though I made a different style later), “Python Plugin Importer” and “Scripter”. The rest I tend to deactivate if I make a new installation of Krita.
There is also “Python API Reference” Script from @rbreu (not sure if it is her nick in this forum) that I appreciate alot and I think should be almost as the same level as other starting scripts:

GitHub - rbreu/krita-plugin-python-reference: A Krita plugin that displays a...

The other scripting needs I had, where the things I did. But I know people do use the other scripts especially those related to brushes.

One thing I might add just because I find peculiar, is the holy trinity of Krita Python:
1- Python (language)
2- PyQt5
3- Krita API
they are like the 3 gates you need to pass to implement something.
ex: you might be able to do something in Python but if PyQt5 has the same option it will be negated. And if you can do something in PyQt5 but Krita does not like it, it will be negated too.
This can happen to commands or even on code ordering.
It is like a balance to walk and pass through all 3 gates and some times the only solution to implement something feels unabalanced from certain perspectives.

[Grum999]

@EyeOdin

I kinda think there are not many Python addons around just because how hard it is to implement it and mostly lack of documentation to know what is available when you start. The way I learnt most stuff was literally by openning others scripts and see how they did it.

Yes… I had to analyze code of other plugin to understand how to build mine…
But, maybe as now we are more comfortable with plugin, we can take time to write a documentation. I don’t really know how to write this and what we need to write… may be a complete how-to to create a basic plugin rather than a theoretical documentation…

@EyeOdin

Having to restart Krita after activating it - Very disruptive for the user as they feel they are actively going back on what they are doing. Gimp had the same thing and I really disliked it. in Krita it seems less distressful I don’t know why, maybe the loading screen or something, but it is still a full stop.

Technically from what I saw, python and plugins are loaded at Krita startup and it might be difficult to reload all of this on the ‘fly’…
I don’t know the underlying technical method.
It seems that python library is loaded and create a python session, in which all plugins are loaded.
This means that all plugins are loaded in the same workspace, as all libraries.

To let a plugin manager being able to load/unload plugin on the ‘fly’, solutions could be:

• Completely stop/start the python session (may be the easiest way) but may have on impact on current loaded/running plugins
• Run each plugin in it’s own python session, but it might be resource consuming and I’m not sure that it will be easier to connect plugins to Krita interface
• Implement a standardized way of writing plugins and declare them, to allow plugin engine being able to load/unload them on the ‘fly’ (I’m currently using importlibto be able to reload entirely plugin when I’m doing some dev with scripter plugin) so mybe it could be a way to explore…

@EyeOdin

I do agree if nothing else would be added there besides Plugins.

It make sense
Plugins with a plugin manager.

@EyeOdin

There is also “Python API Reference” Script from @rbreu (not sure if it is her nick in this forum) that I appreciate alot and I think should be almost as the same level as other starting scripts:

Yes sorry, I didn’t list all plugins and authors (even if list is short)

@EyeOdin

they are like the 3 gates you need to pass to implement something.

Yes, but I don’t see how it can be made differently

Grum999

[tiar]

Installing a new plugin: I agree it has too many steps. When creating the plugin, there is an option to automatically enable it, too. It must be added to the Import Python plugin too (as a checkbox, I guess, and checked by default). And then there needs to be an instruction “please restart Krita to see the plugin in action”. That will make it clear for users what to do.

Plugins available by default were written to just showcase the possibilities in Python API, afaik. They can be changed or added etc., but I think all plugins there needs to be either GPL or CC0 (like some of the already available ones) to allow modifications and to allow distribution within Krita. And it would need some investigations, which plugins are the most useful, which are the most reliable etc.

It’s currently very hard for a new comer (I don’t imagine for a beginner) to understand how to create a plugin (it took me time to create the first one)

Have you used the Python Script Starter?

I was thinking of documenting a whole process of making a new plugin. Like a tutorial. It would use the script starter since that’s the easier way to get it all started, I think.

PyKrita API has a good base, but there’s too much thing that don’t work or that don’t work as expected

It would be good to make a list of things like that.

@Grum999

Rename Tools menu by Plugins , it will be more attractive and easier to understand for everyone

That is, I believe, a historical thing. Krita had macros there before and stuff. I agree that even if we get other Tools, it would be better to have Plugins as a separate menu entry. I also agree with having subcategories - it will be easier to find the specific plugin you look for.

@Grum999

Review entirely the plugin installation process

I agree with 3.2, not sure about 3.1, maybe it should be in managing resources instead?

@Grum999

create a list of available plugins for download, with a button Install

That won’t be that straight-forward because (1) there is no specific place with Krita’s plugins that would be managed by Krita; all of them are shared on different places like github, KDE Invent, only those that are included in Krita itself are on the list by default, and they don’t need downloading, (2) Krita by default has no connection to the internet (vide News widget on the Welcome screen, off by default), (3) allowing adding custom urls would be a bit of security risk for users, and if Krita shows those urls, it’s kind of like saying “sure, they are safe!”, while we cannot be sure about that.

@Grum999

avoid restart of Krita when a plugin is installed/activated/de-activated/de-installed

It might not be that easy to do.

Ok, so my version of

TODO list

• Fix menu entries for plugins
  • rename Tools to Plugins
  • figure out which categories we’ll need
  • rename submenu entries for plugins from Scripts to those subcategories
    Note: I didn’t check it but I guess it’s entirely possible that those things above can be achieved in scripts themselves; they select the location they are in after all.
• Add checkbox “enable plugin”, checked by default, to Import Python Plugin script
• Improve Resources page → plugins section - Resources — Krita Manual 5.2.0 documentation
  • add all the plugins in the development that are here on KA (ask the developer if it’s ready to be used (if not, don’t add it to the page) and if it’s considered finished (if yes, mention it, possibly))
  • divide plugins into categories
  • add one or two sentences of what the plugin actually does, since it’s not exactly obvious often…
  • two links: one for the source code and stuff (ex.: link to the github main page for the project), and one to just download the .zip directly.
• Reconsider default set of plugins
• Possibly include more/prettier plugins by default in Krita.
  Steps that every plugin developer should take to include their plugin into Krita:
  • publish the plugin in GPL, CC0 or similar, compatible license
  • (all files needs to have license on top + information about the author, unless it’s CC0, there could be a LICENSE file as well)
  • it needs to be put for review as a MR on KDE Invent: invent.kde.org by the developer (or possible maintainer) - it needs to be checked for security etc. before it can be added to Krita
  • the developer (or the person who puts it for review) needs to pinky swear they will maintain it (for example fix important bugs)
  • note that all improvements to the plugin will have to go through the same review process as well. The development of the plugin can still happen in the developer’s private repository and it can still be distributed and linked etc.
• Better manual how to create plugins.
  For example this page: How to make a Krita Python plugin — Krita Manual 5.2.0 documentation could be summed up by “just use script starter”. It needs some planning. There are multiple pages in User Manual part: Python Scripting — Krita Manual 5.2.0 documentation and one more in Contributors Manual -> Untranslatable pages: Python Developer Tools — Krita Manual 5.2.0 documentation - it needs to be integrated and thought through. Maybe the User Manual should only say how to import them, and Contributors Manual how to write them? Or all should be in User Manual? Or some parts in Reference Manual?
• Make a list of improvements and shortcomings of Python API.

I would like to get @halla 's approval first but it looks like a good candidate for a Phabricator task.

[Grum999]

@tiar

Have you used the Python Script Starter?

Yes, I always use it
But even with it, it’s not easy to start… And I don’t even imagine how it would be without

@tiar

I was thinking of documenting a whole process of making a new plugin. Like a tutorial. It would use the script starter since that’s the easier way to get it all started, I think.

I have this idea too, I just need some time (Not many time available since I’m back to the office )
My idea was to provide a documentation with a “step by step” to build a simple plugin (no theory: practice)
But also need the idea of a simple plugin, that could be useful, with a light interface and basic algorithm behind.

@tiar

It would be good to make a list of things like that.

Quickly, the filters.
But I need to check with 4.3.0beta2 if problems are still here.

@tiar

I agree with 3.2, not sure about 3.1, maybe it should be in managing resources instead?

It’s an idea, I’m open to any solution that will allow user to install plugin in an easier way:)

@tiar

(3) allowing adding custom urls would be a bit of security risk for users, and if Krita shows those urls, it’s kind of like saying “sure, they are safe!”

Yeah I agree about this.
Not possible to check all plugins and all plugins version to verify if there’s no malicious code…
That’s something difficult to implement

@tiar

@Grum999

avoid restart of Krita when a plugin is installed/activated/de-activated/de-installed

It might not be that easy to do.

Currently writing another plugin, I’ve implemented a solution that allow to reload all modules (currently 22, don’t know why I started to write a plugin with so much work ) on the fly in Python Script Starter without having to restart Krita.
I have to check but it can certainly be used to install a new plugin without having to restart Krita.

@tiar

TODO list

I’ll take time to read it carefully and give feedback in a second time.

Anyway, thank you for the time spent on this subject, I know there’s other higher priorities

Grum999

[EyeOdin]

Strangely enough I made a custom “Blank Plugin” where I make mine now and do my quick testing:
https://github.com/EyeOdin/blank

maybe because I made it myself or something but I just open the file and edit in the indicated spot, or change the UI and it reacts on the next start up. No *.ui to *.py exports in PyQt5. I already forgot the command to do it XP. At least for me it is easyer.

[tiar]

How does it differ from using the Script Starter and why it can be easier/better? Maybe it could be integrated into the script starter, like, start a script with a separate .ui file?

[EyeOdin]

@tiar

How does it differ from using the Script Starter and why it can be easier/better?

well nothing much really in terms what is on the code itself.

the difference for me is on the amount of clicks I need to get a clean slate to use i guess. The plugin creator makes too many questions, when I am asked to name something I will spend hours on it…

I just open Atom and select the file and I am already doing it. After I test it I tend to just delete all my edits after and it becomes empty again and then I can keep working on my “main” one.

@tiar

Maybe it could be integrated into the script starter, like, start a script with a separate .ui file?

I think the separate UI file load is the best way to do it. without QtDesigner I don’t know how I would ever managed to make a UI with just code. I would tottaly be cool with it if it came inside Krita already.

However I am not sure how you could make it as a official starting script since it would be suffering changes on the original files. Maybe it would just make a copy to the user files if activated? and the scripter would open? I am just making stuff up.

Either way on another side note, having to restart Krita to see the changes is already a pain enough for me. I get so lazy to hit the Krita Icon that I made Ctrl+Alt+K start krita when I cant be bothered to pick up the mouse again.
I have allocated Ctrl+Alt+B for blender too when i start making stuff on that next.
If that shortcut would come built in, after installing it would be awesome for me really

[Grum999]

@tiar

• Fix menu entries for plugins
  – figure out which categories we’ll need

This point may need another topic, because I think it will generate some discussion to be sure to determinate which kind of category we want to see.

@tiar

• Fix menu entries for plugins
  – rename submenu entries for plugins from Scripts to those subcategories
  Note: I didn’t check it but I guess it’s entirely possible that those things above can be achieved in scripts themselves; they select the location they are in after all.

Yes it might be possible.
But the risk is to have different plugins creating similar sub-menu; providing a predefined place in a menu will reduce this risk and improve the way the plugins will be organized

@tiar

• Improve Resources page → plugins section

Yes for all ideas
Maybe, in plugin management window, add a link to the page: it will be easier to find it

@tiar

• Reconsider default set of plugins

Plugins provided as example should be available by download for people interested in plugin development.
Or clearly categorized as ‘Developer sample’
Most of users don’t care about plugin if they can’t really use them

@tiar

• Possibly include more/prettier plugins by default in Krita.

Yes
A beautiful showcase with good products attracts more than a stall of odds and ends

@tiar

– it needs to be put for review as a MR on KDE Invent: invent.kde.org by the developer (or possible maintainer) - it needs to be checked for security etc. before it can be added to Krita

git

@tiar

– The developer (or the person who puts it for review) needs to pinky swear they will maintain it (for example fix important bugs)

That’s something difficult. It could work 1, 2, 5 years, and maybe one day for miscellaneous reason the developer can’t continue to maintain the plugin…
But as the plugin is included in default Krita’s plugins bundle, a maintenance is highly recommended (at least, compatibility with new version of Krita)

@tiar

Better manual how to create plugins.

From my own experience, creation of my first plugin was really difficult at the beginning.
I had to read doc to understand the examples, take a look on existing plugin but they’re not easy to understand, search on KA forum, search for tutorials on google…
I was really motivated to build one, but it’s quite discouraging at first.

@tiar

• Make a list of improvements and shortcomings of Python API.

May need a new topic

@tiar

I would like to get @boud 's approval first but it looks like a good candidate for a Phabricator task.

Perhaps we should deepen all these points before doing a Phabricator?
Having something properly defined (or for which main stream are validated) is always better.

From my point of view, once again, there’s no urgency and taking time to define need and possible implementation will allow to define something better at the end

Grum999

[tiar]

@Grum999

Maybe, in plugin management window, add a link to the page: it will be easier to find it

Oh yes, that would be good! And it wouldn’t suggest “they are all safe” since there could be a warning, and they are links to external sites anyway, I think…

[Grum999]

A disclaimer on this page should be a good thing yes

Grum999

[Kapyia]

@Grum999

Also @EyeOdin and @Kapyia made plugins with attractive visual which provides good examples of what can be done

Well, it’s easy enough to keep KB attractive when it mainly consists of Krita’s own dockers

A lot of good reading in this topic even with such few posts! I feel like I can weigh in on this a little:

@Grum999

Installing a plugin is very complicated

To an extent, yes. At least if you install plugins manually.
I would definitely encourage people to make the Plugin Importer the default way to install a plugin. The Plugin Importer is very straightforward to use, and plugin developers definitely should take advantage of something that makes installation as convenient as possible for the end user. But I don’t think I ever found documentation on how to create a .zip archive compatible with the plugin importer, which is concerning. Thankfully it was easy enough to guess for me, but it might not be to everyone.

But the fact that it requires not one but two restarts to get a plugin going is rather tedious. Kinda reminds me of the good old days of having to input multiple cd-roms to install a software if it would be possible to load in plugins without restarting Krita altogether I would have no complaints whatsoever. I kinda wish plugins were activated by default in Krita, but I take it they aren’t for security reasons?

“Using plugins is not really attractive; apart from the installation process”

This is currently a bit of a non-issue if you ask me. I agree that the wording “Tools” could be better since tools typically already refers to the ones in the toolbox. Perhaps “Utilities” would be better here, if the menu is to house both Macros and Plugins. That being said, if there’s only one entry in a menu then that entry should be the menu. Until the Macros feature get fixed it’s worth renaming the entire menu to ‘Plugins’ or ‘Scripts’. But it’s a very minor improvement of UX if you ask me.

Sub-menus are a good idea, but chance are they’ll be completely foregone by new people testing the waters, and plugins might fit multiple categories, or none. I’m honestly not sure what the best way to do this would be. What I’m personally missing atm is a convenient way to add new sub-menus where you can organize your own scripts and their respective settings. It’s possible, but it’s very cumbersome digging through all the child widgets/menus/actions in the main window just to be able to add a sub-menu under Tools->Scripts(unless I’m misunderstanding something about how this aspect of Qt works).

@tiar

Note: I didn’t check it but I guess it’s entirely possible that those things above can be achieved in scripts themselves; they select the location they are in after all

Scripts are supposed set which pre-existing menu they are added to, but they can’t create a new (sub-)menu. That has to be done via the main window and PyQt5.

“Plugins proposed by default are, sorry, not really attractive”

Also a bit of a non-issue imo. It’s clear to me that most of them were made as small showcases of the API, but they also have good use cases. Could the Ten Scripts dialog look snazzier? Absolutely. Does it have to? Not really, it’s very easy to use and performs well (to the best of my knowledge).

“It’s currently very hard for a new comer to understand how to create a plugin”

Is it though? I can agree the process of setting up a new plugin (creating the appropriate .dekstop file, init.py, the main plugin class, folder structure) is a bit lengthy, but if you have a bit of experience with Python then it’s nothing out of the ordinary. And you probably do want a bit of prior experience with Python. It all makes even more sense when you have some understanding of the different components and systems in Qt. Each part of the set up has a very reasonable purpose. Like @EyeOdin said, the “holy trinity” of Python, (Py)Qt5, and LibKis. knowing Qt especially opens up a lot of doors in plugin development!

But a good improvement would be to include a download link to a blank/template plugin somewhere in the documentation just to help people get going. Btw what is this “Python Script Starter” people are talking about??

“PyKrita API has a good base, but there’s too much thing that don’t work or that don’t work as expected”

That’s why it’s so fantastic we’re finally seeing people putting the API to the test, discovering problems, and reporting them to the devs (and possibly help patch them as well ). And as for missing features, I wonder if there’s a wishlist for new features to be added to the API somewhere. I have a couple of entrys to add to that list for sure .

[Grum999]

@EyeOdin

the difference for me is on the amount of clicks I need to get a clean slate to use i guess. The plugin creator makes too many questions, when I am asked to name something I will spend hours on it…

Now, when I start to create a new plugin, I use another one that I already created as base rather than using the Script Starter.

But for the first times I started to try to create a plugin, it helped me to create base files.

@EyeOdin

I think the separate UI file load is the best way to do it. without QtDesigner I don’t know how I would ever managed to make a UI with just code.

I started UI by coding it… I discovered the QT Designer and ui file later…

Coding interface is funny for small and simple interfaces.
Being able to create some UI items by code could be useful, especially when you start to create your own Qt widgets.
But for complex interface, using ui file is the best way.
Made conversion to py file I never tested; it’s more work if you need to review the interface…

Grum999

[Grum999]

Hi

I created a dedicated topic about plugin management

Plugin improvment - plugin manager

Hi, Following discussion started in https://krita-artists.org/t/plugin-improvment/7479?u=grum999, I create a new topic to talk about the plugin installation system. Here some point from original topic: I agree with 3.2, not sure about 3.1, maybe it should be in managing resources instead? It might not be that easy to do. From this, I started to write a plugin manager. Sources: https://github.com/Grum999/PluginManager Zip package: https://github.com/Grum999/PluginManager/releases/d…

Grum999

[EyeOdin]

Well something else did came to mind to me that could be really nice.

Having the plugin folder path:
C:\Users\EyeOd\AppData\Roaming\krita\pykrita\

And instead of having inside a loose file with the folder:
example.desktop (file) example (folder)

maybe just have a folder inside pykrita with everything inside, and the name of the plugin would be the name of the folder. So example folder would contain:
example.desktop init.py example.py example_manual.html

Why would I suggest this?
It would allow to make the plugin folder an acctual seperate project folder allowing that folder to connect to github. I am still learnning how to use github properly because I have my own filing system and cloud, but it seems to not work smoothly because of this common shared folder.

If I clone what is inside the plugin folder the plugin is incomplete but if I connect what is inside the pykrita folder I will send everything I have installed on my krita and not just the plugin I am working on.

[tiar]

@Kapyia

Btw what is this “Python Script Starter” people are talking about??

Tools → Scripts → Krita Script Starter. It creates all those files (so it replaces the “lengthy” process with a few clicks), and it only asks for the name and if it’s an extension or a docker, so I don’t get the “too may questions” raised above argument tbh.

Tbh I don’t see that many plugins to remove… the green ones are those that should stay for various reasons, mostly because they fill important gaps in Krita functionality etc. The purple ones are scripts that operate on multiple files at once. The blue ones are for development, they could be disabled by default but should stay there (I would actually want to check the Python API plugin and check if we could integrate it into Krita by default, too). The red Hello World is the only one that I think could be removed now. The rest are ones I’m not sure about.

But in general, I’m not sure if removing functionalities from Krita is such a good idea just because they are “ugly” or there are more fancier features out there. Filters are ugly too, just grey dialogs with bunch of parameters. But unless there is a good reason to remove one, they just stay there.

@Grum999

That’s something difficult. It could work 1, 2, 5 years, and maybe one day for miscellaneous reason the developer can’t continue to maintain the plugin…
But as the plugin is included in default Krita’s plugins bundle, a maintenance is highly recommended (at least, compatibility with new version of Krita)

Talking of good reasons… basically if there is a feature that nobody cares for and it’s buggy, it can be removed. If there is someone who promises to look after a feature, then this kind of situation happens less often, I guess.

[Kapyia]

Interesting. Is my installation just funky, or is it not part of the Windows 4.2.9 release?

[tiar]

On Linux 4.2.9 appimage I have it:

Can someone else check on Windows? If they have it, @Kapyia maybe you’d want to reinstall… but you can also just go here: plugins/python/krita_script_starter · master · Graphics / Krita · GitLab download it as zip, unzip, make a new folder for the files and make sure it all works (you’ve made plugins so you’ll know how to make it work… I would expect it to work right away).

[Rakurri]

From the 4.2.9 as a portable zip, here is what I see

[Rakurri]

And here is how it looks for me on my current 4.3.0-beta2