Possible immediate advantage for Scribus: @afarid mentioned Scribus uses Transifex. If I understand this right, this is proprietary subscription-based service. By joining KDE, Scribus could take advantage of our already existing translated corpus plus translator teams for more specific stuff

A guest stopped by the IRC to tell me that he wanted animation support for vector layers (and all layers).
I told him that I'm sure that's something many users want, though it's a big job and will have to come after improving traditional animation. =]

Adding some of @Bollebib's requests and suggestions from T7070, if still applicable.

Added a link to the animation feedback survey.

Yeah, that makes sense to me. Thank you for the feedback @hurgar, I'll add that to our list and we'll look into it.

Hi there,

For the in-progress one, you need to check out the MR that @scottpetrovic was working on: https://invent.kde.org/kde/krita/-/merge_requests/56 - note that most issues were fixed already

Added a draft outreach post: https://docs.google.com/document/d/1N9ZIRElBcJuZzMpHiTapoZnQEdebKIo9WizR_l2LK88/edit?usp=sharing

What I meant about the "animation cache is all broken" was bug 402841: Animation curve opacity doesn't display correctly during playback and sometimes during timeline scrolling https://bugs.kde.org/show_bug.cgi?id=402841

@tymond (or @dkazakov) About the animation caching system being broken, do we have a good idea / list of all things that need to be fixed for the animation cache, so I can pick it up from there?

Thanks @tymond. I've added those two points to the list.

My suggestions:

Sure , i will make it today.

Please make a merge request for the code you already have, so we could help you with the unittests part of the task :)

So, what should we do now? I'd like to get this project going forward again :-). Anything I can do?

For most of the places, I think there should be a unit test already there, nevertheless, could you just make a Merge Request on https://invent.kde.org/kde/krita

I have replaced KisSequentialIterator to KiFastDeveiceUtils::processTwoDevices. Can you please elaborate the unit test creating part?

Problems:

1. The final write should be atomic. That is, for the GUI thread the shapes can be observed either in the initial state or in the final state. No intermediate states should be observable (including during the write-back itself). 1.1) theoretically, it could be implemented by adding a lock to a shared d-pointer, but it doesn't guard from hierarchy action. 1.2) we could declare that locking the topmost shape would block hierarchy, but to get this topmost shape we should iterate through this hierarchy, which is unsafe
2. After the swap operation GUI thread might still have pointers to the old shapes that we replaced. How to fix that?
3. After swap operation, the shapes should emit some signals, so that layer's shape manager and other receivers get their notifications. How to postpone/duplicate these signals?

Heh, I was actually googling on how to get the PYQT_VERSION now we've updated to a newer PyQt... But even with these changes, I still get: