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.
(In reply to Michael Weghorn from comment #5) > 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. First suggestion: https://gerrit.libreoffice.org/c/help/+/189595
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/help/commit/4dc2e7d8dd6a240806c66fe76f56421ea06b27b5 tdf#167669 Mention native color dialogs in help
Does your patch also implement native file picker for gtk4?
(In reply to Heiko Tietze from comment #14) > Does your patch also implement native file picker for gtk4? Yes.
(In reply to Michael Weghorn from comment #15) > (In reply to Heiko Tietze from comment #14) > > Does your patch also implement native file picker for gtk4? > > Yes. Sorry, it doesn't implement a native *file* picker, but a native *color* picker. The native *file* picker has already been implemented earlier.
This change has badly degraded our color picker with GTK3; see 169505. For Qt, it's not so bad, but we have still lost the ability to use CMYK coordinates. Regardless - this has significant UX implications that were not discussed. In fact, it may have non-trivial _accessibility_ implications that I don't see discussed. (In reply to Michael Weghorn from comment #0) > Using these will provide better integration and a more uniform experience > across applications. That is a positive thing if the experience is positive. But GTK is known to provide a very _poor_ user experience in various respects, most especially with its common dialogs. We are already suffering from their terrible File picker; we should not also have to suffer their color picker. > 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). That is a neat ability (albeit not trivial to discover). However, this can be worked around with not much effort using a screenshot and an image manipulation program; or we could, in principle, get access the same way the Gtk widget gets access. Granted, that would mean more work; but we should not lose important functionality for a merely nice-to-have feature. As for the Qt case - is this feature present there?
(In reply to Eyal Rozenberg from comment #17) > This change has badly degraded our color picker with GTK3; see 169505. For > Qt, it's not so bad, but we have still lost the ability to use CMYK > coordinates. > > Regardless - this has significant UX implications that were not discussed. > In fact, it may have non-trivial _accessibility_ implications that I don't > see discussed. Do you have any particular negative accessibility implications in mind? If the toolkit-provided dialogs have (a11y or other) issues, I think it would generally be the best approach to report and fix those issues upstream. For a11y of the Qt dialog, I did that for things I noticed in an a11y test, see * https://bugreports.qt.io/browse/QTBUG-141571 * https://bugreports.qt.io/browse/QTBUG-141666 * https://codereview.qt-project.org/c/qt/qtbase/+/687340 * https://codereview.qt-project.org/c/qt/qtbase/+/687341 * https://codereview.qt-project.org/c/qt/qtbase/+/687342 * https://codereview.qt-project.org/c/qt/qtbase/+/688342 * https://codereview.qt-project.org/c/qt/qtbase/+/688343 * https://codereview.qt-project.org/c/qt/qtbase/+/688344 * https://codereview.qt-project.org/c/qt/qtbase/+/688345 If there are remaining issues, I think they could/should ideally be handled similarly, so that users profit from good/accessible dialogs in all applications using those. (Having consistency is also one important aspect when it comes to a11y in general, so I think using the same dialog for the same task "selecting a color" in different applications by itself is a good thing in that regard - but of course depends on that dialog being accessible in order to be actually useful.) I don't claim the GTK and Qt dialogs are perfect, but think those toolkits would be a good place to improve things when/where needed. The LO one isn't perfect either, e.g. the 2 colorful (non-spinbox) controls in the dialog are not keyboard-accessible and there's quite a lag until the color gets updated when the 2nd control is used with the mouse. > (In reply to Michael Weghorn from comment #0) > > Using these will provide better integration and a more uniform experience > > across applications. > > That is a positive thing if the experience is positive. But GTK is known to > provide a very _poor_ user experience in various respects, most especially > with its common dialogs. We are already suffering from their terrible File > picker; we should not also have to suffer their color picker. If you think their dialogs are terrible, do you think discussing improvements would be something worth discussing with GTK upstream? > > 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). > > That is a neat ability (albeit not trivial to discover). However, this can > be worked around with not much effort using a screenshot and an image > manipulation program; or we could, in principle, get access the same way the > Gtk widget gets access. Granted, that would mean more work; but we should > not lose important functionality for a merely nice-to-have feature. > > As for the Qt case - is this feature present there? Yes, see the "Pick Screen Color" button in screencast attachment 201994 [details], at about 00:27. Of course, it's always possible to implement arbitrarily complex things in LibreOffice itself, but I think it's generally useful to use existing logic in UI toolkits where possible (like their implementation for interacting with desktop portals on Wayland and making sure this will keep working in the future,...). (Somewhat similar to the workaround you suggest for the screen color picker, but in my opinion a bit easier: For using CMYK values, a workaround with the GTK or Qt versions could be to use a converter from CMYK to RGB/hex, and enter those values in the LO/toolkit dialog then, or use the screen color picker to select that color entered elsewhere.) In any case, probably best to continue the discussion in tdf#169505 to have it in one place. (There are certainly pros and cons to either approach. Let's get some input from the UX/design team there.)