Opened 12 years ago

Closed 9 years ago

Last modified 8 years ago

#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 12 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 12 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 11 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?

comment:4 Changed 9 years ago by godiard

  • Keywords 12.1.0 0.96 added

Patch sent to sugar-devel

comment:5 Changed 9 years ago by godiard

  • Keywords 0.96 removed
  • Milestone changed from 0.88 to 0.96

comment:6 Changed 9 years ago by godiard

  • Owner changed from tomeu to godiard
  • Status changed from new to assigned

comment:7 Changed 9 years ago by godiard

  • Resolution set to fixed
  • Status changed from assigned to closed

comment:8 Changed 8 years ago by dnarvaez

  • Milestone 0.96 deleted

Milestone 0.96 deleted

Note: See TracTickets for help on using tickets.