Suppose I insert a textbox, and am editing the text. I'm not done editing, but I already want to format a border for my textbox (e.g. so that, after I leave it, I'll have a good idea of where it is exactly; the text won't fill it up so well). So, I navigate to Format > Text Box and Sape... submenu on the menubar, and - find that "Position and Size...", "Line..." and "Area..." are all grayed out. I don't think they should be. There is no ambiguity AFAICT regarding which box and which shape. It's just LibreOffice "sticking its head in the sand" pretending it doesn't know where I am.
Bug 153971 is the complement of this one: It's about formatting the text are when outside the text box or shape.
The editing context is unaware of the parent object. Could be anything and we don't know if border attributes are available. Besides the technical limitations I don't think this use case justifies any larger effort. KISS!
But isn't the issue that the sd Text box "shape" is in its text entry mode. Without finalizing the text box, you currently can shift out of text mode and assign the Line weight, color and type, then shift back into text mode to continue your entry for the text box. The mode change for these draw shapes in Writer are mouse clicks (would be nice to have keyboard only actions available for it). While in Draw/Impress in addition to the mouse clicks, you can also define and make a Style selection for the shapes for the type of Text box you need. In Writer the shapes take the Default Drawing Style when created. So, can already do what is requested while editing the Text box shape, just not from its text entry mode. Weak use case to be able to change the draw shape properties while remaining in the text entry mode. -1
(In reply to V Stuart Foote from comment #3) > The mode change for these draw shapes in Writer are mouse clicks (would be > nice to have keyboard only actions available for it). Oh, /me ignorant. With focus on a shape--the <Esc> toggles to the Object focus mode, while simple <Enter> key toggles to text entry mode! Facepalm. Even less of an issue to need complexity of exposing shape's object properties during text entry as the toggle is so direct.
(In reply to Heiko Tietze from comment #2) > The editing context is unaware of the parent object... KISS! Those two parts of your statement contradict, of course. I _have_ kept it simple: The user is working on a textbox, but can't format it. Thing like isolation of editing contexts from the objects in which they exist is a complex notion, and certainly not something the user should care about. The user knows s/he's in the text box - and expects to be able to format it. There is also no ambiguity regarding which shape or object the user might be formatting.
(In reply to V Stuart Foote from comment #3) > But isn't the issue that the sd Text box "shape" is in its text entry mode. No, that's not the issue. In that mode, it is in the user's interest to be able to take action on the containing object - as long as that does not interference or contradict with the editing. So, certainly, something like a right-click context menu should differ in text entry mode and in outside that mode. But not a menu item, which clearly regards the containing object (the text box). > Without finalizing the text box, you currently can shift out of text mode > and assign the Line weight, color and type, then shift back into text mode > to continue your entry for the text box. The application should (almost) never work against the user's express wish. If I say I want to format the shape line, and LO knows which shape, it should just do that; instead, it's telling the user "Sorry, our offices are closed for the day, come back another time". The fact that some of us might prefer the user first pressed Esc or clicked something, then chose that menu item - is our problem, and should not be the user's. Now, you could argue that making that choice should itself count as finalizing the Textbox, then opening the formatting dialog, taking the user out of the text editing mode. That's fine - and better agrees with the distinction between modes. (Although I'm also ok with the other alternative).