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.

If I am going to collect layout code links anyway:

Turns out Unicode's ICU also has a text-layout component that integrates with harfbuzz and is apparently used by firefox and libreoffice. (I might be wrong, and these two might only be using the bidi and text-segmentation components)
https://unicode-org.github.io/icu/userguide/layoutengine/paragraph.html
https://unicode-org.github.io/icu-docs/apidoc/released/icu4c/classicu_1_1ParagraphLayout.html

The two ideas (flexibility in adding tool instances vs tool presets) are not the same, though there are places where they touch. I still haven't got a better solution for saving tool config settings than the one in my merge request for tool presets.

Now when I think about it, the feature might be overlapping with the "tool presets" feature. People might start using them as presets for the tool options, e.g. Stabilized liner vs Sketch pencil. So it should be taken into account as well [0].

After reading Deevad I'm convinced this can provide value to all krita users. as for the points in the original post:

Web-platform tests for SVG:
https://github.com/web-platform-tests/wpt/tree/master/svg

I very like this thread proposal because the feature really cover many scenarios. Custom icons in toolbar can stimulate the part of DIY in each artist. Investing time on their UI, their setup, sharing cool screenshot with funny custom tools icons, feeling more 'at home' on their own Krita setup.

https://www.w3.org/International/articles/ruby/markup
https://w3c.github.io/i18n-drafts/articles/ruby/styling.en.html

I think most affected users by this does their comparison with a certain model in mind. In my personal experience I wanted a way to get into a particular eraser preset in certain scenarios. I.E. for painting I did not needed a special preset as I used the eraser mode as a painting modifier. I do however needed a specific preset when cleaning while inking or adding depth in some painting styles.

Discussion on using Harfbuzz in javascript:

From what I understand they want to switch to last used eraser preset when they switch to the "Eraser tool" They are okay with having current brush turning into and eraser but they miss the feature where they can click the eraser tool and switch to the last used brush preset as eraser.

From what I understand they want to switch to last used eraser preset when they switch to the "Eraser tool" They are okay with having current brush turning into and eraser but they miss the feature where they can click the eraser tool and switch to the last used brush preset as eraser.

No, that really is the problem for people like Andreas Resch.

That won't satisfy the people who want to see an eraser tool in the toolbox...

That won't satisfy the people who want to see an eraser tool in the toolbox...

I have a feeling that giving "mutliple instances" for all the tools might be a bit of overcomplication. Especially in its definition, because it may be expected for tools to have different options in the "Tool Options" docker.

Text layout discussion by Ralph Levien, has a lot of useful links:

Some interesting observations about unittests here.

Text rendering in Krita on a 72dpi document, with left the text shape, and right the text-shapes converted to paths.

Ah, I think what you're missing is that QRawFont can give QPainterPaths for glyphs (we use it in textOutline), and I suggest that we always go through that, and use those paths to paint with the KoShapeBackgrounds, instead of making QTextLayout do it, as that one does not know about our KoShapeBackgrounds. I also want to have it not happen in KoTextShape, because it doesn't know the fills and strokes and whatever of the textchunk. It makes more sense to me to have the textchunks, which do know this info to handle that.

In particular, all non-image objects call the KoShapeBackground, which in turn draws their qpainterpath for them

resurrecting this old beast...

I like the new icon. Thanks!

After a little discussion on irc, I decided to update again the brush editor icon, here is how it looks:

hmm, that deevad's icon with gear like mechanics for the brush editor,
seems good for me. I think more people are used to that symbol to
understand that "they are going to change something." than an icon with a
couple of lines. That represent the brush editor .

👍 Super @timotheegiet !

Thanks @Deevad for the feedback.

📷 Snapshot docker
Thank you @timotheegiet for the icons on the snapshot docker, the change is very good!
I just read all the thread (and also updated my email setting; next time I hope I'll catch notification).

Ramon told me in PM he agrees with the change, and for him this icon "is a plane where we can locate the center easily using diagonals. that helps. so for me is helping me like an assistant"
So one more +1 for the new icon.

I feel like I would prefer the new assistant icon, tbh. At least they would be very distinct then, so the muscle memory will be easier. I'm not sure, but I think like the current changes are not enough... I know there are some other people with the same issue like me, for example Lynx3d, but I don't know how common it is.

@ramonmiranda @Deevad : can you please give your opinion about this question, as @tymond is also hesitating about it now:

Fixed in this MR: https://invent.kde.org/graphics/krita/-/merge_requests/772

@tymond ok, then I'll revert to the previous icon for now, and if it appears really needed I'll bring back the new one.