As I told to Boud, I'm talking with users to get some interesting ideas and suggestions to these next three months implementing Krita's showcase to for the GSoC.

Chatting with David Revoy, Raghukamath and Boudewijn, I've had some good suggestions to Scripts and plugins to the Krita:

• Image color space for multiple documents

• Changing canvas size for multiple documents

• Take a predefined filter or one applied on one document and to apply in all comic pages for example or another documents(inputted list).

• High Pass Filter - https://bugs.kde.org/show_bug.cgi?id=374972

• Docker that shows thumbnails for last ten opened images

• A multifill script - http://davidrevoy.com/article306/tons-of-potions-part-2-multifill

• Export all the layers (batch) - http://registry.gimp.org/node/28268

• An "export to web" script

• Duplicate image.

• Scale down an image.

• Export to jpg X% quality.

• Plugin to add a docker that shows most recent opened documents with thumbnails

Other ideas from users from the forum topic:

• A shortcut that shows palette with color history and common colors.

• Pop-up with a few buttons "apply X filter with Y settings".

• Pop-up what contain color selector+recent colors+color sliders.

• Hotkeys for brush presets, something like the "ten brushes plugin".

• HUD search menu like GIMP.

• Remember last used/or predefined location.

• Rotate image/s.

Then, I need your help to decide my set of plugins/scripts to GSoC, in special my mentors @woltherav and @rempt.

• Image color space for multiple documents - yes, that should be an easy one
• Changing canvas size for multiple documents - same thing, doesn't need new api either
• Take a predefined filter or one applied on one document and to apply in all comic pages for example or another documents(inputted list). - yes
• High Pass Filter - https://bugs.kde.org/show_bug.cgi?id=374972 - yes
• Docker that shows thumbnails for last ten opened images - yes
• A multifill script - http://davidrevoy.com/article306/tons-of-potions-part-2-multifill - yes
• Export all the layers (batch) - http://registry.gimp.org/node/28268 - yes
• An "export to web" script - doubtful...
• Duplicate image. Could be interesting
• Scale down an image. - same as the second one?
• Export to jpg X% quality. - doable, a bit trivial
• Plugin to add a docker that shows most recent opened documents with thumbnails - same as the other docker idea?

• A shortcut that shows palette with color history and common colors. - yes
• Pop-up with a few buttons "apply X filter with Y settings". - not sure about this one, might be itneresting
• Pop-up what contain color selector+recent colors+color sliders. - hm... not sure what that adds, though the addition to the libkis api would be interesting
• Hotkeys for brush presets, something like the "ten brushes plugin". -- that should already be in the 10 brushes plugin, but might be broken and needs fixing
• HUD search menu like GIMP. -- that's going to be really tricky, I think, though we could use the list of actions for it
• Remember last used/or predefined location. - that should be fixed in the file dialogs, probably not a good idea
• Rotate image/s. - that's already in the api, maybe something generic that allows people to create a list of images then apply rotate/scale etc?

Hi, @eliakinalmeida!

I'll try to lay out my ideas about scripting here:

1. As far as I can tell, the main purpose of the interactive scripting editor and the showcases is to allow the user to extend his Krita with some custom functions that save his time. It means that we should pay attention not only to the script editing part, but also to way how to run them. So at least such features might be necessary for the user:
   1. A docker with a list of "registered" scripts that allows the user (can be implemented in python as par to the showcase actually):
      • add/remove "registered" scripts
      • run/stop script
      • group scripts in folders
      • assign a shortcut to the script
   2. It should be possible to assign a shortcut to each script
   3. It should be possible to create a toolbar with buttons, that call a script. This functionality will be automatically available when the script actions are registered in the KDE's action registry.
   4. [questionalbe] It should be possible to run a script from Krita command-line interface

2. As for the script showcases, I would first concentrate on the routine tasks painters would need to automate, e.g.
   • export layers into files using some name mask
   • prepare the image for web and export: merge down, convert to 8b RGB, duplicate, apply Unsharp Mask, change the opacity of the duplicated layer, scale down, export
   • import images from a folder as layers
   • [questionable] download/upload form Google Drive

3. Here I'll just comment on the rest of ideas listed in your message

