Created attachment 167843 [details] Screenshot with 7.1.0 Beta1 on Windows 10 The "expanded list", a UI component that I don't know exactly the name, but it's used everywhere from various dialogs in "Tools > Options" to "Styles" sidebar, starts to show a visual artifact in recent 7.1 alpha/beta builds. I've attached a screenshot to show what it looks like. The screenshot is with 7.1.0 Beta1 on Windows 10: Version: 7.1.0.0.beta1 (x64) Build ID: 828a45a14a0b954e0e539f5a9a10ca31c81d8f53 CPU threads: 2; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win Locale: zh-CN (zh_CN); UI: en-US Calc: threaded ...but I've seen this since at least around 7.1.0 Alpha1 time. Also a regression from 7.0.
Believe that is intentional. For each section of the expanded tree listbox view there is a leader pointing to the entry, a leader to the opening entry, and the last entry the leader stops and turns.
(In reply to V Stuart Foote from comment #1) > Believe that is intentional. For each section of the expanded tree listbox > view there is a leader pointing to the entry, a leader to the opening entry, > and the last entry the leader stops and turns. Why though? IMHO the current implementation looks rather poor -- (1) the leader lines are barely visible when the entries are not selected, so that the lines for the selected entry looks quite jarring; (2) the line doesn't extend to the left of the entry label, but leaves a quite large white space. Are we sure this change is improving the user experience? Who are the people that need these leader lines to figure out which entry is under which category? May a user ask the old behavior back? If not by default, with a variable in the expert configuration. Pretty please?
(In reply to V Stuart Foote from comment #1) > Believe that is intentional. For each section of the expanded tree listbox > view there is a leader pointing to the entry, a leader to the opening entry, > and the last entry the leader stops and turns. I don't think so. I don't remember any discussion about it. I agree with Ming Hua and think it's a regression
I think this has happened with welding and merging the TreeLists and moving them to vcl/toolbox, their exposure toggles have been unified. So, for bug 116675 with https://gerrit.libreoffice.org/c/core/+/104414 we end up with the full listitem being selected--rather than just the label. And we are now graphically higlighting the "leaders" that have always been there. IMHO => NAB, just different visual appearance. And, would think the fg/bg colors of the active leader and inactive leaders could be changed to make them less subdued.
Created attachment 167925 [details] Screenshot with 7.0.4 RC1 (In reply to V Stuart Foote from comment #4) > So, for bug 116675 with https://gerrit.libreoffice.org/c/core/+/104414 we > end up with the full listitem being selected--rather than just the label. > And we are now graphically higlighting the "leaders" that have always been > there. But in 7.0.4 RC1 the selection is already for the whole listitem instead of just label, yet there is no (visible) leader lines. Screenshot attached. Version: 7.0.4.1 (x64) Build ID: e3cebc55238632eae061a3da668963d484a71147 CPU threads: 2; OS: Windows 10.0 Build 18363; UI render: default; VCL: win Locale: zh-CN (zh_CN); UI: en-US Calc: threaded
Seems Windows users become less familiar with trees (that are known to cause usability issues and should replaced by lists, if possible - Windows HIG). In fact, the file browser has no connection lines and while in the past it was possible to switch it on/off this page does not even talk about them https://docs.microsoft.com/en-us/windows/uwp/design/controls-and-patterns/tree-view Maybe we should follow Microsoft and drop the visual noise. The indentation is large enough to get the relation and in case of the options dialog we have only one level anyway. Stylist comes in mind, where the hierarchy is deeper and variable.
I disagree to regression. It could look nicer by shorten the space but overall it's a visual enhancement.
This is a visual aid. It’s useful for accessibility reasons (not everybody finds it easy to follow the hierarchy of nodes with just indentation). Just doing what everybody else does reminds me of when Apple removed the headphone jack for BS reasons and other companies blindly followed suit.
(In reply to Adolfo Jayme from comment #8) > This is a visual aid. It’s useful for accessibility reasons (not everybody > finds it easy to follow the hierarchy of nodes with just indentation). Well, one user's visual aid is another user's visual annoyance. I feel it's not unreasonable to ask for an expert configuration to turn this visual aid off. Also no one from UX team has addressed my critique in comment 2 yet: > Why though? IMHO the current implementation looks rather poor -- (1) the > leader lines are barely visible when the entries are not selected, so that > the lines for the selected entry looks quite jarring; (2) the line doesn't > extend to the left of the entry label, but leaves a quite large white space.
Please see Bug 137693