Description: A recent, minor regression has occurred in the dialog employed to edit the properties of the "area" of shapes (seen in draw and impress, may affect other components). When you open the dialog, both "None" (to indicate lack of area colorization) and "Color" (to indicate a solid color for the area) or other entries (e.g. hatch) are selected at the same time. The various options "None", "Color", "Gradient", "Image", "Pattern", "Hatch" "Use background" should be mutually exclusive, but "None" end up being shown selected even when it should not be the case. Possibly specific to the kf6 VCL. Steps to Reproduce: 1.Open impress 2.Draw a shape (e.g. a circle) 3.Open the "Area" dialog Actual Results: Both None and Color (or some other entry) is selected Expected Results: Either None or some other entry should be selected Reproducible: Always User Profile Reset: No Additional Info: [Information automatically included from LibreOffice] Locale: en-US Module: PresentationDocument [Information guessed from browser] OS: Linux (All) OS is 64bit: yes Version: 25.8.0.4 (X86_64) / LibreOffice Community Build ID: 580(Build:4) CPU threads: 8; OS: Linux 6.16; UI render: default; VCL: kf6 (cairo+wayland) Locale: it-IT (en_US.UTF-8); UI: en-US 25.8.0-1 Calc: threaded
On pc Debian x86-64 with master sources updated today with kf6 rendering, I don't reproduce this. Now, I noticed my LO used cairo+xcb. I don't know how to use cairo+wayland.
Created attachment 202931 [details] Screenshot with kf6 and LibreOffice 25.8.1
Created attachment 202932 [details] Screenshot with kf6 and LibreOffice 25.8.1
(In reply to Callegar from comment #0) > Actual Results: > Both None and Color (or some other entry) is selected > > Expected Results: > Either None or some other entry should be selected attachment 202932 [details] shows what it looks like for me with LibreOffice 25.8.1 as packaged in Debian testing. It's similar with the gen VCL plugin. It's indeed a little confusing, but as I understand it, these are 2 different highlightings (with a different shade shade of blue being used with the Breeze style): 1) The darker blue one for "Colour" indicates the currently active option. 2) The slightly lighter blue one for "None" indicates the current keyboard focus. Pressing the Tab key repeatedly will move 2) forward, while 1) remains unchanged. It would probably make sense to have 2) match 1) initially if keyboard focus is on one of those buttons. However, I don't see this with current master any more, because the initial focus when opening the dialog is on the vertical tab control. -> Can we close this as WORKSFORME, as it's not a problem in master? (The switch to vertical tabs is a larger change and cannot be backported to 25.8.) Version: 25.8.1.1 (X86_64) / LibreOffice Community Build ID: 580(Build:1) CPU threads: 32; OS: Linux 6.16; UI render: default; VCL: kf6 (cairo+wayland) Locale: en-GB (en_GB.UTF-8); UI: en-GB Debian package version: 4:25.8.1-1 Calc: threaded Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 4e6d5774d97a19cfe3160df94cc2e8733794d4cf CPU threads: 32; OS: Linux 6.16; UI render: default; VCL: qt6 (cairo+wayland) Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: threaded
(In reply to Julien Nabet from comment #1) > Now, I noticed my LO used cairo+xcb. I don't know how to use cairo+wayland. That should be used automatically in a Wayland session, while cairo+xcb is used in an X11 session, so switching to a Wayland session would be the easiest way to try this (e.g. log out, select "Plasma Wayland" or "GNOME Wayland" in the display/login manager, then log in again). Forcing xcb in a Wayland session can be done using QT_QPA_PLATFORM=xcb which makes the app run on XWayland, but doing it the other way around would require running some Wayland compositor in your X11 session.