• Image color space for multiple documents
• Changing canvas size for multiple documents
• Take a predefined filter or one applied on one document and to apply in all comic pages for example or another documents(inputted list).

There are really candidates for a command line interface. Or for some special "batch-apply" dialog, where you can select a set of images, select a filter to apply, choose the output file names and start a batch-operation.

• High Pass Filter - https://bugs.kde.org/show_bug.cgi?id=374972

Sounds like a candidate for a normal KisFilter implementation. Python plugin will not let the user to use it in Adjustment layers and something.

• Docker that shows thumbnails for last ten opened images
• A multifill script - http://davidrevoy.com/article306/tons-of-potions-part-2-multifill

Sound nice

• Export all the layers (batch) - http://registry.gimp.org/node/28268
• An "export to web" script
• Duplicate image.
• Scale down an image.
• Export to jpg X% quality.
• Plugin to add a docker that shows most recent opened documents with thumbnails

Nice list of scripts for point 2 :)

Other ideas from users from the forum topic:

• A shortcut that shows palette with color history and common colors.

Don't we have it already? I'm not sure that python can do anything here.

• Pop-up with a few buttons "apply X filter with Y settings".

Nice plugin. I would so it instead of the high-pass filter. It showcases the same API, but more useful.

• Pop-up what contain color selector+recent colors+color sliders.

Will it just reuse the advanced color selector? And don't we have it already?

• Hotkeys for brush presets, something like the "ten brushes plugin".
• HUD search menu like GIMP.

These two sound nice.

• Remember last used/or predefined location.

I guess it should just be fixed in Krita itself :)

• Rotate image/s.

We already have detailed menu actions for that. So doing a script will be just an example without real usecase.

Conclusion

I think that point 1 and 2 should be of the top priority and all of them can be implemented within Python API (I mean the "python scripts docker" can be implemented in python itself). From the list of wishes, in my opinion "brushes shortcuts", "filters predefined shortcuts" and "actions HUD" are nice features, although of a bit lower priority that 1 and 2.

In T5885#94481, @dkazakov wrote:

Hi, @eliakinalmeida!

I'll try to lay out my ideas about scripting here:

1. As far as I can tell, the main purpose of the interactive scripting editor and the showcases is to allow the user to extend his Krita with some custom functions that save his time. It means that we should pay attention not only to the script editing part, but also to way how to run them. So at least such features might be necessary for the user:
   1. A docker with a list of "registered" scripts that allows the user (can be implemented in python as par to the showcase actually):
      • add/remove "registered" scripts
      • run/stop script
      • group scripts in folders
      • assign a shortcut to the script

I suspect that you haven't built Krita with scripting yet? This is already implemented, and managing the scripts is part of the settings dialog.

2. It should be possible to assign a shortcut to each script
3. It should be possible to create a toolbar with buttons, that call a script. This functionality will be automatically available when the script actions are registered in the KDE's action registry.

That's already possible, since scripts can add actions to the action registry.

4. [questionalbe] It should be possible to run a script from Krita command-line interface

No, that's not questionable, but we've already got the kritarunner application for that.

2. As for the script showcases, I would first concentrate on the routine tasks painters would need to automate, e.g.
   • export layers into files using some name mask
   • prepare the image for web and export: merge down, convert to 8b RGB, duplicate, apply Unsharp Mask, change the opacity of the duplicated layer, scale down, export
   • import images from a folder as layers
   • [questionable] download/upload form Google Drive

That's not really something to showcase; such a sequence of actions is something people should cobble together individually. It's already possible, of course.

3. Here I'll just comment on the rest of ideas listed in your message

• Image color space for multiple documents
• Changing canvas size for multiple documents
• Take a predefined filter or one applied on one document and to apply in all comic pages for example or another documents(inputted list).

There are really candidates for a command line interface. Or for some special "batch-apply" dialog, where you can select a set of images, select a filter to apply, choose the output file names and start a batch-operation.

I think that that was the idea.

• High Pass Filter - https://bugs.kde.org/show_bug.cgi?id=374972

Sounds like a candidate for a normal KisFilter implementation. Python plugin will not let the user to use it in Adjustment layers and something.

