https://bugs.documentfoundation.org/show_bug.cgi?id=164185
--- Comment #8 from Eyal Rozenberg <[email protected]> --- (In reply to Heiko Tietze from comment #3) > I still can select the frame and move the object even when the border line > is hidden. Same here, with 24.8 and w. But... with a 25.8 nightly, I get boundaries drawn because of bug 164438: The images don't render and I get placeholders instead; see screenshot in attachment 198420. (In reply to Heiko Tietze from comment #5) > (In reply to Telesto from comment #4) > > This is terrible annoying while editing. > Assuming you move objects around a lot. I'm against changing the default - > you can enable the option easily. You nearly _always_ move images in frames when they are not positioned as characters. So, it is indeed a problem for the default - for this kind of frames - to be boundaries off. I'm not saying there are no arguments for the change though. I'm sorry I didn't attend the discussion about this change :-( > A) A workflow where you consciously disable showing (caption) frames makes > more sense compared to hiding the frame. Making people unaware of the > existence of a frame which you can move. Combined by no clue you don't even > know what to toggle on. Well, maybe; but you also have the opposite problem: How will novice users know that frame is non-printing? And that it's possible to remove it? > B) Aside frame the fact that you can drag a image outside a frame. So > caption frame not being around the image I'm having trouble parsing these two sentences, please rephrase/fix the grammer :-( > C) The frame is also of relevance for wrapping settings It is, but I don't understand how this bears on what Heiko said. > D) By hiding the frame by default you get descriptions like bug 164045 > comment 0 Let's quote that explicitly: That comment is "It always seems difficult to move a picture in writer". And the poster explains how, instead of moving caption frames, he recreates them elsewhere. Yikes! I can't say how common that experience is, but the movable-object-within-frame is itself difficult for notices; and if the frames are not drawn it is even more difficult. BTW, when they are drawn - their sides overlapping also makes it a bit more difficult for novices to understand what's going on. > @Eyal > Any opinion on the matter? First, I can't say I'm happy that the visibility of all boundaries is now a single option. But - Maybe we should think outside the binary of just showing/hiding the boundaries by default? e.g. one or more of 1. Show boundary on... 1.1 hover over the boundary 1.2 hover over object 1.3 loiter over object 1.4 intersection of any selection and the object (e.g. selecting text in the caption) 2. When the boundary does not show, highlight/colorize area 2.1 hover over the boundary 2.2 hover over object 2.3 loiter over object 2.4 intersection of any selection and the object (e.g. selecting text in the caption) 3. Add a "show boundaries" option (local or global) to the relevant context menus just thinking out loud here. -- You are receiving this mail because: You are the assignee for the bug.
