Implement Floating Selections for Pasting Operations

[ManuAros]

Bitmap layer. When selecting a area within a frame and choosing cut or copy you e.g. don't get to move what you cut out because as soon as you paste the object frame disappears and what you pasted "integrates" into the picture again.

In vector layer copy paste seems to have issues as well.

[JonasThomas]

I can take a look at this one as I just experienced it myself, unless @tasaif is already all over this one.

[tasaif]

I am currently not working on this one

[JonasThomas]

@tasaif @chchwy @feeef I'm starting to work on this one. I don't think I rights to self assign though

[feeef]

Ok @JonasThomas ! You need to ask @chchwy to add you as a developer to the project to be assigned.

[tasaif]

Sorry, I didn't mean to assign this to myself. I've removed myself from this issue.

[Jose-Moreno]

Guys, I've been seeing the task assignment issue is more present than ever since we have more than one developer now. Aside from the lead programmer assigning you to a task, do you guys think we should have a "secondary" task manager acting as roadmap of sorts? I've used Trello https://trello.com in the past for other projects since it's free. And we did talk briefly about this a few months ago, about establishing a roadmap. Would you like to discuss this in the forum?

[JonasThomas]

Jose I thought you just hung out on the forum ;)

[JonasThomas]

One thing I find interesting if that functionality works perfectly at this point if you use F6 to duplicated a frame and then move it on the new frame.. It seems the issue are within the same frame.. Ahhhhhhhh... down the rabbit hole we go....

[JonasThomas]

@chchwy @feeef @tasaif @Jose-Moreno
I was playing around this weekend trying to understand the problem before start coding away.. Some of the stuff I want to do changes some of the functionality somewhat and I wanted to make sure what I'm thinking is in line with Matt's vision on how the software should work.. Anyway.. My braindump is located here. http://www.metalshaperman.com/?p=2214 Is everyone ok, on what I view as the next step for this bug fix.

[tasaif]

@JonasThomas I've posted my response on your website. It says it require moderator approval and it looks like I can't go back to make changes to my response. Can you please move the discussion to the forum?

[JonasThomas]

Your Comments reposted here...
with comments to your comments posted here as **

Why isn’t this on the forum?

** I think the level of detail I go into would probably be too much for most forum members. They just want it to work. (major feature enhancement sure)

Following are my opinions on everything you’ve listed, please let me know if I missed anything or you’d like me to clarify anything.

Consistent way to recreate the bug

I think for the issue that you are working on it is important to scope the issue with care. I think that changes should be small and incremental. This specific bug should be resolved without including your proposed changes. In other words, the pull request should only have the changes required to fix that bug. The other changes should be in a separate issue/pull request.
++ On the same page..

File new

I think File new is really buggy in and of itself. It should be investigated fully on its own in a separate issue. The copy paste bug recreation steps should not include File new in them.
** +1 I don't want to focus on that at this point.. Seperate issue probably ok, (actually we should make this a sop that features/fixes are tested with File-new, File-open and as run and if it bombs create a new issue. (unless what's being worked on is so small it's no big deal to fix)

Cut/copy/paste enabling/disabling