Sure, but it would be good to have one showcase that shows how to mangle pixel data from python, so this is one candidate. That people cannot use it in a filter layer... Well, the same holds true for all the gmic filters, so that's not new. Having this filter as a testcase for scripting has been something I've wanted to do for a long time...

• Pop-up with a few buttons "apply X filter with Y settings".

Nice plugin. I would so it instead of the high-pass filter. It showcases the same API, but more useful.

Um, no -- this would activate a filter, while the high pass filter script would actually get pixel data, do stuff and write it back.

I would argue having one or two regular operations scripts(such as web export) would be good because then we can verify whether this is possible with the current API. Similarly, people use these scripts as a basis for their own.

I also agree that having the highpass filter as a sample script is a good idea. Again, it tests the api, and it allows people to see that writing their own filters is possible. If people request a filter-layer version, then we can do that later.

I suspect that you haven't built Krita with scripting yet? This is already implemented, and managing the scripts is part of the settings dialog.

Sorry for my outdateness :) I built scripting branch about two months ago. It's good that it is already implemented.

2. As for the script showcases, I would first concentrate on the routine tasks painters would need to automate, e.g.
   • export layers into files using some name mask
   • prepare the image for web and export: merge down, convert to 8b RGB, duplicate, apply Unsharp Mask, change the opacity of the duplicated layer, scale down, export
   • import images from a folder as layers
   • [questionable] download/upload form Google Drive

That's not really something to showcase; such a sequence of actions is something people should cobble together individually. It's already possible, of course.

Since we are showcasing, they might be good examples. Though I don't insist.

• High Pass Filter - https://bugs.kde.org/show_bug.cgi?id=374972

Sounds like a candidate for a normal KisFilter implementation. Python plugin will not let the user to use it in Adjustment layers and something.

Sure, but it would be good to have one showcase that shows how to mangle pixel data from python, so this is one candidate. That people cannot use it in a filter layer... Well, the same holds true for all the gmic filters, so that's not new. Having this filter as a testcase for scripting has been something I've wanted to do for a long time...

As far as I can see from the David's explanation of the filter, it is possible to implement the filter just by copying the layers/paint devices, filtering them with existing filters and merging them back using existing composite ops. Using raw pixel data here... At least judging by this explanation it is not needed :)

And if you still decide to do raw pixel data access, you might need to export KisGaussianKernel glass, and, probably, KisConvolutionPainter.

To find the best option for showing raw pixel access is to ask game designers (@gdquest, ping). When developing games, they often need to combine multiple grayscale "channels" (hightmaps, textures, lighting) into one RGBA image to pass to the game engine. This combining is very custom and it is an ideal target for being implemented as a script. And it is also a nice target for showing raw data access.

When developing games, they often need to combine multiple grayscale "channels" (hightmaps, textures, lighting) into one RGBA image to pass to the game engine. This combining is very custom and it is an ideal target for being implemented as a script. And it is also a nice target for showing raw data access.

Yes, it's custom for each game. 3 greyscale textures combined into one's R, G and B channels. Some use the A too, but it gets unpacked as a separate image and doubles the memory cost IIRC.

Will there be handlers/observers? As you've mentioned export, both gamedevs and web designers use continuous export all the time. Because you must check how the textures/sprites look in the game, with lighting, shaders and post-processing applied. Without it, it's common to re-export some images several times a day. Affinity and PS can save in the background, so they both offer this feature.
A script that auto-exports modified groups/layers on save would do the job beautifully though.

@rempt

Plugin to add a docker that shows most recent opened documents with thumbnails - same as the other docker idea?

Sorry, I repeated this part :)

Scale down an image. - same as the second one?

I didn't get it, isn't "scale image" different of "canvas resize"?

Export to jpg X% quality. - doable, a bit trivial

I agree, but I think that makes sense in some contexts. They can merge this one with other scripts.

Rotate image/s. - that's already in the API, maybe something generic that allows people to create a list of images then apply rotate/scale etc?

It's possible to make a generic script.

Hotkeys for brush presets, something like the "ten brushes plugin". -- that should already be in the 10 brushes plugin, but might be broken and needs fixing.

I will fix that

@dkazakov

It should be possible to assign a shortcut to each script
It should be possible to create a toolbar with buttons, that call a script. This functionality will be automatically available when the script actions are registered in the KDE's action registry.

