Context Navigation

← Previous Ticket
Next Ticket →

#1266 closed defect (fixed)

discrepancy of clipboard items and clipping cache

Reported by:	mikus	Owned by:	godiard
Priority:	Normal	Milestone:
Component:	Sugar	Version:	0.85.x
Severity:	Minor	Keywords:	12.1.0
Cc:		Distribution/OS:	Unspecified
Bug Status:	Assigned

Description

Test case (I used Terminal): [Latest occurrence was on soas-2-beta on an XO-1, but the problem occurs in earlier versions of Sugar as well.]

(1) Individually copy (one by one) a sequence of clippings "one" "two" "three" "four" "five" to the clipboard. Frame will show five icons, with "five" in the lower left corner, and the other icons above it in the left edge of Frame ("one" topmost).
(2) Click on "three" - this will select what gets to be pasted.
(3) Perform 'paste' (e.g., from within Terminal) and verify that what got copied out of the clipboard was clipping "three".
(4) In Frame, go to the icon for clipping "three". Click on 'Remove' in that icon's palette. Verify that Frame now shows four icons (called, from top to bottom, "one" "two" "four" five").
(5) Perform 'paste' (e.g., from within Terminal) and verify that what got copied out of the clipboard was still clipping "three".

To me, http://wiki.sugarlabs.org/go/Design_Team/Specifications/Clipboard is confusing:
(A) The text: "The paste operation will not change the selected source, such that subsequent pastes will repeatedly paste the same clipping" appears to prohibit changing the source of which clipping will be copied by a follow-on paste, even though the originally selected clipping might have in the meantime been explicitly removed from the clipboard.
(B) The text: "an alternate paste-and-remove operation will paste the currently selected source and remove the source clipping from the clipboard in one step. When the clipping is removed, the previous clipping (the one that was below it in the stack) will become the new source" appears to allow a 'Remove' to change which clipping gets selected as the source for a follow-on paste.

I believe that behavior (A) is actually a bug - it ought to be more important that Frame show the clippings that can be copied, than to preserve the (invisible!) repeatability of the previous paste operation.

When the selected clipping is removed from Frame, a different clipping needs to be selected. [In the test case, if "three" is the selected clipping, "two" ought to be automatically selected when "three" is removed.]
.

Change History (8)

comment:1 Changed 15 years ago by erikos

Bug Status changed from Unconfirmed to Assigned
Milestone changed from Unspecified by Release Team to 0.86
Priority changed from Unspecified by Maintainer to Normal
Summary changed from "remove clipboard clipping" (from Frame) can be confusing to discrepancy of clipboard items and clipping cache
Version changed from Unspecified to 0.85.x

I picked the bug from your description:

Steps to reproduce:
a) open Terminal
b) copy text
c) copy another text
d) remove text (c) from the clipboard
e) paste text into terminal ---> it is the text from (c)

comment:2 Changed 15 years ago by alsroot

Milestone changed from 0.86 to 0.88

Switch Milestone to 0.88, since we are in code freeze for 0.86.

comment:3 Changed 14 years ago by garycmartin

Distribution/OS changed from SoaS to Unspecified

Just tested again in latest Sugar 0.87.3, removing the currently selected clipping does not auto select a remaining clipping so you can still paste with the removed content. Selecting the latest clipping could be the simplest logic (or empty the buffer if no clippings are left). We're not in code freeze so perhaps this can still be considered a possible bug fix for 0.88?