Bug 116768 - Change predefined Impress templates to allow to edit text by clicking anywhere in the Text Box
Summary: Change predefined Impress templates to allow to edit text by clicking anywher...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
6.1.0.0.alpha0+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsDevAdvice
: 104091 (view as bug list)
Depends on:
Blocks: Textbox
  Show dependency treegraph
 
Reported: 2018-04-03 11:12 UTC by Pedro
Modified: 2023-07-18 13:14 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Pedro 2018-04-03 11:12:27 UTC
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.
Comment 1 Heiko Tietze 2018-04-03 12:11:36 UTC
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.
Comment 2 V Stuart Foote 2018-04-03 12:18:07 UTC
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 ***
Comment 3 Buovjaga 2018-04-03 12:29:47 UTC
Not a dupe. Based on discussion on IRC and testing Powerpoint, Samuel recommended Pedro to create this ticket.
Comment 4 V Stuart Foote 2018-04-03 13:54:40 UTC
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.
Comment 5 Buovjaga 2018-04-03 14:51:33 UTC
(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...
Comment 6 Telesto 2018-04-03 21:01:53 UTC
*** Bug 104091 has been marked as a duplicate of this bug. ***
Comment 7 Pedro 2018-04-08 19:18:48 UTC
So do you guys think that this is easily doable?
It would be a nice change...
Comment 8 Heiko Tietze 2018-04-09 07:28:28 UTC
(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.
Comment 9 Pedro 2018-04-09 09:33:53 UTC Comment hidden (off-topic)
Comment 10 Luke 2018-04-29 15:28:42 UTC
This would make a good 100 paper cuts subproject.
Comment 11 Pedro 2018-04-29 19:16:13 UTC
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.
Comment 12 QA Administrators 2019-04-30 02:41:38 UTC Comment hidden (obsolete)
Comment 13 Aron Budea 2021-02-13 06:16:14 UTC
Still in LO 7.2.0.0.alpha0+ (066799b4a162aa0a4bc6aa28339f1f943a13971e).
Comment 14 QA Administrators 2023-02-14 03:24:32 UTC Comment hidden (obsolete)
Comment 15 Sarper Akdemir (allotropia) 2023-07-18 13:14:26 UTC
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