In Powerpoint, the predefined fields in Powerpoint Slide Schemes allow the user to edit by clicking anywhere on the Text boxes. The same holds true for Google Slides. In Impress, to start typing in the predefined fields in Impress Slide Schemes, the user as to expressly hit the line saying "Click to Type" and it selects the whole Text box to move it around if you press anywhere else in the Bpx. Consider that: 1 - The main purpose of the predefined Text Boxes is to write inside them. Right now starting to type is a secondary action if it requires a double click or to aim at the "Click Here to Write line" to start typing, 2 - It's harder for users of Impress to start performing the main purpose of the Text Box by aiming at a text line than to just press anywhere in the Text Box (except borders) and start typing. To move the Box around/resize/rotate, it's enough to select the borders (that's a secondary action taken on a text box - granted that hit area on the borders could be slightly increased), 3 - The Office suites most used by common users and businesses (MS Office Powerpoint and GDocs Slides) do it that way by default. It decreases the adaptation difficulty to Impress by changing this behaviour to something closer to those two Office suites.
Solution could be to protect the master field position (Format > Object and Shape > Position or F4 or context menu Position) but checking this option in the master slide is not taken into the presentation. Second part of the issue is hit test area (also reported to be a problem for bullets https://design.blog.documentfoundation.org/2017/10/28/impress-lists/, see copy/paste). White space is not accepted here but should be as the object content. Two issues, IMHO, up to devs to decide.
Isn't this really just a duplicate of bug 116342, and has been corrected? In a draw/impress document newly instantiated from template, Text Boxes are now editable by clicking/focusing at any location. =-ref-= http://cgit.freedesktop.org/libreoffice/core/commit/?id=d799436414ab7e28b6bf9a918fd3779b3fc85008 *** This bug has been marked as a duplicate of bug 116342 ***
Not a dupe. Based on discussion on IRC and testing Powerpoint, Samuel recommended Pedro to create this ticket.
Hmm, so Samuel's Text box single click selectable change does move object focus to the Text box frame, but edit cursor focus only happens if the cursor is positioned over the text. Guess one could make the case that click anywhere in the Text box frame, should also position an active edit cursor there.
(In reply to V Stuart Foote from comment #4) > Hmm, so Samuel's Text box single click selectable change does move object > focus to the Text box frame, but edit cursor focus only happens if the > cursor is positioned over the text. > > Guess one could make the case that click anywhere in the Text box frame, > should also position an active edit cursor there. This current report was the result of Samuel checking Powerpoint's behaviour - PP switches focus to input on single click only with the pre-existing text boxes. It's a balancing act between wanting to move/select text boxes you create yourself vs. wanting to input stuff to largely immobile boxes. The hit area of our box borders is notoriously small and that is one factor to take into account. We should make the area bigger anyway, though...
*** Bug 104091 has been marked as a duplicate of this bug. ***
So do you guys think that this is easily doable? It would be a nice change...
(In reply to Pedro from comment #7) > So do you guys think that this is easily doable? Likely not because I'd expect spaghetti code that also affect all framed objects. Maybe Armin can provide code pointers.
Yeah. Damn spaghetti code. :/ It would be nice to disentangle these issues to make LO more UX friendly though. However, the effort to fix this in the code is probably a long-term effort.
This would make a good 100 paper cuts subproject.
Go for it!! I can point open a couple of other bugs in Impress and point you to a Calc bug that could arguably be included as well if you are interested.
** 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
Still in LO 7.2.0.0.alpha0+ (066799b4a162aa0a4bc6aa28339f1f943a13971e).
Dear Pedro, 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
Here's a change on how this could be achieved, I've decided to not to follow through with this patch. https://gerrit.libreoffice.org/c/core/+/154510