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.)
yes! code reference @jayme
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.
@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).
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.
Resolving wontfix in favor of correcting, as in bug 86850 to make clipboard functions always available from context menu, even if inactive.
(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?
@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.
My bug and this bug are different. His mockup suggest combining paste and paste special into a single entry.
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.
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)
(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
(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.
"<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.
This one's in UX-Advise, so Status -> NEW.
(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.
(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.
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.
*** Bug 86033 has been marked as a duplicate of this bug. ***
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
(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.
Migrating Whiteboard tags to Keywords: (needsDevEval)
(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.
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.
** Please read this message in its entirety before responding **
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.
Please DO NOT
Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not
appropriate in this case)
If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/
2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword
Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!
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.
(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
> 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.