System: Fedora33, KDE all updates to date. A recent libreoffice update to 7.0.5.2 has created this issue. If you insert an OLE draw object into a writer document (old or new) and create a line or rectangle etc. you cannot set their fill or foreground colours in the right hand properties pane. You can select a colour in the properties pane but neither the object or the reported colour in the right hand properties pane changes to the selected colour. You can change the colour of text objects fine. Running libreoffice draw all works fine. I have tried deleting my ~/.config/libreoffice config directory, but that made no difference. However if I "su -" as a different user in a kconsole and set the DISPLAY=... environment variable then libreoffice works fine. If I fully login as that other user then the same problem occurs. So possibly an X11/OpenGL issue ?
Downgrading libreoffice to 1:7.0.1.2-5.fc33 did not help so it is likely some other Fedora package update has affected this. Also the users configuration does have an effect. If I copy my personal .config/libreoffice to a test users config that user also cannot set the colours even when libreoffice is run from a kconsole with DISPLAY=.... However if I remove my personal .config/libreoffice my personal user still cannot set the colours.
I confirm it with Version: 7.1.3.1 (x64) / LibreOffice Community Build ID: fa76d07d7006a0e2866c3247cef2d5eb55ae8369 CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL Results: You can't change colour using settings in area tab in the sidebar. You can't change colour using the drawing toolbar. I works with area dialog (Format > Area)
*** Bug 141826 has been marked as a duplicate of this bug. ***
Any news on this bug, it is still present in Fedora35 ?
Bibisected with linux-64-7.0 to 14e26096f0476b8ecb70511c304a0cdf5440ef7a make welded toolbars on-demand that were previously on-demand For me, only the Sidebar is problematic. No problem with the control in Drawing toolbar.
What is described here is presumably a draw ole object inside a writer frame, inserting drawing shapes into the inner draw ole object. Where there are two active frames, the outer writer one and the inner draw one, and the inner draw one should be used as the most relevant one. Seems that while all seems ok in the gtk case, in the gen(eric) backend case on first generation of the dropdown in the sidebar (but not toolbar) the activeFrame is unset, so later operations work on the first frame it finds and not the intended inner draw one
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/ceff75b533654154ac077a7313ebebd53aedaa5e Resolves: tdf#141577 explicitly set current frame as active frame 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.
fixed in trunk
Verified, thanks Arch Linux 64-bit Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: f0baab027df46d4e74b7808ff5d976b8efb1ea33 CPU threads: 8; OS: Linux 6.10; UI render: default; VCL: kf6 (cairo+wayland) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: CL threaded Built on 20 September 2024