bugPSPP - Bugs: bug #57274, Ctrl+V and Paste paste different...

 
 

bug #57274: Ctrl+V and Paste paste different things.

Submitter:  None
Submitted:  Wed 20 Nov 2019 04:30:48 AM UTC
   
 
Category:  Graphical User Interface Severity:  5 - Average
Status:  Fixed Assigned to:  beckmanf
Open/Closed:  Closed Release:  None
Effort:  0.00
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 18 Jul 2020 05:38:02 AM UTC, comment #11: 

I think we can call this one done now.

John Darrington <jmd>
Group administrator
Sat 11 Jul 2020 04:00:17 PM UTC, comment #10: 

I pushed your patch with a few minor alterations.

Let's give everything a good test run for a few days before we call this done.

John Darrington <jmd>
Group administrator
Sat 11 Jul 2020 11:27:27 AM UTC, comment #9: 

okay.

I will have another look at these issues and at your patches.

John Darrington <jmd>
Group administrator
Sat 11 Jul 2020 10:35:34 AM UTC, comment #8: 

comment #5:

> Note that, like Friedrich says, there is a slight difference in semantics between clicking once on a cell, and double clicking on it.  Clicking once selects the cell, whereas clicking twice selects the text within that cell.  This is the same behaviour as in spreadsheet programs such as Gnumeric, so I don't think it should be changed.


Yes, I agree. But as described in comment#6 the clipboard operations should not depend on how you trigger them.

Friedrich Beckmann <beckmanf>
Group Member
Sat 11 Jul 2020 10:20:22 AM UTC, comment #7: 

While I am writing you already make it happen. With commit

http://git.savannah.gnu.org/cgit/ssw.git/commit/?id=88258c239b5c6a7985a86bfbfcd512f0c49f64ff

you remove the newline at the end for a copy...

Friedrich Beckmann <beckmanf>
Group Member
Sat 11 Jul 2020 10:01:42 AM UTC, comment #6: 

The idea is that all three ways of doing Copy/Cut/Paste have the same effect. Without the patches the main menu and the key always work on the store and the context menu always works on the editable.

With the patches it is now distinguished if an editable is open or not. If an editable is open, then clipboard always works on the editable as you would expect it. The difference becomes obvious with the following test:

1. Create a string variable with width 12
2. Enter text "appletree" in the data view
3. Click twice on the cell to open the editable => blue frame appears
4. Select the letters "apple" from the text

Now compare (without patches)
5A. Copy via main menu or <CTRL>c  => appletree is in the clipboard
with
5B. Copy via context menu => apple is in the clipboard

6. Click once into an empty cell
7. Paste with <CTRL>v (or key or context)

Case (A) => appletree is in the new cell
Case (B) => apple is in the new cell

Expected behaviour: The selection was on the editable and there should be "apple" in the clipboard regardless how you copy.

With the patches it does not matter if you copy/paste/cut via main menu, key or context menu. It only matters if your focus is currently in an editable or not which is the behaviour that is compliant with usual gui behaviour. If you do "Cut" instead of "Copy", then in A the complete cell is deleted while in B only the text "apple". If you paste then the main menu and key always replace the complete text while paste via context inserts the clipboard at the current cursor position.

The behaviour in the description below "Pasting in the sheet" and "Pasting in the Cell Edit" is now consistent because you either open an editable or not. With commits

http://git.savannah.gnu.org/cgit/pspp.git/commit/?id=273fd32809f3e2ba6e98540966db0da221704c68 and
http://git.savannah.gnu.org/cgit/pspp.git/commit/?id=e7d38ad8abd34beaec3f9078c9ade9c422707a5c

the string in the editable is nearly already a valid number except that there is a "Newline" at the end of the "5.00". If you select a cell range and paste it into the open editable, then the text with tabs and newlines is pasted at the current cursor position. This results in an invalid number but that is at least obvious. It would also be compliant with user expectation because you are currently editing the text in the cell. While writing this and testing in psppire I noticed that Copy and Cut behave differently:

1. Create a numeric variable with default settings
2. Goto dataview
3. Enter 5.00 in the cell
4. Click once on the cell => no blue frame
5. "Copy" via <CTRL>c => 5.00<NEWLINE> is in the clipboard
6. "Cut" via <CTRL>x => 5.00 without NEWLINE is in the clipboard

So we could change the Copy behaviour such that for a single cell copy no NEWLINE is appended as in "Cut". Then pasting into an empty editable would result in the correct numeric value right away.

I think the unexpected and buggy behaviour is that clipboard operation behaves differently depending on how you trigger the clipboard action.


Friedrich Beckmann <beckmanf>
Group Member
Sat 11 Jul 2020 09:42:12 AM UTC, comment #5: 

I've pushed a number of changes (both to pspp and ssw) which together I think fixes the problem described in Comment #2.


Note that, like Friedrich says, there is a slight difference in semantics between clicking once on a cell, and double clicking on it.  Clicking once selects the cell, whereas clicking twice selects the text within that cell.  This is the same behaviour as in spreadsheet programs such as Gnumeric, so I don't think it should be changed.

