Currently, LibreOffice implements its own color picker dialog. However, the GTK and Qt UI toolkits that are used on Linux provide native color picker dialogs: * GTK: GtkColorChooserDialog, https://docs.gtk.org/gtk3/class.ColorChooserDialog.html * Qt: QColorDialog, https://doc.qt.io/qt-6/qcolordialog.html I suggest to switch to using these dialogs for the GTK and Qt based VCL plugins on Linux. Using these will provide better integration and a more uniform experience across applications. It also adds the ability to pick an existing color from any pixel on screen, which the LO dialog doesn't support (and which would presumably require using some desktop portal to get access). Steps to reproduce: 1) start LO Writer with the gtk3 or qt6 VCL plugin on Linux 2) in the toolbar, click on the small arrow of the "Font color" toolbar item 3) click on the "Custom Color" button Actual result: The custom LO color chooser dialog shows up. There is no way to use a color picker to select an existing color from a pixel on screen. Expected result: The native toolkit color chooser dialog should show up, allowing to pick the color from a pixel on screen. Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 8b60950947e8017b1f0b30538b6ef9a3bab51bee CPU threads: 32; OS: Linux 6.12; UI render: default; VCL: gtk3 Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: CL threaded Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 8b60950947e8017b1f0b30538b6ef9a3bab51bee CPU threads: 32; OS: Linux 6.12; UI render: default; VCL: kf5 (cairo+wayland) Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: CL threaded
I'm working on this.
Pending change series: https://gerrit.libreoffice.org/c/core/+/188345
OK, not opposed. Gut how will the "native" calls for 'Custom Color...' dialog integrate to the Pallet widget, guess it just swaps the target for the button. But then will the new 'custom' color get written back to the 'Document colors' pallet and also show on the 'Recent' swatches on the pallet widget? And will this create a documentation hole needing comment? [1] =-ref-= [1] https://help.libreoffice.org/25.8/en-US/text/shared/optionen/01010501.html?HID=cui/ui/colorpickerdialog/dialog-action_area1#bm_id3151211
Created attachment 201994 [details] Screencast for gtk3 and qt6 with Gerrit change series up to https://gerrit.libreoffice.org/c/core/+/188345 (PS 1) in place
(In reply to V Stuart Foote from comment #3) > OK, not opposed. Gut how will the "native" calls for 'Custom Color...' > dialog integrate to the Pallet widget, guess it just swaps the target for > the button. But then will the new 'custom' color get written back to the > 'Document colors' pallet and also show on the 'Recent' swatches on the > pallet widget? This indeed only replaces the dispayed dialogs themselves as "getters" for a color, i.e. anything using the color (including the logic to store them as recently used color,...) should be unaffected. attachment 201994 [details] is a screencast showing the behavior with gtk3 (first) and qt6 (second) with the pending change series in place. As can be seen, the selected color is present e.g. in the "Recent" section of the font color popup. > > And will this create a documentation hole needing comment? [1] > > =-ref-= > [1] > https://help.libreoffice.org/25.8/en-US/text/shared/optionen/01010501. > html?HID=cui/ui/colorpickerdialog/dialog-action_area1#bm_id3151211 Good point, thanks! That will indeed need to be updated to mention that toolkit/platform-specific dialogs may be used instead of the LibreOffice one. If nobody has any idea at hand yet, I can think about it and try to come up with a suggestion.
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/dae9472b27914807ec08062e8293a091e90cffb6 tdf#167669 weld: Introduce weld::ColorChooserDialog It will be available in 26.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/ffb02496c5c7e11eacb9f0d369237ef38d7013dc tdf#167669 gtk: Extract helper to convert VCL to GDK color It will be available in 26.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/c0721600c294ebc46217477a80a8eea34609e4bc tdf#167669 gtk: Use native GtkColorChooserDialog It will be available in 26.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/072010169bb4668f3c624a9f379e8a79e4e3e57a tdf#167669 tdf#130857 qt: Use native QColorDialog It will be available in 26.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.
Can you please check if tdf#167716 is reproducible and related? Bibisect repo is not updated to check myself.
(In reply to Timur from comment #10) > Can you please check if tdf#167716 is reproducible and related? > Bibisect repo is not updated to check myself. Commented there, but the dialog being too large seems unrelated to me as only the case where a separate color dialog gets shown should behave differently with the commits done in the context of this ticket.