Description: The area in which the text-edit-mode would be triggered is very big. This is good, if the user wants to change text, but it's frustrating, when a rotated text box should be grabbed. The attached video tries to grab the textbox, but will only enter text-edit-mode Steps to Reproduce: (1) Create text box (shortcut: F2). (2) rotate it by 45 degrees. (3) Try to grab the textbox on the top border in the middle. Actual Results: (4) Enter edit-text-mode Expected Results: (4) Grab text box. Reproducible: Always User Profile Reset: No Additional Info:
Created attachment 153336 [details] MKV video demonstrating the problem
UX TEAM, should the handlers be bigger for the cases ?
Have you seen the cursor turning into the four NSWE arrows (or whatever your theme shows)? There are other reports where users do not want to click on the object but go into it to start editing. So I wouldn't mess up with the hotzone.
Topic was on the agenda for the design meeting. Although no further comments, I still wouldn't mess up with the hotzone / selection area.
Created attachment 155995 [details] Video/Audio showing/explaining grabbin problems with a rotated text box
Please see the video I attached. In the first reference image, you can see where my cursor would turn into "NSWE arrows". I hope you can also get a clear picture of the fact, that the handling is kind of confusing in general (exceeding the explainatinos of #Description)
I understand your wish. But as comment in c3, the cursor is responsive and you see where clicking the object is possible. There is always a trade-off between easy getting into the edit mode and selecting the object. I recommend to not change it.
The default in Draw/Impress is, that the property "Allow quick editing" is on. Help says about it, "If on, you can edit text immediately after clicking a text object. If off, you must double-click to edit text.". If the default behavior is not comfortable for you, turn it off. You find the setting in Tools > Options > Draw > General or as icon in the toolbar "Options". Please try, whether this solves you problem.
Created attachment 156058 [details] Shows hotzones for grab/edit mode of rotated text box. Further, shows one example, where the behavior becomes problematic.
Please see the Attachment of #Comment9 > There is always a trade-off between easy getting into the edit mode and selecting the object. > "Allow quick editing" Both is not what I'm concerned about. Initially I wasn't aware of the concrete hot zones, so I went the wrong way with my description. I'm concerned about the fact, that the respective hotzones do not make sense to a user (imo). Especially not, if the actual hotzones and the hotzones shown on screen differ. Thinking about it, this is rather a bug, than a enhancement in my opinion.
Created attachment 160147 [details] Test file I confirm the weird hit areas as illustrated in attachment 156058 [details] Arch Linux 64-bit Version: 7.0.0.0.alpha0+ Build ID: 623d6cf06ccba392c1993a3b0ad271d508205e73 CPU threads: 8; OS: Linux 5.6; UI render: default; VCL: kf5; Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US Calc: threaded Built on 29 April 2020
Dear DarkTrick, 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 https://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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug