Known issues:

I noticed the icons created especially for the plugin do not support theming. So those have not been altered yet. I plan to tackle this issue but need to know how to determine the theme or alternatively prepare move theme suitable Scripter plugin icons to the core gamut of usable icons per theme. The issue icons are those in krita/plugins/python/scripter/icons/*.svg.

Hi,
Since I made most of the icons, I can take care of those too.

For run and stop, we can probably reuse some we already have:
either krita/pics/svg/light_animation_play.svg and _stop.svg (and the dark_ ones)
or krita/pics/Breeze-light/light_media-playback-start.svg and -stop.svg (and the ones in Breeze-dark)

debug_arrow could probably use one of the existing arrows.. would need to check where/how is it used.

For debug and step, I may also need a little more context to make them good (didn't have much occasion to play with scripter yet...)

Yes. I would like that. Since Krita already has such a good adaptive system for picking the right icon based on theme if we use that I think it can save us a lot of trouble in the future. How I have let the theme engine do most of the work is by using code like this

self.setIcon(Krita.instance().icon("document-save-as"))

It seems to work like a charm adapting automatically to whatever theme. I thank Boud for giving me that initial idea and explaining to me how the theming works.

@eliakinalmeida I agree with you. I do not really like this solution but I don't know better. I wonder why adding an action can come into a controller but any post initialisation cannot. If python had interfaces I would probably force every action class to implement an interface with that method. But that does not solve the problem you outlined. When I was trying to add the QFileSystemWatcher feature too I realised that with the current architecture I had absolutely no idea where to put it. Should it be part of the action should it be part of the document controller?

Probably first step is to find a more elegant solution for handling toolbars. Basically the uicontroller tackles a lot of stuff. Since it adds actions automatically and the addAction is also based on the list I thought that I would use the same list. Should we split up the ui controller too into constituent parts. Basically the uicontroller is not controlling the layout but primarily generating it. Qt seems to be doing the rest automatically under the hood. Also actions are already dependent on the uicontroller to run actions. Which is actually weird. I don't know if I understood correctly but it appears that the ui_scripter folder is sort of like the model for the ui components and uicontroller.py is like the view and controller combined.

In D11179#222241, @arvindpinto wrote:

Yes. I would like that. Since Krita already has such a good adaptive system for picking the right icon based on theme if we use that I think it can save us a lot of trouble in the future. How I have let the theme engine do most of the work is by using code like this

self.setIcon(Krita.instance().icon("document-save-as"))

It seems to work like a charm adapting automatically to whatever theme. I thank Boud for giving me that initial idea and explaining to me how the theming works.

@eliakinalmeida I agree with you. I do not really like this solution but I don't know better. I wonder why adding an action can come into a controller but any post initialisation cannot. If python had interfaces I would probably force every action class to implement an interface with that method. But that does not solve the problem you outlined. When I was trying to add the QFileSystemWatcher feature too I realised that with the current architecture I had absolutely no idea where to put it. Should it be part of the action should it be part of the document controller?

To be honest I've just didn't mind that possibility but I know how to implement in a easy way. The Scripter is based on microkernel architecture pattern. The SystemWatcher has to be in the document controller and that emits a notification to GUI, if the user confirms then you reload the document.

Probably first step is to find a more elegant solution for handling toolbars. Basically the uicontroller tackles a lot of stuff. Since it adds actions automatically and the addAction is also based on the list I thought that I would use the same list. Should we split up the ui controller too into constituent parts. Basically the uicontroller is not controlling the layout but primarily generating it. Qt seems to be doing the rest automatically under the hood. Also actions are already dependent on the uicontroller to run actions. Which is actually weird. I don't know if I understood correctly but it appears that the ui_scripter folder is sort of like the model for the ui components and uicontroller.py is like the view and controller combined.

I liked your idea, we can keep in touch and you can send reviews to that thread .