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
If I understand this issue correctly, https://gerrit.libreoffice.org/c/core/+/170341 should presumably solve it.
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/6a3f91c4e9c669fc445eab8f3c526233cd68fdb9 tdf#161026 tdf#161355 icon choice ctrl: Draw icon + text at the end It will be available in 25.2.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.
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/8708e8cf90d0ac0acbbce34b82f10ef7352d5062 tdf#161026 tdf#161355 tdf#161501 icon choice ctrl: Natively draw mouse-hover It will be available in 25.2.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 Michael Weghorn from comment #7) > If I understand this issue correctly, > https://gerrit.libreoffice.org/c/core/+/170341 should presumably solve it. Merged now, and works as expected in my tests on Windows 10 (with default theming) at least. Could you please retest with a daily build from tomorrow or newer and provide feedback here?
Confirmed the vertical tab focus issue on Win builds is fixed with 20240712 nightly build with patch applied: https://gerrit.libreoffice.org/c/core/+/170341 Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 69fc5c396059603804b17b0f0cb076fff7188cba CPU threads: 8; OS: Windows 11 X86_64 (10.0 build 22631); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded