Created attachment 89446 [details] Screenshot Hello, I think most of us use the context menu for cut/copy/paste operations very frequently. However, these items on the context menu are located at the very bottom; therefore making it harder/longer to reach these options. IMHO, it would make sense to move these buttons higher to the top of the context menu, so that they would be easily reachable. Would love to hear your opinions as well. Best regards, Emir
Agreed. Your screenshot even shows a context menu that lists negative* actions (i.e. “Delete” & “Clear direct formatting”) before the positive ones, which is incorrect. --- * as in that they remove content/formatting.
I agree with you, I also think it should be in the top if the context menu below the pointer and below if the context menu is above the pointer. What do you think?
Created attachment 89732 [details] pointer at the bottom
Created attachment 89733 [details] pointer at the top "pointer at the bottom" and "pointer at the top" to show the dynamic placement of cut-copy-paste on the context menu..
So when one uses the context menu lower on the screen, the menu shows above the mouse pointer, so the items are close. As is shown by the screen prints made by Ahmed. Now one could apply dynamic position, but I'm quite affraid that this will be confusing for many users... (difficult all those mouse issues for someone working with the keayboard most of the time ;) )
I actually never use the cut/copy/paste commands from the context menu but their keyboard shortcuts instead. But I do frequently use context sensitive commands from the context menu. I don't think that moving almost static elements (like cut/copy/paste) to the most prominent position (i.e. top of the menu) is actually helpful. For me it would mean that I always would have to skip three entries that I don't use anyway, which certainly isn't an enhancement (well, for me ...), in case of Calc it's even five entries including Paste Special and Paste Only.
(In reply to comment #6) > I actually never use the cut/copy/paste commands from the context menu but > their keyboard shortcuts instead. Alas it's amazong how many people do not use Ctrl+C/V usw.. But of course I agree with you (at least in my heart ♥ )
I also do not use this context menu much, but when selecting text and there is need to copy/paste, this is where context menu comes in handy.
Since the verify first time i used libreoffice, i found this to be a weird behaviour as cut, copy, paste and also paste special [bug 62947] should be the first items in the menu, as they are the most frequently used feature in the right-click context menu. But i simply added this thought to my list of enhancements, which i planned to submit after 4.3 was released. But now that i've gone through the statistics from OOo's tracking stats < https://wiki.openoffice.org/wiki/Tracking_results >, i think it is crucial to do it immediately. Here is the top 10 used entries from writer's right-click menu 1. Paste - 1,119,606 * 2. Copy - 592,585 * 3. Cut - 225,137 * 4. Picture - 47,078 5. Paragraph - 41,302 6. Clear Formatting - 30,401 7. Remove Hyperlink - 29,392 8. Table - 21,493 9. Character - 20,466 10. Page - 16,921 And here are writer's keyboard shortcut stats 1. Paste - 1,471,565 3. Copy - 784,925 6. Cut - 223,061 ??. Paste Special - 17,280 And here are writer's menu bar stats 5. Paste - 194,828 6. Copy - 125,028 16. Cut - 42,855 ??. Paste Special - 32,600 And here are writer's toolbar stats 17. Copy - 77,717 22. Cut - 58,903 ??. Paste Special - 205 ??. Paste - 8 (this must be wrong) And here is calc's right-click menu stats 1. Paste - 924,525 2. Copy - 654,339 6. Cut - 163,492 8. Paste Special - 74,035 You can see in ever instance (except for the clearly incorrect toolbar stats), its always Paste, Copy and Cut. After looking over ms word's ribbon UI, you can see that the first button in the main/home toolbar is a large paste button, with small cut and copy icon next to it. Thats how much emphasis microsoft knows that it needs. < http://www.baycongroup.com/word2007/images/01_Word2007Screen.gif >
Sounds like a slam-dunk to me. Unfortunately popup menus are not nearly as trivial to edit as you might hope - there is no nice XML stuff; it is all resource file blather with things like this: class SwReadOnlyPopup : public PopupMenu Menu MN_READONLY_POPUP { ItemList = { MenuItem { Identifier = MN_READONLY_OPENURL ; HelpId = CMD_SID_OPENDOC ; Text [ en-US ] = "~Open" ; }; ... SEPARATOR MenuItem { Identifier = MN_READONLY_COPY ; HelpId = CMD_SID_COPY; Text [ en-US ] = "~Copy" ; }; }; Though that guy should be easy to move 'Copy' to the top of the menu (for readonly documents) - finding the other more generic bits is perhaps harder: sfx2/source/menu/menu.hrc:#define MN_CLIPBOARDFUNCS RID_SFX_MENU_START+1 sfx2/source/menu/menu.src:Menu MN_CLIPBOARDFUNCS sfx2/source/menu/mnumgr.cxx: PopupMenu aPop( SfxResId( MN_CLIPBOARDFUNCS ) ); sfx2/source/menu/mnumgr.cxx: PopupMenu aPop( SfxResId( MN_CLIPBOARDFUNCS ) ); is one place that might be useful. Indeed - reading that it looks quite promising: SfxPopupMenuManager* SfxPopupMenuManager::Popup( const ResId& rResId, SfxViewFrame* pFrame,const Point& rPoint, Window* pWindow ) { -seems- to insert these items into menus that don't have them =) and it always does it at the end; that should be ~trivial to change this to the beginning - even a beginner can do that =) cf. include/vcl/menu.hxx: void InsertSeparator( const OString &rIdent = OString(), sal_uInt16 nPos = MENU_APPEND ); We need to provide an nPos of zero (ONO) for the insertion of those items and ... bingo =) => an easy hack.
Was hoping that context menus would be trivial, as it was my plan to propose a reorganizing of them after my work on the toolbars. I guess converting the context menu code so that it would be easily editable by means of XML would also be alot of work. Well i guess i'll limit my right-click suggestions to this bug, paste special bug [bug 62947] and the formatting options removal bug [bug 81132].
Hello all, I am a fairly new programmer (CS major in second year of college at the moment) and was wanting to jump into LibreOffice development for fun and to gain some experience. This bug, along with other "easy hacks", seemed like a great place to start. I was wondering if anyone could advise me where to start playing around with this bug or to just tell me that it is too challenging of a fix and send me on my way to hunt down another bug. Thanks!
Note: it turns out that void SfxPopupMenuManager::ExecutePopup(...) is the method that seems to actually make the difference (based on testing my fix)
Just submitted a fix for this.
Jeffrey Stedfast committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=3f8e114bae8bb3ef45a08ced3434e7a9669ed4f9 fdo#71770 Fixed Cut/Copy/Paste popup menu items to appear at the top The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Yay! Thank you!
*** Bug 75103 has been marked as a duplicate of this bug. ***
Thanks Jeffrey for submitting the patch. This fixes the issue in all apps except Calc, as they still appear at the bottom.
Please do not reopen bugs like this. File a new one instead.
My apologize. I thought when a patch goes through that didnt fix the bug completely that it the bug report should be reopened. I've opened the Calc bug at bug 84293.
I tested it right now with LO 4.4.0.0.beta1. Was this deliberately not also implemented in CALC?
This bug fix comes with LibreOffice 4.4 (release notes https://wiki.documentfoundation.org/ReleaseNotes/4.4) Cut, Copy and Paste actions are now at the top of the context menu.
Migrating Whiteboard tags to Keywords: (EasyHack DifficultyBeginner SkillCpp TopicCleanup) [NinjaEdit]