Testing the newly implemented for bug 99528, sw Character style, and Frame style, and Page style panels the on-mouseover trigger of the stack of buttons is uncomfortable. Dragging mouse pointer down the vertical bar of tabs, the tab does not activate until the pointer "tip" reaches the bottom edge of the tab.
Could be os/DE and the pointer style in Windows. Cursor movement between tabs is not an issue, just the on-mouseover pointer position. Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 505803e2cb4d60153be2218a17ede8e34d95b42e CPU threads: 8; OS: Windows 10 (10.0 build 19045); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
Depends heavily on the OS/DE. With kf5 I get a line above the list item aka tab (bright on dark theme) and one below (much darker). Looks quite ugly anyway. Only solution I can think of is to add images so the entry becomes larger. And to add proper highlighting on hover too. Keeping average importance on this ticket.
Can't reproduce on recent Windows build. Can you add a screenshot/screencast with some more explanation?
Created attachment 194483 [details] Insert -> Frame... dialog on Win10 with recent master against 24.8.0 Issue remains with vertical tab mouse over position sense on at least Win10 os/DE STR: 1. open writer 2. main menu Insert -> Frame -> Frame... dialog 3. in the Frame... dialog, mouse over each of the vertical tabs: Position and Size, Options, Wrap, Hyperlink, etc. 4. note where the mouse is positioned before the tab "button" activates To me with this Win10 standard pointer, the mouse is positioned into the next lower vertical tab before it triggers the "on mouse over". Awkward to use. Version: 24.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 838f6adc9bdde2f656eb26bdc2870adfa7aa412b CPU threads: 8; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
I don't see the depicted behavior in bibisect-248 master: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 67dc0edb688d345607ae6afe3ad849f143804e28 CPU threads: 14; OS: Windows 10 (10.0 build 19045); UI render: default; VCL: win Locale: hu-HU (hu_HU); UI: en-US Calc: default Highlight moves with the mouse pointer correctly, also with Skia enabled: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 67dc0edb688d345607ae6afe3ad849f143804e28 CPU threads: 14; OS: Windows 10 (10.0 build 19045); UI render: Skia/Raster; VCL: win Locale: hu-HU (hu_HU); UI: en-US Calc: default Nor with todays nightly: Version: 24.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 8501cb20627e5bc36d760b53b0990f4105c4ff65 CPU threads: 14; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win Locale: hu-HU (hu_HU); UI: en-US Calc: default WFM?
Just checked while setting Win10 os/DE to its Light theme and disabling Skia/Vulkan rendering to Skia raster, and also to to GDI based vcl mode. The STR of comment 4 continue to exhibit the annoying 'on mouse-over' active focus not happening until the mouse body has passed into the next item on the vertical bar. No combination of Win10 os/DE mouse pointer works around issue (size, black, or inverted)--always as though the very tip of the cursor is the exact focus point, and 'on-mouse over' focus change is limited to that exact point. So when dragging down the vertical tab bar mouse body is onto the next tab before a response. Version: 24.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 838f6adc9bdde2f656eb26bdc2870adfa7aa412b CPU threads: 8; OS: Windows 10 X86_64 (10.0 build 19045); UI render: default; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded