Hi everyone, is everything ok? I hope so.

Today, I will talk about my week working on Krita during this first week of the coding period.

1. Implement a new output widget to scripter

In the start I'm intending to implement just a "clear" action to the output widget, but I figure out that this behavior can happen in other moments. What is it? My widgets can have children and your children can have children... Sometimes, I need to communicate with then from a different widget through the uicontroller. Now, in the findWidget method, I need to send two arguments: root/parent widget (A widget registered in the uicontroller when the scripter starts) and the searched widget (optional). The second one must be a child of the root widget.

My implementation in a nutshell:

  • findWidget method improved
  • New OutputWidget with the clear action inside it.
  • ClearAction that clears the OutputTextWidget
  • I change the old OutputWidget to OutputTextWidget

Review D6057 and created and commit pushed to my remote branch.

2. Trying to discover a problem with Scripter’s debugger.

That's a problem that I figure out some weeks ago and promise to myself that I would implement that. I will try to explain that in a few words: It's HARD.

When I tested the debugger feature some time that was working properly to all Python/PyQt scripts, including some basic method from the Krita API. Someday, I resolve to test all the methods in the API and ... SURPRISE... some methods was not working properly, but why?.

I tested this method in the normal execution and everything was OK, so I told to my mentor about it and he said, it could be a problem in the SIP or C++ code, then I relax and I focused in my exams and GSoC proposal (yeah, I was approved xD).

When I was selected to GSoC, this problem was in my mind and I promise to myself that I would try to understand that.

The first thing to understand my problem is to understand how I implemented this feature, so I did this prints below.

GSOC

The action that starts the debugger, calls the "start" method in DebugController, create an object that represents the current debugger class and calls start method in the Debugger. You can see a snippet of the debugger class, showing the start method.

GSOC

If you understand a little about asyncio, you know that the line 90 is waiting a asyncronous call. I'm using async, because I don't know when the Queue in display is not empty.

I have another process running executes the Debugger class that innerits from bdb.Bdb. Everything is working well, exept for one thing: I can't writein shared objects(Krita objects). When I started this implementation, I didn't figure out that and now, I have a huge problem.

I did try to solve that using threading module, but when I use this another problem is created, because if we try to write in some object that's in use, we have a race condition(Nooooo) and resolve that, my friends, it's really awful :/.

I have some ideas to solve this using generators from python with yield to save a state from debugger session, but I will try this in the future, because I need to implement some plugins to YESTERDAY.

3. Planning to implement a generic plugin/script to setColorSpace

  • I will implement a script or plugin to setColorSpace where the parameters can be selected from the script.

  • I need do implement one method to each set of parameters in the C++/SIP API.

  • Implement a method to validate the join of this parameters

That’s it for now, until the next week. See ya!!