After upgrading LibreOffice recently, I discovered that Text Boxes are missing their properties from the right-click menu. Steps to Reproduce: 1. In Writer or Impress, insert a Text Box or Shape 2. Type some text 3. Attempt to format the text by right clicking on the shape. Expected Results: You have the option "Text" to edit the objects attributes. Actual Results: In 5.2 this option is missing. In 4.4 and earlier this worked as expected. I can't imagine why an option that only appears when it's useful would be removed intentionally. If it was, this decision should be rethought as it only hurts productivity by burying relevant options deep in sub menus many clicks away.
Regression introduced in range https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=57997db73725583a84dbac36bcc9c1b2829948f9..d95d9d7f908419f397941ef60ac6ced3261c9b87
(In reply to Xisco Faulí from comment #1) > Regression introduced in range > https://cgit.freedesktop.org/libreoffice/core/log/ > ?qt=range&q=57997db73725583a84dbac36bcc9c1b2829948f9.. > d95d9d7f908419f397941ef60ac6ced3261c9b87 Well, this clearly points to my commit - https://cgit.freedesktop.org/libreoffice/core/commit/?id=447c313586e9b36acff393feae15f5e1b63861ae But the decision on what to include in the context menu made exclusively by the design team. In particular see Bug 81132, Bug 86606, and https://gerrit.libreoffice.org/20446/. @Joey: Since 5.2 it is possible to customize the context menu. Go to Tools > Customize..., switch to the Context Menus tab, and select the "Shape Text" menu from the dropdown. It will allow you to add back all the commands you need.
This appears to be a case of the developer saying, "It's not a bug, it's a feature", so I'll change this to an enhancement to request the old default functionality back. I understand that you offered a work-around, but there is absolutely no reason why this shouldn't be the default behavior. This was a context-sensitive item that only showed up where it was useful. So there really can be no argument for removing it to clean up the menus.
Heiko, Can you please discuss this in your design meetings? After upgrading from 4.4 to 5.2, I've found myself spending much more time digging through the menu system. There are several instances of features that used to be just one click way, which I now have to look up on the web or waste several minutes looking digging through menu after menu to locate. I filed this bug because I use text boxes heavily in my documents. If we don't restore the defaults, I'm sure other users will find the reduced functionality in the context-menus equally annoying. There is no upside to hiding context-aware properties like this one. In 2017, we shouldn't be going back to digging through menus like I did with 90's apps.
(In reply to Joey Reid from comment #0) > Steps to Reproduce: > 1. In Writer or Impress, insert a Text Box or Shape > 2. Type some text > 3. Attempt to format the text by right clicking on the shape. If you right-click on a textbox in Impress, the 'Text' entry is present, but yes its not there in writer, which should be corrected. The issue of shapes not have 'Text' in the context menu is discussed in bug 94448. Do note that 'Text' is available in the context menu when you are in edit mode of shapes or textboxes. (In reply to Maxim Monastirsky from comment #2) > Well, this clearly points to my commit - > https://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=447c313586e9b36acff393feae15f5e1b63861ae @Maxim: Writer only has a single 'Shapes' context menu for both shapes and textboxes, while Impress has a separate 'Text Box (drawing)' context menu. Was this overlooked when you did the conversion to xml?
@Joey: Regarding your comment in bug 81132 which is related to direct formatting entries removed from the context menu and nothing related to that bug report, i'll reply to it so others CCed on that bug report arent spammed with this discussion. (In reply to Joey Reid from comment #49) > I’m a little late the party here because I just upgraded to 5.2. While I > understand the arguments for cleaning up the context menu. You have gone too > far. After the upgrade, I find myself spending much more time digging > through menus. And worse yet, sometimes I have to Google features that were > once available in the context menu. Whatever features that were removed from the context menu in that bug report are available in formatting toolbar, so no need to go into the menus for them. > You have gone too far by removing features that are context sensitive. These > add no cutter because they were hidden except for when they are usable. I'm assuming the removed features you are talking about are the Text option for shapes and textboxes, or are there more? > All your analytics may show that a feature is only used .01% of the time. > But if you are one of those people that use the feature 100+ times in a > single document like I do Bug 107635, these stats are meaningless. For the .01% of users who require a feature to easily be available in the context menu, they have the ability to modify the context menu to their liking, just like we offer the same ability for toolbar and menus. We have to optimize all UI (toolbars, menus, context menus, etc) for the largest user base or else the UI will be worthless to all users. > I'm sure your stats are from basic non-professional users. The stats were gathered for a month from thousands of users of all proficiency levels who used OOo 3.1 in 2009. > Also, you are comparing Apples to Oranges with Word. LibreOffice lacks Word’s > mini popup toolbar that appears when you select text. Nope it wasnt an Apples to Oranges comparison with Word, as Word's mini popup toolbar isnt a context menu and it was created due a limitation in the Ribbon UI, that you could be on a Ribbon tab and have to switch back to the Home tab every time you had to access basic text formatting features. > MS Word only stripped down their context menu AFTER introducing the mini > popup toolbar. By copying their context menu without the toolbar, you have > just cause the UI to take a major step backwards. Completely false as the context menu in MS word has always been condensed. Here is Word 2003's (pre-mini popup toolbar) default context menu < http://www.worldlingo.com/en/images/xp1.gif >. Also we arent copying MS Word's context menu, as I analyzed the context menus of many competing office suites when i did the reorganization.
(In reply to Yousuf Philips (jay) from comment #5) > @Maxim: Writer only has a single 'Shapes' context menu for both shapes and > textboxes, while Impress has a separate 'Text Box (drawing)' context menu. Indeed. Impress/Draw have separate menu for each object type (curve, line, shape, connector etc.), while Writer/Calc reuse the same menu for everything. > Was this overlooked when you did the conversion to xml? No, it was always like that. My conversion was 1:1.
Created attachment 133222 [details] Word's Mini Toolbar is both context sensitive and shows up on right-click (In reply to Yousuf Philips (jay) from comment #6) > Nope it wasnt an Apples to Oranges comparison with Word, as Word's mini > popup toolbar isnt a context menu and it was created due a limitation in the > Ribbon UI, that you could be on a Ribbon tab and have to switch back to the > Home tab every time you had to access basic text formatting features. No, you are mistaken. The mini toolbar is for all intents and purposes a CONTEXT MENU. It's context sensitive, it shows up when the user right clicks, and it requires little mouse movement to reach. These are all qualities of context menus. You not including ALL the functions offered by Word after a right-click, made your comparison unfair. You made it easier to justify removing items that should not have been removed. I appreciate your effort to clean up the context menu, but for heavy context menu users like me, you have gone too far. Let's discuss them in other reports that I will file on a case by case basis. Sorry for my harsh tone earlier. I was annoyed to be told that this change was a feature and not a bug without any justification. Since you agree, the ‘Text’ entry should not have been removed, lets focus on getting this bug fixed.
(In reply to Maxim Monastirsky from comment #7) > No, it was always like that. My conversion was 1:1. Is the underlying contextual code for shapes and textboxes separate and they are just pulling from the same .xml, which would make pointing textboxes to a separate .xml file easy? (In reply to Joey Reid from comment #8) > No, you are mistaken. The mini toolbar is for all intents and purposes a > CONTEXT MENU. It is a contextual toolbar and not a contextual menu. https://en.wikipedia.org/wiki/Context_menu > It's context sensitive, it shows up when the user right > clicks, and it requires little mouse movement to reach. It shows up initially just on selection and is also presented on right-click. > These are all > qualities of context menus. You not including ALL the functions offered by > Word after a right-click, made your comparison unfair. You made it easier to > justify removing items that should not have been removed. Well that is your opinion, which i dont agree with. > I appreciate your effort to clean up the context menu, but for heavy context > menu users like me, you have gone too far. Let's discuss them in other > reports that I will file on a case by case basis. As a heavy context menu user, i dont agree with your opinion. Will gladly comment on any new bugs you file, but wont be getting into a back and forth discussion unless others in the UX/design team agree with your suggestion. > Sorry for my harsh tone earlier. I was annoyed to be told that this change > was a feature and not a bug without any justification. Since you agree, the > ‘Text’ entry should not have been removed, lets focus on getting this bug > fixed. Yes it was a feature to have it remove from shapes, which unfortunately had a negative effect on textboxes, which hopefully we can resolve in this bug report.
** 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! Warm Regards, QA Team MassPing-UntouchedBug
Andreas, please take this into account. And check the meta ticket as well.
Bug will be fixed with the change discussed in BUG 119596. I already had it into account and yes I'll check all the other contextmenu bugs.
Hi I add in master text context menu styles support to text in writer and calc. So you can style text, paragraph, table, ... with right click without any code change. I think it's a good plan and the right way to go. On my todo list support for shape styles, colors, ... are planned, but therefore styles support has to get some improvement. Recent Styles would be also nice.
If possible I'd like to close this bug and have the styles support as written in BUG 121108
I also would close this bug. I compared 6.2 with 3.3 and couldn't find a context menu item that I miss now. The 3.3 menu was a mess and formatting is now additionally available through sidebar. If commands are needed, the Customize dialog can help too. The mini-toolbar feature is covered by bug 119707.