So, conceptually, we divide that GlobalRect into smaller contiguous, non-overlaping, regions or tiles

Hello everybody. My 2 cents are here. I give all the brave Krita users access to edit the document, coment and share. Enjoy and Help if you can ;)
https://drive.google.com/drive/folders/1UMTT6TumIXr0NurBf0rex7-podiQjxwH?usp=sharing

https://invent.kde.org/graphics/krita/-/merge_requests/1460

We've talked in the past about associating assistants with certain layers, but lately I've been thinking wondering if it would be possible to just treat individual assistants as a new type of node/layer.

scenerio 1) you want to make one single line or a bezier curve in a nice way and it’s done better with assistants, but to do that, you gotta go to the assistant tool, set it up, then move to the brush, enable snapping, then go to the assistant tool again to remove it -> how to make it faster/easier?

For scenenario 1, yes it is cumbersome to work with assistants that need constant adjustment, however this may not be a problem with the usage but the design of the assistant. For example, ruler is good but requires to be adjusted on every stroke to make new lines, on the contrary, parallel ruler needs less input as you can do all parallel lines at once. So first we have to design the functionality of assistants to be less dependant of user input. However this is not trivial to do. On the other hand, if we could have a key to quickly activate the edit options from the closest assistant that could help mitage this issue.

My thoughts/priorities regarding this task. (The subtitle says the priority, to make it easy I just assigned three, "Now", "Maybe now" and "Later").

For flowing text, I did have a small proposal couple years back. Unfortunately got busy with my own stuff, couldn't even participate in GSoC.

I've read it...

@woltherav I see... is there any plans on when that meeting will happen?

@knowzero : No clue. The problem is that we haven't had a post-5.0 meeting yet, and as far as I know only you and Alvin have read my report. I have literally no clue what is going to happen.

@woltherav - While I understand the need for rewriting the backend and moving away from QTextLayout. From the sound of things the on-canvas editing will take a while correct?

Re colour font, we already have a related bug report (sort of): https://bugs.kde.org/show_bug.cgi?id=439908

Ok, I've decided to write a report for everything I've learned. I hope we can use this as a basis for a proper meeting at some point:

Some updates on this:

Just a note from IRC:

Also the gamut mask controls are still missing, I don't really like the current way. There should be some way to choose the mask from the docker (has been requested a few times), I'm thinking of a popup/dropdown, and the angle control could be better integrated IMO.

I think we talked about moving the color history to Ko~/KisCanvasResourceProvider, but I haven't done that yet.