Created attachment 194471 [details] Screencast I wonder if this is an issue of the kf5/6 implementation. Version: 24.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 2269b418f7af598ff8194acb9929c8bd6c4baeb1 CPU threads: 32; OS: Linux 6.9; UI render: default; VCL: kf5 (cairo+xcb) Locale: de-DE (en_US.UTF-8); UI: en-US Calc: threaded Operating System: Arch Linux KDE Plasma Version: 6.0.5 KDE Frameworks Version: 6.2.0 Qt Version: 6.7.1 Kernel Version: 6.9.2-arch1-1 (64-bit) Graphics Platform: X11
(In reply to Heiko Tietze from comment #0) > I wonder if this is an issue of the kf5/6 implementation. From what I can see, this looks pretty much the same with SAL_USE_VCLPLUGIN=gen, doesn't it? Some more details (steps to reproduce, what exactly is incorrect?) in the description would be useful. Do you mean that the "mouse pointer focus highlighting color" (or whatever would be the proper term) in LO's vertical tabs when using the Qt-based VCL plugins is different from those in native Qt controls? If so, to be honest, that sounds more like an enhancement request than an issue of severity "major" to me. Or am I missing something else in the screencast?
The right part of the screen cast shows KDE's system settings with an icon view to select the area. It's probably not a tabview. UI/UX wise it gives proper feedback for hover and select. The left part shows how the new vertical tabs look like with kf5, hover with faint lines above and below and select per grey background.
[Automated Action] NeedInfo-To-Unconfirmed
I see the same under windows in 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
(In reply to Gabor Kelemen (allotropia) from comment #4) > I see the same under windows in todays nightly: I've adjusted the title accordingly. For the Qt-based VCL plugins and getting a behavior like in native Qt widgets, actually using those is probably the best solution, see tdf#130857.
(In reply to Michael Weghorn from comment #5) > For the Qt-based VCL plugins and getting a behavior like in native Qt > widgets, actually using those is probably the best solution, see tdf#130857. An alternative as long as we don't use native widgets is to use the Qt drawing API instead. Pending Gerrit change using that for the mouse hover feedback: https://gerrit.libreoffice.org/c/core/+/170341
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 #6) > Pending Gerrit change using that for the mouse hover feedback: > https://gerrit.libreoffice.org/c/core/+/170341 Merged now, so closing as fixed. I suggest to track further visual improvements in tdf#161501 or separate tickets.