I am here for an opinion too. I would say yes to maybe having it in the shortcuts/right-click option when selecting multiple layers. I do not like it in the GUI though on the bottom of the layers docker.

Seems good to me

pushed out to the draft branch. Thanks for the quick review @woltherav

This patch currently does layer changing to get to the newly created mask, which is what would be overlapping with gdquest's situation. If we want the new mask to automatically activate, I will have to figure out a different way to automatically activate it. Currently in Krita switching to a different layer de-activates the transform tool boundaries

@dkazakov -- I think I understand your points. I think the video was meant to be for artists for them to help decide how they want this tool and functionality to work. The current functionality in stable is not how some artists want it. Maybe I can make a video to help communicate the different directions that the tool could go.

We might need a bit of discussion about both of these points to figure out what needs to happen.

With the group layers and the handles immedietly showing up...I noticed a group layer initially doesn't show the handles. If you select a child layer, then select the group layer again, it shows up.

I mostly just added a bit of logic to get the handles to show up faster. The issue with the handles not appearing instantly was because layer changes on the transform tool messes up the paint() from fully rendering.

did a bit more commenting and fixed the white space.

This is pushed out... It will be in master and in Krita 4.2

Just a note about that "work recursive" toggle on the tool options for the transform tool.

Updated logic with recursive mode and group layers. The added mask is skipped now in that situation

I took care of most of the points, so the the undo works now with it. I moved the function to the startStroke area as well. I also fixed a recent regression where transforming doesn't work on things like clone layers and vector layers.

Updated the diff a bit. Added another color filter on the end so it matches what we had before.

The wireframe alone is hard to tell how the workflow would be with this... I tried putting together a video with how it would work. I am not too good with video editing, so forgive the "popping" that happens with the onion skin docker.

Based off the video in the previous conversation, the animator is putting the previous frame and the next frame to the new in-between position so the two drawings overlap. I added to the wireframe the ability to add 2 reference frames. I think they should default to before and after frames.

some additional conversation (IRC) and video from FlameReaper on how he uses it....
https://drive.google.com/file/d/1CVooALeUVgMDG9WgQd-zNVe1a7EptIjA/view

Additional Reference:
Clip studio puts these in a separate area called light table layers: https://www.clip-studio.com/site/gd_en/csp/userguide/csp_userguide/577_animationcell_plt/577_animationcell_plt_ope.htm

just made these changes...closing this ticket.

Pushed out...closing

updated code to use enum instead of separate boolean values for fill type

I talked with @albertoefg about this ticket. He is ok with me finishing this guy off.

@albertoefg - Are you still working on this. If not, would you be ok if I took this patch over and finished it off. I think the patch is still pretty much yours, so you can still get the credit for it.

Everything looks fine to me

yes. Looks nice!

Good idea. I wonder if we can extract this logic and put it in a function to isolate what is going on. There is a lot math stuff going on with this file already, so I am always a little concerned that adding more math stuff is going to make this file even harder to understand if we don't try to organize/comment it more.

it seems fine to me.

I attached one idea for the tool options for the multi-brush.

@kamathraghavendra - I closed that ticket. That was a wishlist item to add the copy translate feature to begin with. The person that reported it was the same person that actually coded the feature. I think the UI idea on that ticket was to make a new popup to define the sub-brushes. I think we agreed that it was too disruptive...so we opted for adding the brushes right on the canvas and keep the options on the tool options.

Looks good to me

I think I updated all your points. I ended up refactoring the code so it is shared. Adding more if statements for the pixel grid was a bit sloppy for me, so I moved it all to a new calculation function that does that for the other areas to use later.

@dkazakov I think most of the issues are resolved except the disputable one.

👍 +1

I updated the logic so it tries to more intelligently calculate the width and height when you toggle the vertical and horizontal. I think this should fix the issue @dkazakov found.

Pushed and closing...

@woltherav @amedonosova I could be mistaken, but this is just adding another way to get to the arrange functions. The Arrange docker is not being removed, so people can still go to that to use that if they want icons and a GUI interface for doing the arrange operations. I don't see really any reason to have a conflict of interest with this. There are a lot of things in the application that have multiple ways to access them. People like options.

Updated the diff removing the extra logic and replacing it with a safe assert. Using the python, it seems ok and I don't get any errors or issues

forgot to close this.

closing this. I am not really working on it and it probably needs more discussion

@emmetoneill I am not sure what you are proposing exactly. Are you proposing that we remove the reference guide, general concepts, and tutorials area. Or are you proposing to move all that stuff into the user manual under a beginner, intermediate, and advanced areas. The way I am reading your comment, the "big picture" appears to only talk about the user manual. I don't see any references to our other areas like tutorials, reference manual, or general concepts areas and how those fit in.

@woltherav - alright, so you are thinking the user manual needs to do a couple things. Looking at a few pages, I see a pattern we might want to try to follow for all the areas in the user manual.

Closing this ticket. I am not working on this and I am not sure if there is a good way to get this data for krita.org to consume and show to people. We can look at it again if this comes up.

ahh. Looks nice!

That looks great to me

Great job anna!

To start off some discussion, here are a few questions I have with how this new site will fit in with everything else that we do...

Thanks for the review @rempt

I changed all the checks to return the document instead of the active view.

Thanks for the video. I think some other artists that might use this are going to need to speak up about how this will work. This whole idea seems a bit confusing to me that changing your colors in the toolbar doesn't actually change the colors. If this is exactly what the artists want, we can roll with it.

@rempt thanks for the reviews and help. Pushed out and closing this ticket.