Description: I'm somewhat frustrated by the Writer Textbox. Reported multiple bugs about this topic in the past: bug 139592 bug 139593 bug 107825. Those bugs point usability issue I perceive exists.. Except I was searching in the wrong direction. What's called a Textbox in MSO apparently - more or less - a (interactive) Text Frame (without border) in Writer. Or at least LibreOffice converts an MSO textbox into a frame (if opening a doc created by Word) The same happens saving a textbox (shape). It will be converted to a frame on export to DOC/DOCX. The textbox (shape) is shared across all LibreOffice components. While the Interactive Text Frame being a Writer only element. This might be done for coherence between components (I speculate) And maybe to prevent people creating textbox frame with anchored objects (which MSO can't handle). However the textbox (shape) from usability perspective not 'it', IMHO. See bugs mentioned. I'm kind of inclined to make an Interactive frame being called TextBox. However textbox used for shape variant over the years (no the shape part not that obvious, IMHO). So I would consider the current 'Textbox" to "Shape textbox". And adding new entry "Frame Textbox" (or textbox frame). And 'hiding the 'Textbox shape' under insert shape. Yes this would add an duplicate; Frame Textbox being essentially an Interactive Frame (but well.. Textbox is in essence shape without fill.. so) The accessibility of Interactive Frame surely nicer compared to textbox shape. And would also reduce the whole DOCX/DOC translation/transformation process. Disliking sudden changes in a document Yes, this kind of breaks harmonics across components. But well Writer isn't Draw/Impress. And textboxes inside Calc are less common I think (but might be wrong here) Steps to Reproduce: See above Actual Results: Textbox based on shape.. with certain limitations Expected Results: Textbox based on Interactive frame Reproducible: Always User Profile Reset: No Additional Info: Version: 7.1.0.0.beta1+ (x64) Build ID: f9fab4203c1aa0b9a3f27ce2713b6d5addc7df19 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: nl-NL Calc: CL
So would use Interactive Frame with a Column (.uno:InsertFrameInteract) vs. current Text Box (.uno:DrawText) Would require a lot of import/export filter changes; and would have to consider handling of existing documents. Very disruptive and considerable work, not clear it is worth it.
(In reply to V Stuart Foote from comment #1) > So would use Interactive Frame with a Column (.uno:InsertFrameInteract) vs. > current Text Box (.uno:DrawText) Confused me. What I have/had in mind doesn't require lots of changes.. At least nothing substantial.. so where surely not on the same page.. In intended to say: Create an new entry in "Insert" called 'Textbox Frame". Which would trigger the same .uno link as Insert -> Frame -> Interactive frame. And move the 'insert textbox (.uno:DrawText) to Insert -> Shape Frames are already handled by import/export filters. So not proposing something new.. And Textbox shapes are converted to frames already on DOCX/DOC export/import. It's in fact only shuffling around menu entry's and some renaming. There are obviously some more area's where this needs to happen (toolbar). But this is seen from the amount of work simply a "cosmetic" change. Documentation would obviously not appreciating this (in the sense of re-doing). No clue if this would make explaining easier. One objection is obviously using using 2 names for the same tool? (Textbox frame = Interactive frame). But well textbox is currently a drawing object (so in fact a shape without background). Same distinction would be Textbox frame inserting without pre-set border. But now I'm ask myself what had Stuart in mind when read in my proposal? We are apparently talking about something different?
Well sure, the menu change would be part-n-parcel to the TB change. Replacing the Insert -> Text Box (now .uno:DrawText) with "Text Frame" (to use a frame with column .uno:InsertFrameInteract). The "Text Box" (.uno:DrawText) could shift to the Insert -> Shape The complexity comes with all existing documents, extensions, documentation, and user work flows for Writer that have been DrawText focused. The TB and Menu changes are easy, the cultural changes not so much. Is it a good idea and better UX--probably. Should it be done--I don't know.
I like the idea to have an icon in the standard toolbar for what now needs menu Insert > Frame > Frame Interactively. If you currently try to add a frame command to a toolbar, you get these problems: 1. The command .uno:InsertFrameInteract as icon in a toolbar does not provide a single-click functionality. Instead you have to open a drop-down list and select the number of columns. That is different from menu, where you can immediately drag-create the frame. 2. The command .uno:InsertFrameInteractNoColumns, which I had thought would give a single-click functionality, does not work at all. And I like the idea to have the shape text-box (command .uno:DrawText) (and perhaps the other missing shape types too?) available via menu Insert > Shape.
(In reply to Regina Henschel from comment #4) > 1. The command .uno:InsertFrameInteract as icon in a toolbar does not > provide a single-click functionality. Instead you have to open a drop-down > list and select the number of columns. That is different from menu, where > you can immediately drag-create the frame. Noticed that, on TB the current control would need a split button with default 1-column frame with column, and drop list for the dialog for more columns--like we did with the Save button. Also, might need an icon rework. @Maxim, what is your take on this, and emphasizing 'Frame with column' over a 'draw shape' text object?
FWIW: if the change is considered... please include the shortcut topic :P. For me it would entail also using the Frame text when pressing F2 in Writer. [But well this has a compatibility issue.. As surely a group would like textbox Draw object. And F2 is used for draw textbox in all components]
We have a hidden vertical text box in the toolbar that needs to be removed as well. But it isn't working anyway, clicking the show checkbox never checks it.
Sascha commented on the design meeting + sdraw objects shouldn't replace main features of swriter (Sascha) + the frame has several advantages and should be preferred (Sascha) So let's do it.
Sascha suggested to use Ctrl+T as shortcut (requested in bug 139632). I hesitate to add default shortcuts everywhere as removal is much harder. The text box is IMHO not a frequently used feature that requires a shortcut. It's pretty easy to click on the toolbar - and to customize.
(In reply to Heiko Tietze from comment #9) > Sascha suggested to use Ctrl+T as shortcut (requested in bug 139632). I > hesitate to add default shortcuts everywhere as removal is much harder. The > text box is IMHO not a frequently used feature that requires a shortcut. > It's pretty easy to click on the toolbar - and to customize. CTRL+T for .uno:DrawText or .uno:InsertFrameInteract? I see F2 as rename to or a tool to enter a textbox/ Interactive frame (click it press F2). Not for insertion, but well said that before. However CTRL+T is not enough. Interactive frame would need a shortcut too (I think, but can be argued about). So personally like CTRL+T for DrawText (if available and used for all components) To only well this need so adapting for certain group of users. The can obviously change the shortcut back. And I personally see good reason for the change.. (F2 in navigator). So I'm seeing advantages freeing F2 of uno.DrawText.. And I assume people do use Textboxes in Impress/Draw and those people surely want a shortcut.. And I prefer 'global shortcut' for the uno.DrawText.. as this can be inserted everywhere..
Are the points in comment 4 considered part of this ticket? Or should new bug reports be made for them? (In reply to Heiko Tietze from comment #7) > We have a hidden vertical text box in the toolbar that needs to be removed > as well. But it isn't working anyway, clicking the show checkbox never > checks it. Confirm for: Version: 7.1.0.3 (x64) / LibreOffice Community Cannot reproduce with: Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 72841008bf422dfd8553240b3a78f0474d03523c (i.e., no problem to put this .uno on the toolbar, and it works as promised, displaying text vertically).
(In reply to sdc.blanco from comment #11) > Are the points in comment 4 considered part of this ticket? It is the essence of the solution. See also comment 3 for code pointer.
Insert > Frame > Frame Interactively. Actual: After placing the frame, focus is on the frame, Expected: Focus is in the frame (like Text Box) (or should I file a separate ticket)?
(In reply to sdc.blanco from comment #13) > Actual: After placing the frame, focus is on the frame, > Expected: Focus is in the frame (like Text Box) But you can type type straight away. NAB IMO
(In reply to sdc.blanco from comment #13) > Insert > Frame > Frame Interactively. > > Actual: After placing the frame, focus is on the frame, > Expected: Focus is in the frame (like Text Box) > > (or should I file a separate ticket)? Actually that is one of the annoyances of the current drawshape text box (.uno:DrawText) that moving to the frame w/ column insertion (.uno:InsertFrameInteract)--as soon as you release the mouse cursor while dragging box to size you loose ability to adjust and can only type the shape's text. If you type nothing, and attempt to adjust the size the shape will close and be destroyed. So the draw shape text box has the unwanted behavior--text cursor focus on drag release, it happens too soon and without control. The Frame w/column on the other hand behaves sanely--you can position and resize exactly as needed, and only when correct an <Enter> key will complete the frame and enters the inscribed column with text cursor focus. Don't see an issue here.
(In reply to Heiko Tietze from comment #14) > But you can type type straight away. [Insert confession here] about my lack of knowledge/misinterpretation about the meaning of the highlighted frame. > NAB IMO Agreed.
Adding CC: Miklos the author of textboxes in 4.4. https://vmiklos.hu/blog/textbox.html His work here has been a huge boon to interoperability with MSO. Frames have their own limitations comparted to textboxes. Ex, textboxes have modern features like rounded corners and complex content like containing a table. In addition, LO’s textboxes map well to OOXML textboxes. This is a huge win for those of us that need to collaborate with others. Rather than going back to the old frames concept. We should focus on fixing textbox bugs and bring the feature level of LO's textbox up to that of MSO’s. Textboxes have advantages over frames.
(In reply to Luke from comment #17) > His work here has been a huge boon to interoperability with MSO. Frames have > their own limitations comparted to textboxes. Ex, textboxes have modern > features like rounded corners and complex content like containing a table. > In addition, LO’s textboxes map well to OOXML textboxes. This is a huge win > for those of us that need to collaborate with others. Good arguments. OTOH, frames are easier to handle (they don't disappear when left empty and edit vs. object mode is more clear) and they start with margin and border by default. IIRC, there are good reasons for textboxes to behave like this and we cannot improve the usability.
(In reply to Heiko Tietze from comment #18) > frames are easier to handle (they don't disappear when > left empty .. and they start with margin and border by default. None of those issues should be showstoppers nor insurmountable. For example, an easy hack solution for the first would be to add highlighted dummy text. As soon as you start typing, the text would be over written. If left empty, the textbox would remain with the dummy text. The margin and border issue could be fixed by styles. Textbox allow so much more customization and options that frames, we really need a textbox style and choice of type of textbox style on insert time. This is a good project for the UX team. I suggest you survey our competitor as they have tacked this issue nicely.
Please go back and re-read the OP and summary. The Draw shape text is not being eliminated. This UX adjustment would simply deemphasize the current 'Insert Text Box' of the .uno:DrawText, which would be moved to the Insert -> Shape -> 'Text Box' (or Text Frame as notated on Navigator). It would provide a main TB button action (likely a split button, single column default action--and a DL for other column picks) and would use the .uno:InsertFrameInteract action. The work on Draw shape text features is great, but they have a long way to go to match the edit engine handling already available for text in an interactive frame which exposes a fully functional/customizable set of style for the 'Frame' object. What style controls do you have over a Draw shape 'Text Box' in Writer?
What is more, our writers on https://essaywritinghelp.pro/custom-term-papers/ are experts in their own fields and this means they can tackle assignments on any subject. Whether it is chemistry, biology, English, mathematics, social sciences, physics or business, we can handle it. Place your order with us today for assignments help online.