Last Comment Bug 41547 - Paste Special submenu needed - paste cells as Rows or Columns
: Paste Special submenu needed - paste cells as Rows or Columns
Status: NEW
[behavior][ui] (2 days)
:
Product: SeaMonkey
Classification: Client Software
Component: Composer (show other bugs)
: Trunk
: All All
: -- enhancement with 5 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
: 59115 (view as bug list)
Depends on: 73286
Blocks: 149043 83989 89323
  Show dependency treegraph
 
Reported: 2000-06-05 07:45 PDT by rubydoo123
Modified: 2012-02-28 12:10 PST (History)
10 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments

Description rubydoo123 2000-06-05 07:45:46 PDT
In Composer, under Edit, the Paste submenu is missing on win32 and mac builds
Comment 1 Charles Manske 2000-06-05 10:30:45 PDT
Do we agree on what should go into this menu?
My suggestion was to get the available clipboard formats and build a submenu
based on those.
Comment 2 rubydoo123 2000-06-06 16:03:23 PDT
this should actually be in future, I meant to do that when I submitted it.
Comment 3 rubydoo123 2000-10-26 06:20:36 PDT
Clarified Summary.

One special paste function should be 'paste > xxxxx selection order' or
something described like that, where xxxx could be any object. The point behind
this is to allow the user to paste the selected table cells, or list items (as
examples) in the order that they were selected.

So, if a user has a table like this:

a   b
c   d

they can select 'a' 'c' 'b' 'd' and get a resulting paste of:

a
c
b
d

not, what they would currently get:
a
b
c
d
Comment 4 Kathleen Brade 2000-10-26 06:33:11 PDT
also, in a list, if a user drag-selects from the bottom to the top, I would want 
to be able to Paste-special a reversed list.
Comment 5 Simon Fraser 2000-10-26 10:23:00 PDT
Oh come on, you're being unrealistic now. Even beppe's suggestion is borderline, 
and pasting lists in reverse order makes no sense.
Comment 6 Simon Fraser 2000-10-26 10:33:47 PDT
Perhaps I should add that these kinds of features are candidates for whatever 
kind of implementation we use to replace Java plugins: pluggable JS transactions, 
perhaps?
Comment 7 rubydoo123 2000-11-07 09:25:16 PST
see bug 57292 and bug 58807
Comment 8 Charles Manske 2000-12-11 13:22:50 PST
This is very important when pasting table elements. We need to allow a user to
paste "As Columns", "As Rows" etc. when clipboard contains table cells.
I'll try to do this for 0.9 as part of table copy/paste work
Comment 9 Charles Manske 2001-01-02 18:17:45 PST
*** Bug 59115 has been marked as a duplicate of this bug. ***
Comment 10 Charles Manske 2001-01-02 18:18:07 PST
*** Bug 59115 has been marked as a duplicate of this bug. ***
Comment 11 Charles Manske 2001-01-02 18:20:03 PST
Updating summary to cover table issues.
Comment 12 robinf 2001-03-14 14:29:17 PST
Can you describe how this feature will work? Thanks.
Comment 13 Charles Manske 2001-03-15 15:46:47 PST
I think the basic table-pasting behavior should be:
Any original row/column relationships of cells in their source table is ignored,
unless the entire table was selected when copied to the clipboard.
[jfrancis: how can we determine that informtion?]
If that is true, then the paste will always be the complete original table.

So "Paste Special" options only apply when cells were selected, not the entire
table. Rules for pasting cells:
1. Cells are pasted in proper "bidi" order: Row-wise from left to right (for
"left" order, or right to left for "right" order), going from top row to bottom.

2. If pasting into a table with selected cells, replace each selected cell with
the cells found in the clipboard in the order they are encountered on the
clipboard.
Question: What to do if number of cells in
source is > number of selected cells? I vote we simply don't paste everything.

The Paste Special submenu would allow these options:
1. "Insert New table". User is prompted with a small dialog similar to
"Insert Table" so they can tell us how many columns and rows. A new table
is created and if pasting inside a table, it would be a nested table.
2. "Paste as Rows". Insert new rows, taking each cell from the source and
raveling them so the number of cells in each new row is same as table pasted
into (the destination table). When we run out of cells to paste, the current
row is automatically filled with empty cells to keep number of cells/row
balanced.
3. "Paste as Columns" is very similar, but creates new columns with
appropriate empty paddingcells to keep table structure.

Pasting as Rows or Columns is enabled only if pasting into an existing table,
of course, and also only if there are no selected cells in destination table.

4. Pasted cells retain the same attributes (background color, etc.) as they had
in the source *except* COLSPAN and ROWSPAN because that would create a nightmare
in figuring out how to paste! I suggest removing all COLSPAN, ROWSPAN in source
cells, but not, of course, if source is the entire table.


Comment 14 Kathleen Brade 2001-03-16 06:30:59 PST
In addition to all the table features Charley describes, Paste Special will also
show a list of all of the different kinds (flavors) of data on the clipboard.

