The unpublished com::sun::star::cui::ColorPicker and
com::sun::star::cui::AsynchronousColorPicker UNO services
were previously used to be able to use ColorPickerDialog
(implemented in cui) from svtools.
That's no longer the case since
commit 0905c23676
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Fri Jun 13 18:27:09 2025 +0200
Stop using UNO abstraction for color picker
, so drop the now unused services and the ColorPicker
class that implemented them.
Change-Id: I9264707df57e46192a393f6736257c413e5d9831
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186538
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
which means I can remove one usage of gb_Library_set_plugin_for, which
is blocking linking the cui module into --enable-mergelibs=more
Change-Id: Ic6cd48377627f94747037c7247a1cd398738b390
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163820
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
901360967d "Combine
com.sun.star.cui.[Asynchronous]ColorPicker implementation decls" had assumed
that:
"f54ccf09a5073b6e544c976da68de0c9fc0bdf6c "Make Custom Color Picker dialog
async" had added the additional com.sun.star.cui.AsyncColorPicker implementation
entry (later renamed to com.sun.star.cui.AsynchronousColorPicker) for the same
actual C++ implementation, presumably out of confusion. (The implementation
name "com.sun.star.cui.AsynchronousColorPicker" appears to not be mentioned
anywhere else than in this .component file, so it shouldn't matter to drop it.)"
But turns out that things are even more confused there than I'd initially
thought they would be: The names com.sun.star.cui.ColorPicker and
com.sun.star.cui.AsynchronousColorPicker are actually UNOIDL service names as
declared in offapi/com/sun/star/cui/[Asynchronous]ColorPicker.idl. And the
implemenation is accessed via css::cui::ColorPicker::createWithParent and
css::cui::AsynchronousColorPicker::createWithParent in
svtools/source/dialogs/colrdlg.cxx. Which, in the past, happened to work,
because creating a service X also looks for registered implementation names X,
if it does not find a registered implemenation that advertises service name X.
For com.sun.star.cui.AsynchronousColorPicker it happened to work until I removed
that implemenation name from cui/util/cui.component...
A minimal fix for that mess is to make that implementation also advertise the
com.sun.star.cui.AsynchronousColorPicker service name (the
com.sun.star.cui.ColorPicker service name is still found, unconventionally, via
the implementation name). Whether the two additional service names
com.sun.star.ui.dialogs.ColorPicker and
com.sun.star.ui.dialogs.AsynchronousColorPicker are relevant in any way I don't
know---just leave them alone for now.
Change-Id: I37f4fd5b45b97ab27275cd377921063d6e0cc096
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152418
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
f54ccf09a5 "Make Custom Color Picker dialog async"
had added the additional com.sun.star.cui.AsyncColorPicker implementation entry
(later renamed to com.sun.star.cui.AsynchronousColorPicker) for the same actual
C++ implementation, presumably out of confusion. (The implementation name
"com.sun.star.cui.AsynchronousColorPicker" appears to not be mentioned anywhere
else than in this .component file, so it shouldn't matter to drop it.)
Change-Id: I80cc4f474d71493fb5bc125d9137595184cc6e96
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150644
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
a side effect of this painfully tricky rework is that we recover an apparently
long lost initial "ON" column in tools->options->appearance
Change-Id: I262feae14e9f8a21f46103e35256687e66a13c7c
Michael Weghorn