its getting triggered. It works perfectly when it gets connected to theme change event.
I’m still working on how to make sure it gets connected to that when I have the docker already loaded and open at krita start. I have added a check in canvasChange to make sure it connected to themeChange.
Ok next plugin that I now can’t work without, xD Amazing! Thank you! ^^
Feature request: It would be great if it had Reload Original Preset button and Update State button.
It’s maybe not a perfect solution but would help UX a bit
I’ll investigate adding those - Reload Original Preset is under Brush Tip so i’ll look into that one. I was experimenting with themes and icon this week.
The plugin has reach it’s limit in terms of solving some of the bugs that come with it.
i.e. it has tendency to reset a number of things such as blending mode, opacity of the brush etc… when toggling.
it frustrates me how it’s perfect for what I need except for the little things that my programming I can’t solve anymore.
Hey
Sad news, I also experience lag when this plugin is active.
I was thinking that the cause of that might be extensive traversing of the whole Qt’s Widget node tree?
Most likely. I don’t have hardware with less ram to test out the performance. in the virtual machine linux it was working well at 8gb but i think it was not indicative of its performance in actual hardware.
It’s why I hope to make it native one day- atleast within this year.
UPDATE ***
V.0.1.4 have been merge to master. works for both 5.1 and 5.2 pre-alpha nightly
Icons have been added,
Icon only interface is now possible.
Fade label on fade slider have been remove to accommodate thinner layout.
Some bugfix - the ones I can fix (Some are … really i think i need a full different approach to mend).
edit:
I forgot to add - it works with light themes.
Other things:
I tried adding the action for resetting preset. for some reason adding my loadState() function after to load the state, doesnt… work.
my test code - loadstate just works after switching brush, this even if I remove that line that checks for brush and even if It clearly runs the code the state it check doesnt seem to reflect the actual state.
test on vm
fedora at 8gb ram → unworkable stutters.
linux mint at 8gb ran → runs smoothly
fedora at 16gb → kinda works
I think this will be the last update [outside of maybe bugfix]
– i have started working on krita code itself
I have achieved what I wanted and envision the plugin to be.
I check the new version on Fedora 37, Krita 5.1.5 App Image. Im not really sure if its plasma spin. By Virtual Machine. @16gb ram. All toggles works and activate.
yes , i know this for awhile now - listed under known bugs.
This is one reason i want to make this native.
I discover this bug not only from my plugin but other krita actions.
I tried to mitigate it by re-assigning the size but sometimes that does not work. I concluded that it have something to do on how the brush engine handle changes and at this point doing it native will probably be part of the solution.
I will check again , the code and see if I can do some more adjustment to minimize it.
Question: Is this plug-in already officially usable? I’ve wanted a tool like this for a long time. So as not to switch to editing after every brush strokeln.