Bug 84177 - Context menu: “Paste Special” should be combined with “Paste”
Summary: Context menu: “Paste Special” should be combined with “Paste”
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
4.4.0.0.alpha0+ Master
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsDevEval
: 86033 (view as bug list)
Depends on:
Blocks: Context-Menu Paste
  Show dependency treegraph
 
Reported: 2014-09-22 10:33 UTC by Adolfo Jayme
Modified: 2019-07-16 21:27 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:


Attachments
Writer right-click menu on empty clipboard (6.17 KB, image/png)
2014-09-22 10:33 UTC, Adolfo Jayme
Details
Split menu mock-up (7.74 KB, image/png)
2014-10-23 14:27 UTC, Adolfo Jayme
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Adolfo Jayme 2014-09-22 10:33:54 UTC
Created attachment 106668 [details]
Writer right-click menu on empty clipboard

The newly-added Paste Special option doesn’t disappear when the clipboard is empty. In the attached screenshot, note that the good old Paste command is not displayed at all in this case, so Paste Special should not be visible as well, for consistency.

(Already mentioned over bug 62947, but let’s file separate bug reports please.)
Comment 1 bavincen 2014-09-22 11:26:46 UTC
yes! code reference @jayme
Comment 2 Adolfo Jayme 2014-10-23 14:27:56 UTC
Created attachment 108300 [details]
Split menu mock-up

Sorry for not replying earlier.

I can’t provide you with code pointers because I’m not a developer.

I had another idea: rather than having a separate “Paste Special” menu item, let’s make the existing “Paste” item have the “Paste Special” submenu you added. But the thing here is that Paste should still be clickable. Exactly the same behavior as split buttons in toolbars. See the attachment for how it would look ideally.
Comment 3 Yousuf Philips (jay) (retired) 2014-12-02 01:11:09 UTC
@bavincen: I believe Menu::RemoveDisabledEntries() in vcl/source/window/menu.cxx needs to be tweaked to remove the submenu entry after it cycles through a submenu and all of those entries have been removed.