For example, if you copy some cells from a spreadsheet, it might put the
following flavors on the system clipboard:
   * raw text
   * styled text (RTF?)
   * html
   * jpg image
   * bitmap image
   * internal/proprietary flavor

Of these, we could might list these in the Paste Special menu:
  * text
  * html
  * image

We probably would be pasting the data as html or text by default but if you
really wanted another flavor (like to get the image) then you could choose that
from this menu.

If the data is copied by us (in Navigator or Composer), we can also offer other
options like "selection order" or "column" or "row" as described above.

Robin--does that help?
Comment 15 Charles Manske 2001-03-23 18:34:59 PST
I am doing all UI and table-related work. Brade is more expert for D&D and
clipboard matters and will help with clipboard flavors issues.
Comment 16 rubydoo123 2001-04-03 16:49:12 PDT
moving to mozilla1.0
Comment 17 Charles Manske 2001-05-14 10:13:22 PDT
Did we really intend to put this work off? All UI is done as a new "Save As"
submenu under top leve "Edit":
Text
Image
-----------
Row
Column
Table   (or "Nested Table" if selection is inside existing table)

Kathy: Is it that hard to detect the "text" vs "image" vs "html" on the
clipboard to do the firt 2 "Paste As" menu items?
If we don't do the table items (Row, Column, Table in "Paste As" submenu),
pasting into tables will be very poor: we would always have to paste as a nested
table, I guess.
Comment 18 Charles Manske 2001-05-14 13:13:16 PDT
Since UI is checked in, beppe said it's ok to work on this for 0.9.2 (0.9.1
would be even better) if we have the time.
Comment 19 Charles Manske 2001-06-01 08:56:47 PDT
We probably won't have time for this, so the task is to remove the "Paste As"
menuitem.
Comment 20 prass 2001-06-05 17:40:16 PDT
adding myself to cc list
Comment 21 Charles Manske 2001-06-06 15:21:34 PDT
Here's the patch to remove the menuitem:

Index: editorOverlay.xul
===================================================================
RCS file: /cvsroot/mozilla/editor/ui/composer/content/editorOverlay.xul,v
retrieving revision 1.177
diff -u -r1.177 editorOverlay.xul
--- editorOverlay.xul	2001/06/01 23:40:34	1.177
+++ editorOverlay.xul	2001/06/06 22:18:26
@@ -318,6 +318,7 @@
       <menuitem id="menu_cut"/>
       <menuitem id="menu_copy"/>
       <menuitem id="menu_paste"/>
+<!--
       <menu id="menu_pasteAs" label="&pasteAs.label;" 	
accesskey="&pasteAs.accesskey;">
         <menupopup oncreate="InitPasteAsMenu();">
           <menuitem id="menu_pasteText"    label="&pasteTextCmd.label;"
accesskey="&pasteText.accesskey;"/>
@@ -329,6 +330,7 @@
           <menuitem id="menu_pasteTable"
accesskey="&pasteTable.accesskey;"/>
         </menupopup>
       </menu>
+-->
       <menuitem id="menu_delete"/>
       <menuseparator id="edEditMenuSep2" />
       <menuitem id="menu_selectAll"/>

sr=kin

Comment 22 Asa Dotzler [:asa] 2001-06-07 11:55:58 PDT
a= asa@mozilla.org for checkin to the trunk.
(on behalf of drivers)
Comment 23 Charles Manske 2001-06-07 22:24:40 PDT
Removal of menuitem checked in. Implementation of feature move to next version.
Comment 24 wkfx2003-bugzilla 2001-08-13 19:41:05 PDT
My suggestion to paste selected cells would be the same shape as the source
Source
a b c
d e f
g h i
if I copy
e f 
h i
and I can paste as 
e f 
h i
Why do I want to change it to either column or row??? IMHO, it make no sense to
convert it.
Comment 25 Syd Logan 2001-09-12 13:35:52 PDT
spam composer change
Comment 26 Charles Manske 2001-11-28 17:59:18 PST
changing milestone
Comment 27 Syd Logan 2001-11-30 14:48:55 PST
Agree with EDITORBASE-, removing EDITORBASE designation
Comment 28 Charles Manske 2002-02-07 09:11:08 PST
changing milestone
Comment 29 Kathleen Brade 2002-02-28 12:35:04 PST
*** Bug 128309 has been marked as a duplicate of this bug. ***
Comment 30 Robert Kaiser 2009-06-14 07:13:29 PDT
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Comment 31 Robert Kaiser 2009-06-14 07:29:45 PDT
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Comment 32 Robert Kaiser 2009-06-14 07:41:50 PDT
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Comment 33 Robert Kaiser 2009-06-14 13:05:43 PDT
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Comment 34 Robert Kaiser 2009-06-14 17:21:27 PDT
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Comment 35 Robert Kaiser 2009-06-14 17:38:03 PDT
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Comment 36 Robert Kaiser 2009-06-14 17:40:10 PDT
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Comment 37 Mike 2010-01-17 05:23:57 PST
*** This bug has been confirmed by popular vote. ***

Note You need to log in before you can comment on or make changes to this bug.