John Darrington <jmd>
Group administrator
Sat 11 Jul 2020 05:30:20 AM UTC, comment #4: 

When I apply the provided patches, --- at a first glance --- I don't see any change in behaviour of the bug.  I'm also concerned that the sheet changes might have unexpected and undesirable side effects.

(I don't think we need to worry about the API change macros at this point.  So far as I'm aware pspp is the only user of ssw and
ssw is still only alpha)

John Darrington <jmd>
Group administrator
Wed 08 Jul 2020 12:45:57 PM UTC, comment #3: 

I fixed this with commit

http://git.savannah.gnu.org/cgit/pspp.git/commit/?id=475baffca930c4bdbd9db52139e30eb1c8e8604c

and two commits for ssw. I provide the ssw commits in branch clipboard here:

https://github.com/fredowski/ssw/commits/clipboard

The idea is that copy/cut/paste must target the editable in the sheet once a cell is focused. Then all clipboard actions via key, main menu and context menu yield the same result. I could fix the copy and paste with changes in ssw only but the cut operation was done solely in pspp without a ssw call. Cut only operates on the store. So I had to add an api function which tries to cut from the editable.

In order to have a mechanism to check if the additional ssw api function is available I added an ssw api version method. I can compile pspp vs the previous version of ssw and the cut operation does not end in a crash...

Friedrich Beckmann <beckmanf>
Group Member
Sat 27 Jun 2020 10:45:24 AM UTC, comment #2: 

I still cannot reproduce the problem in the value label dialog. But I see a problem in the data view window. To reproduce

=== Pasting in the sheet ===

  1. Open psppire
  2. Create three variable a, b, c, d
  3. Select the Data view window
  4. Create 4 cases by typing 5 <ENTER>, 6 <ENTER>, 7 <ENTER>, 8 <ENTER>
  5. Select cell "a 1" (only one click)
  6. Select in the menu Edit->Copy
  7. Select cell "b 1" (only one click)
  8. Paste via menu: Edit->Paste. This works: 5.00 appears in cell "b 1"
  9. Select cell "c 1"
  10. Paste via key "CTRL V". This works: 5.00 appears in cell "c 1"
  11. Select cell "d 1"
  12. Paste via Right mouse click context menu->Paste


=> The cell edit opens and 5.00 is inserted in the text field. Typing <ENTER> or clicking another cell or typing arrow keys will end the editing but the cell is empty. I can make it appear by deleting all text that is right of 5.00 in the text field and then typing <ENTER>.

=== Pasting in the Cell Edit ===

When I click twice a cell, the cell edit opens. To reproduce the difference

  1. Click twice on cell "b 2" => Cell Edit opens
  2. Paste via menu Edit->Paste
  3. Type <ENTER>. This works: 5.00 appears
  4. Click twice on cell "b 3" => Cell Edit opens
  5. Paste via key Ctrl+V
  6. Type <ENTER>. This works: 5.00 appears
  7. Paste Right mouse context menu->Paste
  8. Type <ENTER>


=> This results again in an empty cell

Somehow the pasting via Edit menu and keys reformats the edit cell such that only number string appears. I think Pasting via context menu keeps the spaces and the dot in the cell which results in a an invalid number string. Leaving edit then leaves an empty cell.

So the pasting via Edit menu and keys is identical and o.k. but the Right Key Context menu paste is different and not so o.k.

Friedrich Beckmann <beckmanf>
Group Member
Mon 01 Jun 2020 06:05:37 AM UTC, comment #1: 

I cannot reproduce this on pspp in master branch on commit e870838d34e5e0133 from June 1st 2020.

Friedrich Beckmann <beckmanf>
Group Member
Wed 20 Nov 2019 04:30:48 AM UTC, original submission:  

I am using PSPPIRE on Windows 10, installed from pspp-20181109-daily-64bits-setup.exe .

When setting Value Labels for a variable (from double-clicking on the Value Labels cell of that variable in Variable View) I am copying labels from a text file and pasting them into the 'Value Label' field for each numeric Value before clicking Add.

I soon noticed that (for instance) if I had previously pasted '+ITM2B', then even after I copied '+mPCSK1N' and could paste it in other text files with Ctrl+V, using Ctrl+V in PSPPIRE's Value Label field would instead paste '+ITM2B' again, no matter how many times I did Ctrl+V.

However, as soon as I right-clicked the Value Label field and selected Paste, it would past '+mPCSK1N' instead, after which Ctrl+V would consistently paste '+mPCSK1N' (even if I copied something different to the clipboard from a textbook).

I would greatly prefer Ctrl+V to behave the same way as Right-click + Paste, please!

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jmd (Posted a comment)
  • -email is unavailable- added by beckmanf (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-07-18 jmd StatusReady for Test/Review Fixed
        Open/ClosedOpen Closed
    2020-07-08 beckmanf StatusConfirmed Ready for Test/Review
        Assigned toNone beckmanf
    2020-06-27 beckmanf StatusCannot Reproduce Confirmed
    2020-06-01 beckmanf StatusNone Cannot Reproduce

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code