Bugs - Ok I need some Help

I made 2 bug python report bugs and no one believes me they are bugs… How can I prove it is a a Bug without question?

Can you link the bug reports here. The bugs should be reproducible and the behavior should not be intentional for it to be classified as a bug by the developers.

I will not give the link. it could come off as some sort of personal attack to people.

Reproduciable… check
what do you mean by intentional?

well I made a script and addon with it:

  • on the script it DOES NOT work
  • on the addon it DOES work

and BOTH have the SAME CODE!

but because of the UI I managed to make it work on the addon. And that proves the reported BUG. However it is ignored because they don’t check both in contrast nor the results of the code for what it should be doing in essence.

The problem is that things work individually but not together.

Do you mean that the bug is not confirmed or any developers have not yet responded to it? If this is the case then the developers simple may not have seen your bug report and had time to respond.

You can also log in to IRC to ask questions about this behavior and understand the devs point of view or convince them your point of view :slight_smile:

They have responded, after checking it. their response is that it is not a Bug.
That is why I made this post to ask for advice to actually see what I can do to expose the bug better.

Since it is Python I made scripts to show but I think they totally missed the point of it.
How to show it is not just bad coding from my part? and it is indeed a Bug?

Truth is that was I trying to make a simple operation but all paths to do it seem to have different bugs.
However I managed to make a addon that works in the most stupid way possible, and I must say I am kinda ashamed of its existence as it is currently.

They game me some advice but it did not work clearly :expressionless:

the IRC still works? I thought it was closed

yup the IRC channel is gone by the looks of it

It is not linked on the website but it is still there,

join from here - https://kiwiirc.com/nextclient/irc.freenode.net change the channel to #krita

1 Like

Thank you @raghukamath, I will try and see if I can talk to someone there.

on another note I wrote a really short sample script of what I think is ONE of the problems.

 # Import Krita
from krita import *

# Krita
ki = Krita.instance()
ad = ki.activeDocument()

# Make a Selection
ss = Selection()
ss.select(50, 50, 1000, 1000, 255)
ad.setSelection(ss)

# Stupid bug example
ki.action('add_new_paint_layer').trigger()
ki.action('activateNextLayer').trigger()  # should swap layer with this command
ki.action('clear').trigger()
ki.action('deselect').trigger()

just need to open a image file (jpg or png) with no layers to test it. Run it and and it creates a new layer, it tries to swap layer with the “activateNextLayer” command and then delete what is inside the selection. however having the active next layer command or not there is irrelevant as it always acts as if it is not there so you always have the same result. But if you run the activate next layer command isolated it works but never when you have it alongside with other commands.

Does this look like a bug or am I seeing things where they are not?

I was just at the IRC and it seems the code works on their end perfectly…however various pcs on my end don’t. I don’t get it :\

Guys. I’m sorry for writing here. I have signed up to forums for a single question about Krita but somehow I’m not allowed to create a topic. And there is no other way to contact Krita etc. Sooo, what am I suppose to do now? :smiley:

if this is not a Bug I dont know what is really

Hi @EyeOdin

On my side, there’s 2 case:

  1. Using the appimage of Krita 4.3.0-beta1, I can reproduce your example and I agree about the fact that it doesn’t work as it should: the active layer stay unchanged after call to ki.action('activateNextLayer').trigger()
  2. Using the nightly appimage of Krita (last one I downloaded: git 5a643ab), everything is working fine (but need to use ad.waitForDone())

Looking the bug report, you’ve informed that bug is detected in Krita 4.2.8
I didn’t tested on my side if I have it or not with Krita 4.2.8 but there’s maybe a lack of communication between you and developers:

  • Developer(s) may didn’t care about the ‘old’ 4.2.8 version and have tested the case on last nightly build and it should have informed you that the problem doesn’t appear with last version built from repository)
  • I quickly read the bug report, and I have to say that I’m not able to determinate if the bug is talking about the activated layer or the mirroring tool (maybe I’m wrong because I read it quickly, it seems that 2 problems are reported in the same bug report… :thinking:)
  • The last thing is, mmh, don’t take it badly, maybe it’s just my english that is not good enough, but the employed tone in reported bug seems to be a little bit aggressive :roll_eyes:

I agree that PyKrita scripting API are not working pretty well (I myself already saw some bugs and expect for more available functionalities through provided API) and should/can be improved but I think there’s too few developers in team to allow to work on all bugs/features, and currently I think that plugin scripting is not the priority because there’s not very much users that use it (the fact is, bugs&features relatives to drawing are naturally more important because I think 99.99% of users are waiting for them, and, finally Krita is a drawing software and these functionality are the core of Krita :wink: )

Can you try the lasted nightly build and give me a feedback about the bug, if it’s still here or not?

Grum999

I knew I was not imagining things. At least someone \o/ can see it! Thank You for Checking it!

So that is why they dismissed it so quickly? At first I was told it was my pc but after testing it in 4 pcs with various OS, it was hard to believe it to be the case.
Yes have been waiting for response on this since 4.2.8. in order to continue. I upgraded to 4.2.9 too and still had the same results so it was still a valid bug. Until I guess the nightly build now? I will need to check that too.

The addon/script was made to correct a mirror tools asynchrony. It can happen if you do a transform or something else on just one side manually. Then the addon reacts to active user selections or NOT, hence all the “width/2” talk, that was just talk about scrapped code on the script version and maybe a bad order of events, since it was calibrated to work on my faulty version?
Both addon and script had the same exact code and one worked and the other didn’t. The 2 buttons on the addon literally bypassed the python lock and proved that the bug was real.

