Copy paste within a frame bugs #414

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… Separate 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”.

** I know this is an enhancement, but think allowing so many permutations open to the user, will make it very difficult to squash the bugs.

My mistake these two were supposed to be separated. I agree with the above.

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.

(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 permutations 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…

I’m not sure if I’ve looked at the copy/paste code in depth, but a clipboard class/object doesn’t sound like a bad idea to me.