Don't draw updates for tiny movements

endStroke() was returning early because it expect a stroke to be in progress. I think this is fixed now.

Terminate strokes correctly

Should be fixed by rKRITA6e51b8a32162

Anyone have a chance to review this?

Hi @kamathraghavendra - could you comment out lines 114 and 117 in kis_input_manager_p.cpp? #if defined(Q_OS_WIN)

Taking over with rKRITAd2706d879ca345e56465465ff8046a943c60173e

Hi Scott - there was something like this in the 2.9 code, I pushed a patch that uses an existing function ignoringQtCursorEvents() which right now just tracks the same thing as the variable isTabletEventStarted.

I don't know anything about this except that it's apparently Linux specific?

Unfortunately this patch doesn't solve @kamathraghavendra's problem. It seems like of a "no-op" as far as the inputmanager logic is concerned, but it could also randomly break something. I'd rather land something that fixes the problem, or perhaps make a bigger change...

In D930#20248, @rempt wrote:

Hm, even with git blame it's hard to figure out why these lines are here. But I'm not sure I even understand the input manager at this point.

This new version adds a toggle for the preview in addition to a toggle for the guideline. In other words, it is now possible to toggle each of them separately. The names are changed in the UI to reflect this distinction. The new default is to have both the preview and the guideline turned on.

Hi Dmitry - you're right, I missed the existing option for a guideline decoration, so I removed that from the patch.

Fix comment in stroke update compressor

Add code to make redraws prettier

This appears to be happening in the linux platform code.

I can pop this into the Krita repo for future use, since the tests are becoming re-enabled.

Rebase onto Krita repo

In T948#18716, @woltherav wrote:

In T948#18576, @abrahams wrote:

This particular task was related to changing the things in "Settings -> Configure Shortcuts." Right now there is a choice of default, paint tool sai, and photoshop. The idea was to add a reworked "krita 3.0 default" and change the current defaults to "classic." But since shortcuts can be shared now, perhaps it would be better to wait for users to redesign shortcuts on their own and start a discussion in the future.

Combining the two existing shortcut systems is separate thing which would be far more messy and unpleasant. (It would be another big refactoring of the XMLGUI code. I tried to start on it and got vertigo.) Instead of doing that, I think a more easily achievable design would be to simply move Krita's "Configure Shortcuts" dialog into a page in the "Configure Krita" menu.

Well, the reason why the 3.0 default stayed back is because this is really something that needs to be discussed with artists, live. Which means that we either would get it done at LGW or the big Krita Sprint. And I think we'll spent at the least 5 hours on it, even if we prepare.

This particular task was related to changing the things in "Settings -> Configure Shortcuts." Right now there is a choice of default, paint tool sai, and photoshop. The idea was to add a reworked "krita 3.0 default" and change the current defaults to "classic." But since shortcuts can be shared now, perhaps it would be better to wait for users to redesign shortcuts on their own and start a discussion in the future.

I'm stepping back with my contributions and I don't have a great desire to push forward with this any more. Unless someone else would like to take the lead on changing Krita's defaults in the near future I will close this task.

I think I mentioned this a few times on IRC but forgot to write it down here: I am holding off on this until the Lazy Brush is finished, since the methods used in that tool will be very useful for implementing a new magnetic lasso.

You're right, I forgot the change had to be added to both the path tool and path selection tool separately.

In D930#17973, @kamathraghavendra wrote:

@abrahams I tested this and unfortunately the issue persists. I also did a clean build but it didn't help.

All the libs refactoring means it would be easier to do this over from scratch.

@kamathraghavendra Could you review this patch with arc patch D930 or just by commenting out those two lines of code and seeing if it fixes your problem?

Yay!

It's still working as expected for me on Linux and Windows. Are you using a right-click with your mouse or with a tablet side button?

I think Messages.sh will have to be updated to reflect the new location of this script.

Ah, interesting, I think I see where the problem is coming from. There are a few places in the log like this. It seems the popup causes an extra "Enter" event, which messes things up.

Patch is here:

@kamathraghavendra Is there any chance you could record a tablet log of this behavior? I actually removed the old fix 17ea12afc530e1bc5137880b91c99f07fa73e856 following dmitryK's rewrite of the tablet code since it didn't seem necessary anymore (and I think it broke something else), but now I don't know exactly how the input event sequence on your machine looks.

I made a fresh Windows build.. my tablet log is not similar to that one in the slightest. I have no idea what is making that tablet data look so crazy. @rempt, did you apply the patch disabling Qt builtin tablet support to the Windows release? (I am assuming you did since the log looks kinda OK, but I don't know what else could be different.) Also what version of Qt are you building with?

Builds fine on Windows!

I wrote a tablet log analyser in Julia this evening. Here's a plot of the first stroke. Looks like some points are right on top of each other. It is very strange to me how few events have any decimals in the hires coordinates, because in my log almost all numbers include some decimal precision.

Just change those to std::ceil, std::floor?

This happens with pre-alpha but not with stable?

This is my first attempt at writing QML. I was not sure of how to idiomatically call methods in the TimerView subobject from the Main.qml Plasmoid. I used signal opacityNeedsReset() and signal digitHasChanged() and connected them to slots in the subobject. The plasmoid seems to work as expected, and bug https://bugs.kde.org/show_bug.cgi?id=353090 is fixed.

Update copyright year

Seems like the new blending mode works as described - it is a bit of a strange effect when painting over one color with another though, perhaps some tweak to the algorithm would do a better job with mixing colors? I also notice the white halos bordering strokes.