Description: The choices available in image properties dialog, "Type" tab, "Position" selection, section "to" are changing is hard to predict and inconsistent way when "Anchor" selection is changed. Steps to Reproduce: 1.Insert image. Right click on it and anchor it "to paragraph". Then bring up the image properties by right-clicking on it. 2.Select "Type" tab and notice the "Anchor" selection. 3.Click in this tab "Anchor->to Page" and check available choices in "Position-Horizontal->to" and "Position-Vertical->to". I can see: Horizontal:"Left...","Right...","Entire....","Page text..." Vertical: "Entire...","Page text area" 4.Click "Anchor -> to character". "to->Horizontal" contains now almost all possible options, but "Position->To->Vertical" only "Margin","Parag...","Entire page","Page text...". 5.Click "Anchor->as character". Don't check anything. 6.Again click "Anchor->to character". Check what is now available at "Position->To->Vertical". I can see two more options than previously: "Margin","Parag...","Entire page","Page text..." plus new: "Character","Line of text" Actual Results: The positioning options available in step 6 are different than options available in step 4. Expected Results: The possible set of selections should be independent from the sequence of any other operations in this window and should consistently report the same set of possible selections regardless of how and in what order the anchor selection was made. Reproducible: Always User Profile Reset: No OpenGL enabled: Yes Additional Info: Observation: Once the "Anchor->as character" was selected at least once the possible selections for "Anchor->to character" are consistent with point 6 regardless of how do I switch between selections. I suspect then, that this is a correct set of selections. If You think otherwise, please re-consider it. The "Character" and "Line of text" are I think critical for "to character" anchor. Without them it doesn't differ much from "to Paragraph". Notice I did not inspect other selection sets. The current behavior suggests that some other bugs of such kind may be present. I do suggest to check if the piece of code which is manipulating sets presented in drop-downs is state-less, that is if it builds set each time from scratch and re-selects a best match option instead of trying to modify existing set by adding/removing options. The state-less design is much easier to maintain. I do qualify it as "minor" but shameful. It's a real pain for LibreOffice fan like me to explain a new user that to set some position mode for "to character" one must first make it "as character" and then move back to "to character". It sound like a "black magic" isn't it? Version: 7.0.2.2 Build ID: 00(Build:2) CPU threads: 4; OS: Linux 5.8; UI render: default; VCL: x11 Locale: pl-PL (C.UTF-8); UI: en-US Ubuntu package version: 1:7.0.2-0ubuntu1 Calc: threaded Thanks for an excellent software. Keep up with improving quality, it is more important than bells and whistles. If I would like to have a "fashionable" soft I would choose Word, but I prefer Libre because I use software to earn money at work.
Took reasonable time to understand. Repro Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: a809b2ab2553e946431699d9d7ac3f6209cbdd6b CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL STR 1. Open the attached file 2. Click the drop down at 'Vertical' containing 'Margin' Notice 4 entry's 3. Switch anchor to 'as character' 4. Switch anchor to 'to character' again -> 6 entry's
Created attachment 171348 [details] Example file
Working differently, but broken too in 6.2 Currently behaviour also found in Version: 6.3.7.0.0+ (x86) Build ID: 726535ec30f12697ceccd2f0640d9371a64dc5bd CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; Locale: nl-NL (nl_NL); UI-Language: en-US Calc: CL
@Caolan You might take an interest in this. Would say welding changed something (but being broken before)
What is listed in the "to" depends on what is selected in "vertical". If you start as "anchored to character" and "vertical" of "from top" there are four options for "to". Change to "top" then the distance greys out and there are six options for "to". The "to" depends directly on the "vertical" setting rather than the sequence of anchor changes. Though, changing the anchor changes what options are available for "vertical" and thus what's available for "to", so in the example sequence of comment #1 2. Click the drop down at 'Vertical' containing 'Margin' Notice 4 entry's At this point the "Vertical" is showing "From top" as one of six options (where Top is another possibility) and the "to" dropdown is showing "Margin" as one of four options depending on "From top" 3. Switch anchor to 'as character' At this point "Vertical" has four options, "From top" is not available so something else is picked instead, "Top" in my case and then "to" has three dependent options for "Top" 4. Switch anchor to 'to character' again -> 6 entry's At this point "Vertical" remains as "Top" because "Vertical" has "Top" as a possibility and "to" shows one of the six dependent options. Taking as a given the differing availability of anchoring hori/vert options for each anchor mode and then then differing dependent to targets depending on that I don't see an easy "fix" for the UI. FWIW: The code for this notebook page is SwFramePage in sw/source/ui/frmdlg/frmpage.cxx and the matching .ui is sw/uiconfig/swriter/ui/frmtypepage.ui
Created attachment 171795 [details] Image properties dialog Just a screen shot of image properties dialog as it is visible in my version of LibreOffice so that we all know what we are talking about.
First I would like to thank You all for good work. LibreOffice is my work-horse and having it working perfectly is very important to me. Back to business. > What is listed in the "to" depends on what is selected in "vertical". > (...) I don't see an easy "fix" for the UI. Ok, I do understand that now. This is not a bug, but a confusing design of a user interface. As far as I understand it is is a double cascade: change to anchor changes the possible set of "vertical" options. Since current option is not available, the other option is selected without a user action. This selected option changes the available set in the other set, again without a user action. This cascade may have, I think, up to five levels in any direction, so it will be hardly possible to try out all combinations by a user. I have to agree with You that applying any fix in code will be rather tricky. I will try now to take two steps: A. Figure out what was responsible for the fact that I missed those side effects as a user. B. Figure out what logic is behind the problem and propose some solutions. ------------------------------------ Ad A) I was aware, that changing anchor may change some choices I do have, so I was looking for them. But since I was looking for what is available, I did not try to click every possible combination. This is a first element - one can't see what is possible in place A without making a selection in places B and C. Next problem is: what places should I observe to notice those side effects? 1.The image on the right of anchor radios (I did attached a screenshot just in case) 2.Changes in any of eight "Position" settings. 3.Changes in any of four drop-down lists. Ad 1) I did notice that when my eyes do focus on radio buttons then the image presenting setting IS in my center of focus, so I can easily notice something moves there when I change "anchor". I missed however those changes when I was making selections to "Position" drop downs. Ad 2) Those eight "Position" settings are far enough from "anchor" and image so that they are out of sight and attention focus. They are just text so I missed they are changing. Ad 3) Change in possible choices on drop-down list is of course invisible. X-ray vision is necessary ;) So the first problem is: the arrangement of GUI is such, that some side effects are hard or impossible to notice. The most helping element which is an image which shows what is going on is at the side, far off from the attention center. To make it even harder it is logically grouped with "Anchor" and "Size", being in one row, but not in fact with "Position" which is below. This is _why_ I didn't notice. --------------------------------------- Ad B) The big question is: what logic is behind it? I think the main reason is an _asymmetry_ of a data structure (choices available in step 2 do depend on choice made in step 1) related to anchoring and designed _symmetry_ of user interface (all choices available at every step, selections are independent). Asymmetric is a tree like selection, symmetric is a table like. In table every combination You can select in any column forms a valid selection, in tree You have to follow the path. This is hardly possible to present an asymmetric choice in a symmetric GUI without a nasty set of side effects. This is exactly what is observed. In symmetric GUI user may make choices in any order and, as You noticed, some selections can't be moved from one branch of selection tree to an another one. I think this is a key point: I did switched the "anchor" and some selection become "impossible" in this context. Since it was impossible to keep it, program did some "best choice" behind my back. This triggered a cascade. I missed that and got confused. Now imagine how would this GUI behave if I would start making selection from the bottom right corner of this dialog and going up? Nothing prevents me from doing it in that way, but a final effect is, if You try it, almost unpredictable. ------------------------------- There are two possible paths of solving it, I think: 1.Make side effect clearly visible. 2.Make "impossible" to become "possible". Ad 1) The center of "Anchor" operation is that image on right. It could be put in center of attention and updated to more precisely present the effect (mirror is missing now for an example). The options should be located around it, horizontal at the bottom, vertical on right, anchors on the left. Drop down lists should be changed to radio-buttons blocks with grayed out disabled options so that changes to available choices would be clearly visible. Tooltips should be added to every element. Side effect may be left as they are now, they should be much easier to notice. Ad 2) First assume following presentation of "impossible" options: 1.If option is a selection from a drop down list: a) show it in RED and striked-out (some can't tell colors apart); b) update tooltip to that selection to say "This is impossible in that anchor mode"; 2.If the option is the value in "by" input field: a) leave value as it is; b) keep input field enabled and show value as striked-out text; b) update tooltip to that selection to say "This value is ignored in that anchor mode"; 3.If the option is a check-box, then it means that check box has no meaning in that anchor mode, so: a) leave value as it is; b) keep it enabled so user may click and change it; c) show it as striked-out; d) update tooltip to that selection to say "This option is not aplicable in that anchor mode"; Second: 1.Always show all options in drop down lists. Those "impossible" in current context should be shown as impossible, but user must be allowed to select it anyway. Selection of such an impossible option should disable "OK" button, because such an option cannot be applied. 2.Always allow user to click check box, even if not applicable, and type values in "by" field, even ignored. Simply show them according to their status. Not applicable/ignored values in check-boxes and input fields should be silently ignored when user clicks "OK". Third: 1. Make tooltips to explain what is what. This will help users to understand why some option is impossible and how to use it. Fourth: 1. The "Anchor" is a main setting. Setting anchor mode is always possible and it dictates what is possible and what is not, either directly or through a cascade. No "impossible" presentation here, since otherwise we would have a logic loop. Result: This will: a) force user to update their choice to a valid one, so no side effect can escape their attention; b) let user to click back to their previous selection since GUI still preserves old, "impossible" now settings; c) the interface becomes discoverable, because user can always see all options; d) the result does not depend on order of selections. The right-bottom-corner-up scenario I described above should be now possible and give reasonable results. ---------------------------------------------------------- Note:Unfortunately when playing I had hit an another bug in the same area: https://bugs.documentfoundation.org/show_bug.cgi?id=142178