It would be great that if you are able to fix this issue in that function, that you could also tweak the function to not remove clipboard functions found in the MN_CLIPBOARDFUNCS menu entry found in sfx2/source/menu/menu.src (bug 86850).
Comment 4 Yousuf Philips (jay) (retired) 2014-12-02 01:21:27 UTC
I think alternatively, if you set the HelpId to CMD_SID_PASTE_SPECIAL for the SID_MENU_PASTE_SPECIAL submenu, that might be the simplest solution.
Comment 5 V Stuart Foote 2014-12-18 22:17:09 UTC
Resolving wontfix in favor of correcting, as in bug 86850 to make clipboard functions always available from context menu, even if inactive.
Comment 6 Adolfo Jayme 2014-12-19 01:01:17 UTC
(In reply to V Stuart Foote from comment #5)
> Resolving wontfix in favor of correcting, as in bug 86850 to make clipboard
> functions always available from context menu, even if inactive.

Whaaaaaaaat!? That is… dumb! Why would I want a context menu having cluttering inactive items?
Comment 7 V Stuart Foote 2014-12-19 02:23:25 UTC
@Adolfo, no sense in two open issues at cross purposes. Closing this Resolved Wontfix as it is to hide just the paste special, while the other is to always expose the full set of clipboard tools.

Any discussion over on bug 86850, comment and discussion there please--placed on the Design hangout pad.

Stuart
Comment 8 Yousuf Philips (jay) (retired) 2014-12-20 07:39:41 UTC
My bug and this bug are different. His mockup suggest combining paste and paste special into a single entry.
Comment 9 Yousuf Philips (jay) (retired) 2014-12-20 07:41:52 UTC
If the combining of the two entries into a single entry is to go forward, a solution for calc's 'Paste Only' submenu should also be addressed.
Comment 10 Cor Nouws 2014-12-21 19:16:36 UTC
Note that in a least one other case the behaviour is that the submenu shows the text in grey "<No selection available>" 
(Context menu of a shape when only one is selected)
Comment 11 Cor Nouws 2014-12-21 19:17:10 UTC
(In reply to Cor Nouws from comment #10)

> (Context menu of a shape when only one is selected)

Context menu of a shape entry Group when only one is selected
Comment 12 Yousuf Philips (jay) (retired) 2014-12-21 19:45:56 UTC
(In reply to Cor Nouws from comment #10)
> Note that in a least one other case the behaviour is that the submenu shows
> the text in grey "<No selection available>" 
> (Context menu of a shape when only one is selected)

Yes this is correct with the shape context menu entries for alignment and group.
Comment 13 m.a.riosv 2014-12-21 22:58:05 UTC
"<No selection available>"
It's for me a very useful information, showing the user what is happening.
What do we gain hiding it?.
IMMHO Paste or Paste special must show the information.
Comment 14 Robinson Tryon (qubit) 2014-12-22 06:04:00 UTC
This one's in UX-Advise, so Status -> NEW.
Comment 15 Adolfo Jayme 2014-12-22 13:28:00 UTC
(In reply to m.a.riosv from comment #13)
It’s redundant to have two paste-related items in the same menu. And it’ll be very obvious that you can’t paste when “Paste Special” is disabled in the combined menu I show in the mock-up.
Comment 16 m.a.riosv 2014-12-24 00:38:18 UTC
(In reply to Adolfo Jayme from comment #15)
> (In reply to m.a.riosv from comment #13)
> It’s redundant to have two paste-related items in the same menu. And it’ll
> be very obvious that you can’t paste when “Paste Special” is disabled in the
> combined menu I show in the mock-up.

"Paste _OR_ Paste special", at least one showing the comment.

Often what is very obvious for us it's not so obvious for others.

Sometimes this information it's useful, e.g. when having problems with copy+paste, not so strange doing it between different applications

OTOH how people knows the reason for disappearance.

Modify the items list also not very friendly, and it is not how Menus work. Making it behave as the menus do, greyed out the item, I think is the right way.
Comment 17 Yousuf Philips (jay) (retired) 2014-12-25 08:45:05 UTC
Tried different combinations that i thought would work like i had mentioned in comment 4 but that didnt work to hide the folder when paste special isnt accessible. :D.
Comment 18 Adolfo Jayme 2015-06-20 16:14:02 UTC
*** Bug 86033 has been marked as a duplicate of this bug. ***
Comment 19 Dr. Goddard 2015-07-21 19:09:48 UTC
When doing academic or technical work it is necessary to quote from various sources.  Many publications require that a specific font and format be  used.  This requires the use of "paste without formatting" be an option.  having the:
-- edit menu achieved witha right click -- to offer this under Paste Special would greatly improve efficiency.  

This would make "LibreOffice Writer" and "LibreOffice Calc" work the same way making for better efficiency and be more efficient than having to:
-- find the edit menu and then 
-- paste special and then 
-- paste without fomatting
Comment 20 V Stuart Foote 2015-07-21 19:45:26 UTC
(In reply to Dr. Goddard from comment #19)
> When doing academic or technical work it is necessary to quote from various
> sources.  Many publications require that a specific font and format be 
> used.  This requires the use of "paste without formatting" be an option. 
> having the:
> -- edit menu achieved witha right click -- to offer this under Paste Special
> would greatly improve efficiency.  

Already implemented for 4.4 and the 5.0 release for bug 62947. 

There is a Paste, and also a Paste Special combo button with "Unformatted text" (which receives "Default Style" formatting when inserted, but can be easily formatted as needed), and the More options button launching a Paste Special dialog.

This somewhat related issue is about GUI change to merge Paste Special with a Paste combo button.
Comment 21 Robinson Tryon (qubit) 2015-12-13 11:21:15 UTC Comment hidden (obsolete)
Comment 22 Maxim Monastirsky 2016-01-25 13:26:55 UTC
(In reply to Adolfo Jayme from comment #2)
> I had another idea: rather than having a separate “Paste Special” menu item,
> let’s make the existing “Paste” item have the “Paste Special” submenu you
> added. But the thing here is that Paste should still be clickable. Exactly
> the same behavior as split buttons in toolbars.
Nice idea, but there is one big problem with this (and other non-trivial manipulations to context menus), namely OS X. Unlike other platforms where we use our own implementation of menus + some OS specific theming, on OS X we use _real_ native menus, so anything implemented for our own implementation doesn't affect menus under OS X at all. For those who didn't notice - even seemingly trivial thing as forcing some disabled item to be visible like in Bug 86850, actually doesn't work under OS X (and I'm not sure it will be easily possible to make it work). Another example is Bug 86138.

So everyone should be very careful when doing any changes to how menus work.
Comment 23 Xisco Faulí 2017-09-11 08:22:51 UTC
Dear developer,
This bug has been in ASSIGNED status for more than 3 months without any activity. Resetting it to NEW.
Please assigned it back to yourself if you're still working on this.
Comment 24 QA Administrators 2018-09-12 02:37:45 UTC Comment hidden (obsolete)
Comment 25 andreas_k 2019-04-18 08:03:41 UTC
As "Paste" ans "Paste Special" are separate in Menubar, context menu and I don't know where. I don't see an big advantage of combine them into one command.

For me this bug can also be closed as WFM.
Comment 26 Cor Nouws 2019-06-07 13:52:17 UTC
(In reply to andreas_k from comment #25)
> As "Paste" ans "Paste Special" are separate in Menubar, context menu and I
> don't know where. I don't see an big advantage of combine them into one
> command.
> 
> For me this bug can also be closed as WFM.
The initial description of the bug was "Paste Special shouldn’t appear in context menu when there’s nothing to paste"
That makes more sense to me.