Description: View -> Boundaries is turned off by default making it impossible to move image + caption frame Steps to Reproduce: 1. Open attachment 197788 [details] (bug 164045 ) 2. Notice Figure 1 on page 1, having a caption frame without a border. 3. Try to move the image + caption frame around (without turning Boundaries on) This actually a part of what the user is complaining about in bug 164045. The user started moving images by cut/copy Actual Results: View -> Boundaries is turned of by default since recently, causing the caption frame to be out of sight. Expected Results: No clue if the change was intention, but the side-effect is pretty user unfriendly. 1) Exclude the caption frame from boundary's 2) Turn boundary's back on Reproducible: Always User Profile Reset: No Additional Info: Found in Version: 25.2.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 94afced0195ef824e575176e33c79ca57484cd5c CPU threads: 4; OS: Windows 8.1 X86_64 (6.3 build 9600); UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL threaded not in Version: 24.2.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 898d5d470e24a55556f2fb244fec24df33ba8855 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: threaded
I suppose it's after bug 163856.
*** Bug 164583 has been marked as a duplicate of this bug. ***
I still can select the frame and move the object even when the border line is hidden. And even for the plain indication I prefer the clean look over the educational hint. My take: NAB.
(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. True. Not sure how you managed to find to border proper area to click for the image with a caption frame >And even for the plain indication I prefer the clean look over >the educational hint. My take: NAB. If i desire a clean look I disable View -> Boundaries or render a print preview. This is terrible annoying while editing. Main use case is creating/editing. Not viewing/reading stuff requiring a clean like See also bug 164045
(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.
(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. If you know where to look. 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. B) Aside frame the fact that you can drag a image outside a frame. So caption frame not being around the image C) The frame is also of relevance for wrapping settings D) By hiding the frame by default you get descriptions like bug 164045 comment 0 @Eyal Any opinion on the matter?
It's true that we already get reports from people confused about this default while 25.2 is not even final yet: bug 164618
(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 [details]. (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.
Created attachment 198421 [details] Screenshot (In reply to Eyal Rozenberg from comment #8) > > 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 :-( The image and caption frame don't act like a grouped object, sadly. So clicking in the middle of the caption frame - so on the image - will select image not the frame. Resulting in the risk of dragging the image around, instead of the frame. This problem exacerbated by hiding the caption frame. It's going from bad to worse for now Screenshot: Image anchored in frame, but moved outside the frame.
Created attachment 198422 [details] Relevance frame for text wrap Frame border is also relevant right click context menu to set text wrap. Clicking the image inside the frame will apply text wrap for the image itself. The being able to click frame border matters. Disabling the border by default suggests it doesn't Story would be different image caption frame and image would be some kind of grouped object. Where you could only access the image when entering the group, but this isn't the case (yet)
(In reply to Eyal Rozenberg from comment #8) > First, I can't say I'm happy that the visibility of all boundaries is now a > single option. It's not a single option. You control it in more detail via Tools - Options - Writer - Formatting Aids: Object Boundaries.
Please enable the boundaries by default. It can be hard to handle some table without borders for me now
Solving bug 164605 actually and not this request.
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/8b5d4c360c359adf787d466164377c05ac8f7d14 Resolves tdf#164185 & tdf#89420 - Show text boundaries in Draw It will be available in 25.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Commit Notification from comment #14) > Heiko Tietze committed a patch related to this issue. Mistakenly assigned to this bug, it rather fixes bug 164605.
(In reply to Roman Kuznetsov from comment #12) > Please enable the boundaries by default. +1. Boundaries highly desirable for header/footer as well, and even body text.
Pressure is building, so let's do it.
When doing - Table - Insert table - Ok - nothing is displayed on the document even though the table is there. Regression introduced by: commit f40dc496a511ae06a308dd0859bc3aad28a8ec7e [log] author Heiko Tietze <tietze.heiko@gmail.com> Thu Nov 07 16:12:56 2024 +0100 committer Heiko Tietze <heiko.tietze@documentfoundation.org> Wed Nov 20 16:56:07 2024 +0100 tree b8c7e7658f194316dcee6fced0f9a4ae5fed39ab parent c635271eb17e3b9d50223356dbc09b771fcd643f [diff] Resolves tdf#163856 - Disentangle boundaries options
Ilmari Lauhakangas committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/39c50d9aedc1721ec5ffaa4568b668171e0342bf tdf#164185 Activate View - Boundaries in Writer by default It will be available in 25.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Ilmari Lauhakangas committed a patch related to this issue. It has been pushed to "libreoffice-25-2": https://git.libreoffice.org/core/commit/af70c7038540837e04f670750bd820fe79702859 tdf#164185 Activate View - Boundaries in Writer by default It will be available in 25.2.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Done and dusted.