Created attachment 175265 [details] Video capture In Impress and Draw, if you create a text box, enter text and then click outside it, it moves the text to a different position (see attached video capture). This is a bit of an annoyance because every time a text box is created, it changes the position of the actual text and then the user has to manually fix it. After a long time using LO you get used to this behavior, but still it doesn't feel right. It seems the problem is caused by the fact that after the text box is created, the default style is applied and it creates internal spacing in the text box. Note that if you change the "Default Drawing Style" and remove all internal spacing in the "Text" tab under "Spacing and Borders" the problem disappears. It would be great if applying the default style did not change the text position but rather create spacing around the current text position.
Not quite valid. You have started typing into your text box without completing its positioning. If you complete drawing a box outline (drag its drawing cursor away) the draw text object is fully instantiated and stays put. The "jump" in position on clicking outside the new text is completing the styling of the draw text object. To me it is doing the correct and expected thing. To precisely position, complete the draw objects box (including its internal spacing) then fill its text. Box will resize with object styling as needed for overflowing text.
Created attachment 175423 [details] Same workflow in MS PowerPoint
Created attachment 175424 [details] Same workflow in OnlyOffice
Created attachment 175425 [details] Same workflow in Google Slides
> Not quite valid. You have started typing into your text box without > completing its positioning. If you complete drawing a box outline (drag its > drawing cursor away) the draw text object is fully instantiated and stays > put. Hi! To be clear, I'm not saying it is a bug, but rather a UX issue. I mean that it would be better if the text did not jump to a different position. Suppose there were two options, which do you think would be more desirable for the end user? 1) Follow the steps I did in the first video and the text remains in the same position when the user clicks outside. 2) Follow the steps I did in the first video and the text jumps to a different position after clicking outside. > To me it is doing the correct and expected thing. I followed the same steps on MS PowerPoint, Google Slides and OnlyOffice and in all of them, when the user clicks outside the text box, the text stays in the same position. Notice that when the user first clicks the slide, the initial textbox already contains all the internal padding. In LibreOffice the initial textbox does not have internal padding and it gets applied only when the cursor leaves the textbox. Just as a final remark, I always like to think from the perspective of a new user coming from other office suites to LibreOffice... and since all of them have the same behavior, when the new user faces issues like these, he/she will not get a good impression from LibreOffice and will think that this is a bug. Moreover, I would have much trouble explaining to a new user that the text changing its position is a better experience and that this is the way things should be.
(In reply to Rafael Lima from comment #5) > > Not quite valid. You have started typing into your text box without > > completing its positioning. If you complete drawing a box outline (drag its > > drawing cursor away) the draw text object is fully instantiated and stays > > put. > > Hi! To be clear, I'm not saying it is a bug, but rather a UX issue. I mean > that it would be better if the text did not jump to a different position. > Suppose there were two options, which do you think would be more desirable > for the end user? > > 1) Follow the steps I did in the first video and the text remains in the > same position when the user clicks outside. > > 2) Follow the steps I did in the first video and the text jumps to a > different position after clicking outside. > Maybe, but IIUC if we were to immediately instantiate a new draw text object, with no text entry, and then <esc> out we would leave a zero size draw object. They'd be impossible to select and clear away. Don't want that behavior. So, in addition to the current mouse release/click to complete draw object creation--we would need the Draw text box object to be created fully styled on the initial single character entry, rather than by a mouse action. That would be to supplement currently functional drawing of full text box with its styling and then entering text at its text cursor.
Don't see why the textbox needs to jump by a fix value. And if this can't be solved we may introduce a similar solution as in Writer where you have to draw the box first - just clicking is not enough. Miklos, who could be an expert here?
The jump looks like a bug to me as well. CC Thorsten in case you would need an Impress expert.
(In reply to Heiko Tietze from comment #7) > Don't see why the textbox needs to jump by a fix value. And if this can't be > solved we may introduce a similar solution as in Writer where you have to > draw the box first - just clicking is not enough. IMO forcing the user to draw a box before entering text will not be nice, specially because it won't automatically resize the box and the user will later have to resize it manually. Also, in Impress creating text boxes is something users do many times, so it has to be done quickly. The current way of creating a text box in Impress/Draw is better... the only thing that needs fixing is the text jumping to another position. BTW... notice that in Writer the text does not jump because no internal padding is added. Maybe this behavior could be implemented in Impress as well.
The "jump" is because there is no style applied to the draw text object as it is created by just typing text--the "jump" now is the draw object padding being applied to the text within the text box as the object is fully created. If possible, the "fix" to hold the text position would require the text entry to know it is creating a draw text box object with particular style/configuration, and to apply its padding as the text is being entered--not when entry is completed and the object fully created.