I really like this idea, because this puts shortcuts on another level. I'm thinking of something like a docker that you can create buttons with shortcuts and associate with files in your own file system. When the action is triggered, the script is executed. The script can be anything and that's cool (I think).

It was good to see all this discussion about the showcase and that's really amazing. Reading all these comments, I defined some steps to my work:

1 - Implement simple scripts.

Image color space for multiple documents
Changing canvas size for multiple documents
Take a predefined filter or one applied on one document and to apply in all comic pages for example or another documents(inputted list).
Export all the layers (batch) - http://registry.gimp.org/node/28268
Duplicate image
Export to jpg X% quality.
Generic script to take a list of images (inputted list) and apply rotate/scale

2 - Implement plugins that I have solutions in my mind

Fix ten brush plugins
A shortcut that shows palette with color history and common colors.
Docker that shows thumbnails for last ten opened images
A multifill script - http://davidrevoy.com/article306/tons-of-potions-part-2-multifill
A Docker where you can create your own button with a shortcut and point to one script in your file system.

3 - Implement more complex plugins to me

High Pass Filter - https://bugs.kde.org/show_bug.cgi?id=374972
HUD search menu like GIMP

What do you think?

P.S. Some interesting point to talk about is how to make this available to users? maybe using share.krita.org ? We could use this new feature in progress (https://phabricator.kde.org/T6108 ). :D

About revision D5998

That impact the Scripter plugin, to be more specific the run slot that executes Python scripts wrote in the editor.

How you probably read, we need to create a function main to execute code when a module is created. That's clear, but why am I using modules?

The shorter answer, you can see in the revision, but exist some specific reasons that I will list here:

1. It's slower
   • It's not the main issue, but obviously, compile and evaluate a big string is slower than import a module.
2. Makes it easier to manipulate from code
   • It's better to send extra default args to scripts, debugger implementation. Believe, manipulate modules is more simple than strings.
3. Memory Leak
   • When implementing classes inside Scripter, we can have this scenario:
     
     Class with module
     
     Class without module
   • The first implementation shows that the garbage collector removed our Foo instance, but in the second image, it wasn't collected. Why? Exist a implicit cycle between _ _del_ _ and foo object, then python interpreter don't delete the object. In the module implementation, Python has a trick when modules end up, it will override all global values that do not begin with an underscore with None. That's a documented behavior.
4. Classes and function must be defined inside modules
   • That's an unwritten convention in python, but some modules (pickle, inspect, pkgutil, pydoc) from python will can't work properly and probably some module from PyQt also (I had problems with QDialog subclass).

Article from flask creator with more details here

These two plugin mentioned in D6210 need GUI Mockup.

1. Canvas Size
   • It's just a a widget to load document and then resizes canvas to each selected document.

2. Filter Manager
   • I'm intending to do that filter manager plugin like a filter management tool.
   • Tree Sctructure
   • You can select a filter from a node or document and apply it for a list of document or specific Nodes in one document.
   • Maybe, it shows the thumbnails to Nodes and documents.

Mockup to Canvas resize

@rempt

I need to extend Document with offset properties and change resizeImage to accept x and y parameters (like QRect). What do you think?

Yes, that sounds good. I wonder whether the dialog shouldn't look more like the Resize Canvas dialog, but I have to admit I never understood the Anchor option myself, and, in any case, when going over multiple images, that probably doesn't make sense.

It's common to resize from different anchors, as a more precise alternative to cropping (which currently doesn't support snapping or fine-tuning of the size). When you apply resize canvas in batch, that's what it becomes: your crop tool. Cropping images in batch isn't so common, but it is something you'll use in games/web/graphic design every now and then. You probably won't need it for painting/comics though.

Simple scripts to duplicate and export an image to jpeg or png. You can see some examples to setup your own config.

Script to export all layers

• Export to pre-defined formats (jpeg or png).
• All layers are exported in the selected format.
• Group layers are converted to directories.
• The scripts works for the activeDocument.
• You can change GLOBAL variables: XRES, YRES, BASE_DIR and FORMAT.
• If the directories already exist, they are not created.
• batchmode to that operation is working.