Description: When I'm trying to change all shapes with same color to another color, "Replace" button is not active in a Tools->Color Replacer Steps to Reproduce: 1.Opening PDF file via LibreOffice Draw 2.Going to "Tools" 3."Color replacer" 4.Chooxing which color should be change with which color Actual Results: Replace Button not active Expected Results: It should replace the color Reproducible: Always User Profile Reset: No Additional Info: Version: 7.4.3.2 (x86) / LibreOffice Community Build ID: 1048a8393ae2eeec98dff31b5c133c5f1d08b890 CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: en-US (en_GB); UI: en-US Calc: CL
Created attachment 185177 [details] Picture where showing that button is not active
On pc Debian x86-64 with master sources updated today, I got an assertion with gen rendering when trying to open the dialog box: warn:vcl.layout:14496:14496:include/vcl/builder.hxx:439: .ui widget "DockingColorReplace" needs to correspond to vcl type 6VclBox soffice.bin: /home/julien/lo/libreoffice/include/vcl/builder.hxx:440: T *VclBuilder::get(const rtl::OString &) [T = VclBox]: Assertion `!w || dynamic_cast<T*>(w)' failed. Unspecified Application Error with gtk3, I got: (soffice:14769): GLib-GObject-WARNING **: 21:03:32.012: invalid cast from 'GtkGrid' to 'GtkBox' #3 0x00007f348d5a24f6 in (anonymous namespace)::GtkInstanceBuilder::weld_box(rtl::OString const&) (this=0x562f7bac2600, id="DockingColorReplace") at vcl/unx/gtk3/gtkinst.cxx:24039 #4 0x00007f349b93d547 in SfxDockingWindow::SfxDockingWindow(SfxBindings*, SfxChildWindow*, vcl::Window*, rtl::OString const&, rtl::OUString const&) (this=0x562f777cde80, vtt=0x7f349a916dc8 <VTT for SvxBmpMask+8>, pBindinx=0x562f769612a0, pCW=0x562f7714b340, pParent=0x562f76975a70, rID="DockingColorReplace", rUIXMLDescription="svx/ui/dockingcolorreplace.ui") at sfx2/source/dialog/dockwin.cxx:769 #5 0x00007f349a516266 in SvxBmpMask::SvxBmpMask(SfxBindings*, SfxChildWindow*, vcl::Window*) (this=0x562f777cde80, pBindinx=0x562f769612a0, pCW=0x562f7714b340, pParent=0x562f76975a70) at svx/source/dialog/_bmpmask.cxx:348 Caolán: do we expect a GtkGrid or a GtkBox here?
I think it should be a GtkBox, so https://gerrit.libreoffice.org/c/core/+/146646 for that. For the original report though, I think the Color Replacer only works on images, i.e. png/jpg graphics and doesn't work on shapes/text. We probably need the original pdf, or a similar one, to confirm that the operation was on an element that the Color replacer doesn't work with. I don't know whether it just can't ever work on whatever the target element was, or if could be somehow enhanced to do whatever the right thing should be.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/bad7bb439461ab0d50b44260c7274b05758d8e1f Related: tdf#153438 this toplevel needs to be a GtkBox It will be available in 7.6.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.
Thank you Caolán for the fix about GtkBox, I don't reproduce the pb with master sources updated today. Heiko/Xisco: any idea what should be the behavior of Color Replacer? I mean, if it can't change color of a pdf, a shape, ... the entry menu should be disabled for these cases. No need to enter the dialog if the "Replace" is always disabled in these cases.
Yes, we should disable the command if no replacement is possible at all. Not sure whether this is easy hackable or we better wait for the color replacer being able to work on drawing objects as requested in bug 123766.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/core/commit/ac6f0c9fd17bd7b306e17fff0b870eef641324ad Related: tdf#153438 this toplevel needs to be a GtkBox It will be available in 7.4.6. 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.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-7-5": https://git.libreoffice.org/core/commit/ccebbe0447329512ca017dc326d276c22f9fa2ef Related: tdf#153438 this toplevel needs to be a GtkBox It will be available in 7.5.1. 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.
Caolan, is this bug solved?
(In reply to BogdanB from comment #9) > Caolan, is this bug solved? I gave a new try on pc Debian x86-64 with master sources updated today, I don't reproduce the assertion but now I reproduce exactly the problem described by Mikayel84
(In reply to Julien Nabet from comment #10) > (In reply to BogdanB from comment #9) > > Caolan, is this bug solved? > > I gave a new try on pc Debian x86-64 with master sources updated today, I > don't reproduce the assertion but now I reproduce exactly the problem > described by Mikayel84 Hmm, I began to debug to add some traces and didn't reproduce the pb. Then I remove debug traces and try again, no reproduce too, so forget my previous comment.
I solved the warning mentioned in comment #2. The original issue probably is still there. I speculate in comment #3 as to the problem. I suspect the color replacer just only works with bitmaps/pictures and not shapes and the pdf is imported as a collection of shapes.