Yeah … I have been waiting for a good couple of months to try and make this script happen including the subquent bug responses that I was forced into, it seems all paths to do the same don’t work for various reasons, and this script should have been by far the most simple one I have attempted.
The other bug I reported had even had video footage too prove it’s validity due to it’s similar nature. It too had a sort of “dismissal”. I did not bother with it since they kinda saw it, but considering this second time it was going on the same path but not even recognized, it did not felt right since actions feel more essential for python now, considering how short it is currently.
I do apologize for my outburst and the way I spoke about it.

I do agree on all of that considering the team, what they want to do and what people expect. But from my perspective is dismissal of a bug is worse than taking a really long time to fix it. It is not like a bug will go away if you ignore it long enough, unless you wish to ignore it on purpose for some reason. You can do what you will it I was just reporting it’s validity since it is reproducible.

for May 15, I tested:

  • 2.8.3 Beta
  • Nightly Build #959 Pre-Alpha
  • Nightly Build #745 Beta

for the windows portable version, since it is my normal OS. The behavior is still consistently wrong on all versions. Don’t know what to say. Maybe the nightly build on Linux has something different that works better?

I am just happy someone else checked that it is actually true and is not me doing false claims around.

Wow…

Curious by nature, I’ve downloaded the last nigthly build #744 (git f9f3d94) and… yes, bug came back! :dizzy_face:

So, I tried again with the nightly build #741 (git 5a643ab ) because I was wondering if I had dreamed the bug fix, and no, there’s no bug…

Tried to look commits between #741 and #744, there’s nothing (from my point of view) that can justify why bug came back.

And finally after many tests, I’m starting to enter in an insane state :crazy_face:
Tried nightly build #741, #742, #743 and #744
On all versions:

  • I’m sometime able to reproduce bug
  • I’m sometime able to execute script without any bug

Unfortunately, I’m currently not able to determinate precisely what is the thing that made the script working or not :roll_eyes:

The only thing I can recommend for now is, rather than using action command to manipulate nodes, is to try to use Node API directly…
That’s a little bit frustrating but this is a workaround that should work (I hope) in all case (exception: if API change…)

from krita import *

def next(layerNode):
    if layerNode is None:
        return None

    if isinstance(layerNode, Node):
        returnNext = False
        for layer in layerNode.parentNode().childNodes():
            if returnNext:
                return layer
            elif layer == layerNode:
                returnNext = True

    return None



# Krita
ki = Krita.instance()
ad = ki.activeDocument()

# Make a Selection
ss = Selection()
ss.select(50, 50, 100, 100, 255)
ad.setSelection(ss)


ki.action('add_new_paint_layer').trigger()
ad.waitForDone()

# in replacement of: ki.action('activateNextLayer').trigger()
next(ad.activeNode())

ki.action('clear').trigger()
ad.waitForDone()
ki.action('deselect').trigger()
ad.waitForDone()

Grum999

well, that’s the thing, it must be a windows only bug then, because none of us can reproduce it on linux…

@wolthera
No no

I’m working on Linux and I can confirm that bug can be reproduced.

Now the difficulty is the bug can’t be reproduced systematically and I’m currently unable to determinate in which condition it occurs or do not occurs :anguished:

I already took more than 1h to do approximately 30 tests with different 4.3.0 build versions, and it made me crazy: it work, it don’t work, it work, it don’t work,… :woozy_face:
I stopped doing tests before being insane…

While the exact conditions for which it occurs/doesn’t occurs are not properly determinated, I agree that taking time to try to fix the bug will be wasted time: the pre-requisite to fix a bug is to be able to reproduce it and to know how to produce it.

Grum999

welcome to how I have been feeling the last couple of months trying to locate this.

however on my end it feels really consistent, as if it “just” works that way.

Well, I think it still might be somewhat caused by faulty multithreading at some point. That would make it strongly rely on timing, which could give the results of “sometimes yes, sometimes no”, depending on the current load of the CPU etc.

@EyeOdin @Grum999 can you please check if the script works if you add sleep() for 1s between every command? It will be executing very slowly, but should succeed I think. Then @EyeOdin you could try to remove as many sleep() calls as you can and see where is the first line you can put it which would guarantee the success. That would help debugging which command is the source of the issue. Of course that’s only if I’m right, but I think it’s worth checking :slight_smile:

something like this?

# Import Krita
from krita import *
import time

# Krita
ki = Krita.instance()
ad = ki.activeDocument()
# Make a Selection
ss = Selection()
ss.select(50, 50, 1000, 1000, 255)
ad.setSelection(ss)
time.sleep(5)

# Stupid bug example
ad.waitForDone()
ad.refreshProjection()
ki.action('add_new_paint_layer').trigger()
time.sleep(5)

ad.waitForDone()
ad.refreshProjection()
ki.action('activateNextLayer').trigger() # should swap layer with this command
time.sleep(5)

ad.waitForDone()
ad.refreshProjection()
ki.action('clear').trigger()
time.sleep(5)

ad.waitForDone()
ad.refreshProjection()
ki.action('deselect').trigger()

I noticed a display inconsistency on the versions I used:

  • on the 4.2.9 it would pass all the sleeps added and then suddenly show the final result.
  • on the nightly builds I could see the commands being applied one after the other as I waited for the sleeps.

however the sleep() command was not able to by pass it.
But I imagine that the nightly build is working far better because it helps with the undo stack I imagine.