I agree with you. I think this should have its own issue labeled as “enhancement”.
a modal message pops saying that you can’t do that from the pop-up menu.
I agree there should be a message. I don’t agree that it should be a pop up. It should be somewhere unobtrusive that doesn’t require interaction.
** I know this is an enhancement, but think allowing so many permutaions open to the user, will make it very difficult to squash the bugs. (If not a pop-up I'm open to suggestions... (I guess I'm too old school with the pop-up, but from my perspective its the best way to say don't do that...)
I'm almost wondering if there should be a separate object to route all the copy-paste ctrl-v,etc... so logic on behavior is in one spot (if it's agreed that this should be a next step, i need to do a little research to find out where everything is and figure out what makes the most sense.

Now in my mind when a paste if performed via a ctrl-v the copy should be placed where the mouse cursor resides (upper left corner)
I like this.
** we agree on this..

Whenever the selection is not visible, the clipboard is cleared.

I don’t agree with this. It is not default clipboard behavior.
** Well at this point when edit-select all is chosen it highlights the selection box only. I dont think this is standard behavior. There is some residual do-do that's not getting cleared out. This selection thing interacting with copy-paste doesn't to really causing some problems. I just felt this was a way to reduce some of the permuations of stuff that can go wrong. Not saying this is the best solution, but when I was just playing with the current build it made sense to me.. After I sleep on it, I might think its a stupid idea.

In closing, I’d like to say that each of the separated blocks above should theoretically have its own issue in the event that it is approved as opposed to one large pull request that contains all of the changes at once.
** yah, I didn't think so at first, but as I started digging into this things got complex.

** one things not addressed is that we should think about clipboard should follow the selection box.. Ctri-V or Edit-Paste the new item gets the selection box. (fI don't think the user will notice a difference, but I think it will keep program logic simpler...

[JonasThomas]

I guess need to research this stying with markdown... I thought ** would post as bold or something.

[Jose-Moreno]

Guys, I think there is a developer-only part of the Pencil2D forum. But I'll have to ask @gordielachance how to add you there, in case you guys want to have passionate discussions about complex stuff 👍

[tasaif]

I've moved the conversation to the forum, because it is a better conversation platform than github comments.

http://www.pencil2d.org/forums/topic/copy-paste-within-a-frame-bugs-414/

[feeef]

I fixed a bug with the selection tool where you could have a selected area that had no size. It seems copy pasting in the current frame works well for me now.
It is in the pull request #447

If you still get this issue, could you please indicate the exact steps to reproduce?

Thanks!

[JonasThomas]

@feeef I pulled #447 unto my laptop, Behavior is fixed in the bitmap mode, but I believe there is still some work to do in vector mode. In vector mode if you if you select a selection as soon release the mouse it reverts to a select all.

[JonasThomas]

I'm hoping this issue if fixed once the latest merge requests are integrated with the current master. I find this to be a very annoying bug that really needs squashed. (I'm thinking that feeef has fixed this and I don't want to trip over what he's done.. If not, I'm willing to give it a go..)

[ManuAros]

I'll test as soon as pr is complete so that I can build myself a new version. Looking forward to hitting hard on this annoying bug :)

[ManuAros]

It doesn't seem possible to copy and paste something in a frame. You can copy paste onto the object itself because you can see when you paste that the image outline "grows" when you paste, but you can't move what you just pasted.

[ManuAros]

Correction I managed to copy something if I moved the object away from the original spot before pasting but that's not very usable of course.

[Jose-Moreno]

[2019 Review] After re-reading all of the comments, I think more than a bug this is a very needed enhancement for the selection copy / paste behavior.

If we could paste specifically to "floating" selections (similar to GIMP) instead of pasting directly to the canvas (we could always have a toggle in case someone prefers either method) the users would be allowed to move these selections to improve upon their interaction with the tools and their own drawings.

The current workaround for this is to paste to a temporary keyframe or layer, move the selection however you want and then from that position paste it again to the correct layer and keyframe. This is obviously not ideal, and even more so when we consider each transformation is degrading the quality of the image.

Regarding the "bug" part, at least now, the selection does not disappear IF you maintain the select tool enabled. Even if you switch frames and duplicate or create a new keyframe, you can paste to the existing selection anytime what is saved in the clipboard, so that's a step forward to improve such behavior for pasting to floating selections.

[scribblemaniac]

Agreed, this is a very important enhancement. From an implementation perspective, what needs to happen is instead of pasting directly to the canvas, we make a new active selection, just like either the select or move tool (probably the move tool) does. Unfortunately right now the canvas painter, which is responsible for drawing the current view, tracks the selection rectangle (QRect) and the selection transformation (QTransform). I think Ideally it should store the selection rectangle as an untransformed QImage instead or in addition to the QRect, which would allow the copy and paste to easily be implemented by setting that QImage to the clipboard contents and then starting a selection transformation.

Some useful sections of the code to look at:

• SelectionManager This class is responsible for tracking the selection
• CanvasPainter::paintTransformedSelection(QPainter) This is where the active transformation is painted
• ScribbleArea This class calls CanvasPainter and passes it data from the SelectionManager.