First thoughts about questions being asked to artists:

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.

calculating backgrounds for raster borders happens when the user requests, maybe?

Why do we have to calculate them at all? We have generator layers, and they are generated only once (with some color-space-related complications). Can we just reuse them?

Ping @rempt @dkazakov - hi, could either of you read through the "Current ideas" section of the task and see if it makes sense from the development point of view? I mean I'm sure it's doable, but whether it's a good enough idea? I want to ask for further feedback on KA, and then start implementing, and of course details of the plan can change at any moment (specifically, I want to figure out how to simplify it without sacrificing too much of usability), but I need to know if the foundation of the idea is okay (especially the Panel Layer idea and the "binding" of points in vector shapes).

@Deevad I do intend to do this "modular design", yes :) Knife tool is one of the most important parts I plan to do actually. It's present even in Medibang. It's so basic and so useful that it just must be done.

It's not only about the database schema though. For example, one of the recent changes in the database schema was adding the "active" column in resources_tags database. So, if someone uses the current stable nightly to tag and untag resources, and would go back to before that change, the column would disappear, right? So then all tag-resources pair would denote that the resource is tagged, even though the user untagged it. And there can be other unforeseen now issues in the future.

My conclusion from research for now is that Medibang's comic panels are way too underwhelming, and CSP's code architects know what they're doing. I was surprised they made the comic panels layer into a group layer ("folder") but it makes perfect sense, and even more sense in Krita: group layers have their own projection, and they calculate it from the children + the backdrop. There is nothing there that says they couldn't first draw the backsides of the frames, then the frame content, then the borders. Or that it couldn't cut the content from outside of the frames.

We shouldn't write fragile code to support going back a version

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

I closed the task because the Reference Images Docker has been removed and the Reference Images Tool has been implemented, with all of the features that are mentioned here. The followup (with new features for the reference images tool) is in https://phabricator.kde.org/T14490 and https://invent.kde.org/graphics/krita/-/merge_requests/901

I think the learning materials should be separate from communities... but in any case, for learning materials scripting.krita.org is a must.

@rempt Do you want this behaviour for both embedded and linked resources? From the user point of view, there is hardly a difference there, and I've seen that embedded resources can be loaded from the global resource interface to save the memory, so I guess you'd want it for both.

I was thinking about this issue. It's a bit complex; I agree with Dmitry there is an issue, I disagree that putting a version number in the filename would solve it completely though. I don't think we can solve it, really, at least without user input, which might've been a bit annoying... so I'd suggest just trying to make sure *it doesn't happen*. It's not trivial, but might be easier and more stable than other solutions. (Except for UUID, which we cannot pursue at this point).

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.

Hi @timotheegiet I'm not sure if the new icon is necessary or not. The new icon for measure tool might or might not help - I'd need to test it, probably. It seems to be able to improve the situation.

I guess that what's really biting us here is that we do not map this relationship in the database and in the bundle to begin with.

I'd say addResource should be renamed updateResource, and we need a createResource and importResource method.

A hyperlink to a webpage with instructions on how to get ffmpeg - One of the big issues people have with ffmpeg is that it is too confusing for people on where or how to get it. We would check their OS and send them to a simple guide that should be simple enough for even a fresh windows user can follow.

Shouldn't we close this? We have a list of things to do in https://docs.krita.org/en/untranslatable_pages/release_krita.html ?

Can we close this now? It's implmented here: https://invent.kde.org/graphics/krita/-/commit/5c458e1250237ee864451ec804c155a889d712bc and it's nicely working now: https://krita-artists.org/t/sneak-peak-on-the-new-search-feature-in-krita/20046

Great work, thanks!

Damn repeating threads... in any case, here: https://krita-artists.org/t/resource-manager-mockup-updated-design-december-2020/4413/37 the same solution was suggested, even with a mockup: https://krita-artists.org/uploads/default/original/3X/3/4/348cbaf1ba9c1eb3ab4e8f1585c4c7a6dfe7cbb8.jpeg

I think a simpler way of thinking about removal from a tag would be to allow users to remove by dragging anywhere outside of the right-hand side tagged resource view. This is usually a pretty intuitive UI/UX way of describing removal, and moving the tagged resource into the left hand side seems unnecessary since you're not really "adding" it to that specific view. To make it clear what it's going to do, IIRC you can change the icon of the QDrag once the user drags the resource outside of the tagged resource box. I hope that makes sense, it's a bit hard to describe in words...

Video showing the alternative version of the multiple resources view: https://krita-artists.org/uploads/default/original/3X/d/5/d5bbedf1d1bb88702b7981a61efdb0d2df7ab7b2.webm