Until very recently, the color picker used to have textboxes for entering color values as RGB, HSB or CMYK coordinates/channel values. Now, these textboxes (and section titles) seem to be gone from the dialog. Was this the result of some intentional change? Something which changed "under our feet"? Anyway, we need those textboxes back. They are very important for color picking - no less, if not more, than the square-and-rectangle "swatch" areas.
The color picker textboxes are missing in: Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: d2def868cb3ac5a7e538a911e83d7d907a2ec794 CPU threads: 4; OS: Linux 6.12; UI render: default; VCL: gtk3 Locale: en-IL (en_IL); UI: he-IL Calc: CL threaded but not in: Version: 25.8.1.1 (X86_64) Build ID: 54047653041915e595ad4e45cccea684809c77b5 CPU threads: 4; OS: Linux 6.12; UI render: default; VCL: gtk3 Locale: en-IL (en_IL); UI: en-US Calc: threaded
Ok, this happens with GTK3. Apparently, we downgraded our color picker to Gtk3's, in: https://bugs.documentfoundation.org/show_bug.cgi?id=167669
Is the complaint that we've lost the CMYK color space for setting a color, or that we've increased DE integration by dropping our own color picker for the DE specific flavor. If the latter, so long as we are still maintaining our own color picker, guess the appropriate thing to do would be to follow the 'File Picker' and provide ability selectively use our LO color picker by user choice in user profile (Tools -> Options -> General, or an ExpertConfig only stanza).
(In reply to V Stuart Foote from comment #3) > Is the complaint that we've lost the CMYK color space for setting a color, > or that we've increased DE integration by dropping our own color picker for > the DE specific flavor. As the title says... "RGB, HSB, CMYK textboxes gone from color picker dialog" On GTK we lost RGB, HSB and CMYK; On Qt we lost just CMYK; On Windows and Mac - I don't know. the trigger was the switch to the DE color picker, but the complaint is that we need textboxes for color value control. Many many users need RGB and HSB for sure; and I do believe CMYK has some importance in desktop publishing. Heiko wrote in bug 99525 that: "An outcome of the Draw survey in 2016 was that users apply the program for DTP like operations such as creating flyers, brochures, and posters." so, there's that.
(In reply to Eyal Rozenberg from comment #4) > On GTK we lost RGB, HSB and CMYK; > On Qt we lost just CMYK; > On Windows and Mac - I don't know. On Windows and macOS, LO's custom color picker is currently still used, i.e. no change there. How to continue is certainly up to the UX team to decide. I personally think there is value in integrating well with the platform/desktop environment and use existing platform/UI toolkit dialogs where available, also for consistency across applications - and ideally reporting and addressing any shortcomings upstream, so that LibreOffice and all other projects using that functionality can profit from it. My tdf#167669 comment 18 has some more thoughts on that. One feature the Qt and GTK color dialogs provide that the LO one doesn't is to select a color from an arbitrary pixel on screen. I agree the GTK one is more limited at the moment, though. (RGB values can still be entered in hex form as is often used on the web, but that's not intuitive for everyone.) Potential approaches I can think of: 1) Adding an option to switch between the upstream toolkit and custom LibreOffice dialog, so people can still go back to using the custom LO dialog if they want to (as suggested by Stuart in comment 3). 2) Drop support for GTK and Qt color dialogs again. 3) Leave Qt color dialog in place (as it offers entering RGB, HSV, HTML color code and picking color from screen), but drop use of GTK one for now as it has fewer features. I'd clearly be in favour of 1). In case of 2) or 3), I think it would be good to have clear criteria of what a native color dialog would have to provide in order to be considered "suitable", i.e. it would be "dropping for now", with the possibility to re-enable in case those features are implemented in the upstream dialogs later. 2) would presumably also make it harder to implement tdf#130857 and thus fix tdf#141578 and other issues blocked by tdf#130857. At least last time I looked into it, trying to support the custom LO color dialog with custom Qt widgets resulted in issues that would need further analysis.
(In reply to Michael Weghorn from comment #5) > I personally think there is value in integrating well with the > platform/desktop environment and use existing platform/UI toolkit dialogs... Nothing to add, if you don't like Gtk you should consider another DE. And I see no use case in c0, something like "I need to enter CMYK values because... and don't know how to convert... and cannot use the tool...". Sure, there might be a few experts who need this. But I'm against spoiling clear and simple dialogs for a minority. => WF, first of all as this contradicts bug 167669
(In reply to Heiko Tietze from comment #6) > Nothing to add, if you don't like Gtk you should consider another DE. This is not about what I like or dislike, this is about the functionality we offer our users. And we should not take away functionality that they need just because we're using Gtk. > And I > see no use case in c0, something like "I need to enter CMYK values > because... and don't know how to convert... and cannot use the tool...". Color pickers need numeric entry fields. People both use them directly to enter values, and to consider what they've chosen graphically. > Sure, there might be a few experts who need this. Not "a few experts", but many, and probably most, of the people using the custom color picker in the first place. Otherwise, there are several palettes to choose colors from.
I personally prefer cross-platform dialog consistency above platform/UI toolkit integration. I'm quite platform agnostic. The same application having a different options depending on OS/Desktop is quite frustrating. The (GTK) shortcomings belongs technically upstream (comment 5), true. Question is what to do in the mean time. I tend to opt for using LO color picker by default. If desired a providing the ability for opting for the DE (GTK) integration (Tools -> Options -> General, or an ExpertConfig only stanza). The default can be changed when the GTK color picker being on par with the LibreOffice variant. I'm rather undecided what what the proper answer would be for the QT variant. Should we be strict or somewhat flexible?
This is not our bug. Gnome developers and UI designers have decided to provide a certain workflow likewise Apple does on macOS. We follow the mantra to blend into the OS/DE and avoid wheel inventions.
(In reply to Heiko Tietze from comment #9) > This is not our bug. Gnome developers and UI designers have decided to > provide a certain workflow likewise Apple does on macOS. We follow the > mantra to blend into the OS/DE and avoid wheel inventions. You're moving into slippery slope when using this argument. LibreOffice never feels totally native (workflow or UI wise). It's always been a compromise because of technically limitations or different UI guidelines between desktop environments You're opening a box of Pandora when going all in on: "blend into the OS/DE". You can't dismiss a feature requests with: we are a cross-platform application and we have to opt for compromise For example: Blending into would - entail setting tabbed bar default on Windows and improving - it matching Windows look and feel. There is also not a wheel of inventions here. It was OK until started to use the platform/UI toolkit. So the 'proper' dialog is actually available. It's not gone, it's not used anymore in favor of UI Toolkit. Which doesn't match LibreOffice standards regarding functionality. Sure it's not nice having to workaround the platform/UI toolkit. And ideally it shouldn't be needed. It's frustrating, maybe even infuriating. However making user experience of your app depended outside your control and 'blaming' others for the lack of functionality doesn't seem mature. And well GTK developers might have totally different priority's. It might be a corner case in perspective of a desktop environment, whereas it's more essential for some apps (like LibreOffice)
(In reply to Heiko Tietze from comment #9) > This is not our bug. It is our bug: We made a change to our code, and necessarily functionality disappeared. > Gnome developers and UI designers have decided _We_ decide what functionality LibreOffice users get. If GNOME developers & UI designers decided that, LibreOffice would probably have a few ambiguous monochrome buttons drawn over its title bar, a hamburger menu, and 90% less settings. > We follow the mantra to blend into the OS/DE 1. In term of visual style - yes, somewhat; but in terms of functionality - that's really not the case. 2. You don't even know what DE does. There are multiple desktop environments that are Gtk-based, or neither-Gtk-nor-Qt-based. Some of those DEs are more like GNOME, others - aren't. > and avoid wheel inventions. 1. We already have a wheel: Our color picker. 2. The Gtk wheel is a hexagonal rather than round, so we should use our wheel rather than their wheel.
Setting => NEW and seems accepted UX advice is as in comment 3 and comment 5 option 1) to follow os/DE handling of our custom File picker, and make the custom LibreOffice Color Picker optionally available for all DE. os/DE would control defaults (and yes Gnome has yet again screwed their users as they purge APIs, *that* is not our bug) but users should be able to select the LO custom picker if they prefer greater functionality it offers.
(In reply to V Stuart Foote from comment #12) > Setting => NEW and seems accepted UX advice is as in comment 3 and comment 5 > option 1) to follow os/DE handling of our custom File picker, and make the > custom LibreOffice Color Picker optionally available for all DE. > > os/DE would control defaults (and yes Gnome has yet again screwed their > users as they purge APIs, *that* is not our bug) but users should be able to > select the LO custom picker if they prefer greater functionality it offers. Pending change series in Gerrit: https://gerrit.libreoffice.org/c/core/+/195105
(In reply to Michael Weghorn from comment #13) > Pending change series in Gerrit: > https://gerrit.libreoffice.org/c/core/+/195105 Read through them all, a bit of work for sure--but looks to be the way to restore our custom color picker features as a user may prefer to replace os/DE limits. Thanks Michael!
(In reply to Michael Weghorn from comment #13) > Pending change series in Gerrit: > https://gerrit.libreoffice.org/c/core/+/195105 I couldn't quite understand from the code at the link, but - just to make sure, the OS/DE color picker is opt-in, and our color picker is the default, right?
(In reply to Eyal Rozenberg from comment #15) > I couldn't quite understand from the code at the link, but - just to make > sure, the OS/DE color picker is opt-in, and our color picker is the default, > right? No, the other way around, as is the case with the file picker (system one is default).
(In reply to Michael Weghorn from comment #16) > No, the other way around, as is the case with the file picker (system one is > default). Well, my opinion is that we should default to our color picker, and our file picker - at least with the GTK VCL. After all, the discoverability of the toggle is rather low, so the default choice is what most users will have, whether they like it or not. Why not have the users who want to "blend in with GNOME" go to the trouble of realizing there might be a toggle and searching for it, rather than the users who want want a decent color picker? I realize there is no consensus on this - but I believe users would be better served with the opposite choice of default.
(In reply to Eyal Rozenberg from comment #17) > Well, my opinion is that we should default to our color picker, and our file > picker - at least with the GTK VCL. After all, the discoverability of the > toggle is rather low, so the default choice is what most users will have, > whether they like it or not. Why not have the users who want to "blend in > with GNOME" go to the trouble of realizing there might be a toggle and > searching for it, rather than the users who want want a decent color picker? My take is in comment 5 and the referenced tdf#167669. If you think the default should be switched to the custom LO dialog, could the next UX/design team meeting maybe be a good place for further discussion?
(In reply to Eyal Rozenberg from comment #17) Trend over the years has been to appropriately integrate functionality provided by os/DE native widgets, and to supplement that with our custom controls as an option when we have a better offering. As done with the File manager (First GTK2/3 then KDE then...) So the new 'UseSystemFileDialog' expert config, or the GUI checkbox follow that practice. Even though (for now) our color picker UI is better. Folks preferring can toggle the Expert configuration, or it is available as checkbox in Tools -> Options -> General just like the 'Use LibreOffice Dialogs' for our custom file manager. Tighter os/DE integration is marketable (even if less functional), with bonus of user being able to select alternate should they choose. Reasonable item for release note, and blog content.
(In reply to V Stuart Foote from comment #19) > Tighter os/DE integration is marketable (even if less functional) Try telling people we've decided they should use the GTK file picker, and see how they react. Or think of the feedback we would get if we switched to Sifr as our default icon scheme for the GTK VCL.
(In reply to Eyal Rozenberg from comment #20) > (In reply to V Stuart Foote from comment #19) > > Tighter os/DE integration is marketable (even if less functional) > > Try telling people we've decided they should use the GTK file picker, and > see how they react. Or think of the feedback we would get if we switched to > Sifr as our default icon scheme for the GTK VCL. But we haven't. The whole point to keeping the more functional LO dialog *easily* available, though not default. Some folks won't know any better, some simply won't care and if inclined will locate the UI checkbox in Tools -> Options. Fully discoverable. And, at some point when GNOME gets their act together for gtk5, we move folks to that flavor by default. Michael's work here thusfar sets all that up.
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/6bdcc269420719891f27abeaf5f4b84b370cb591 tdf#169505 Let ColorPickerDialog only subclass weld::GenericDialogController It will be available in 26.8.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/c80637bc429853ea034998fce49b980ef52d76fa tdf#169505 Move HexColorControl from svx to vcl It will be available in 26.8.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/89ad9eec8ba4f0923a3be843a8343646e8870b90 tdf#169505 Move ColorPickerDialog from cui to vcl It will be available in 26.8.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/005d7e91a2f3694cbcec7da367be404795f1ab4c tdf#169505 Drop one level of abstraction for ColorPickerDialog It will be available in 26.8.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/86a04e193376b732bd8827103e1507046efff07b tdf#169505 Use ColorDialog in ColorPicker It will be available in 26.8.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/77c2dc5b69e0bfe8816e8aac3ced3b6478350294 tdf#169505 Add abstract ColorDialogController It will be available in 26.8.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/0b839726d4cb3c54741faa66414f0ad119ddc9f3 tdf#169505 Let ColorPickerDialog subclass ColorDialogController It will be available in 26.8.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/5bb41f2a588caff88b2fd957af9c9e94d8cdf2e0 tdf#169505 Allow disabling native color pickers It will be available in 26.8.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/c0d3205c4686680a6eea00286fa49cc3d51be672 tdf#169505 Add checkbox to enable/disable native color dialog It will be available in 26.8.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.
(In reply to Michael Weghorn from comment #13) > Pending change series in Gerrit: > https://gerrit.libreoffice.org/c/core/+/195105 Merged for master now, backports for 26-2 pending in Gerrit. I'll look into potential adjustments for help/documentation next week. I don't see it from the current discussion so far, but should the UX team should still decide to switch the default, that can still be easily done (and would not be affected by the upcoming string/UI freeze, see https://wiki.documentfoundation.org/ReleasePlan/26.2 ).
(In reply to V Stuart Foote from comment #19) > So the new 'UseSystemFileDialog' expert config, or the GUI checkbox follow That new Expert config stanza should have read 'UseSystemColorDialog' of course.
Michael Weghorn committed a patch related to this issue. It has been pushed to "libreoffice-26-2": https://git.libreoffice.org/core/commit/0b183e801d799e9488b4a1859eaad4af2cab611c tdf#169505 Let ColorPickerDialog only subclass weld::GenericDialogController It will be available in 26.2.0.0.beta2. 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 "libreoffice-26-2": https://git.libreoffice.org/core/commit/383053318ee364cd39620edffc5bc16f26cc8885 tdf#169505 Move HexColorControl from svx to vcl It will be available in 26.2.0.0.beta2. 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 "libreoffice-26-2": https://git.libreoffice.org/core/commit/e96d624e7b0b2db2f76113453cc63731b4808514 tdf#169505 Move ColorPickerDialog from cui to vcl It will be available in 26.2.0.0.beta2. 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 "libreoffice-26-2": https://git.libreoffice.org/core/commit/69449a1ce1a6366ac4677f509d3cd7ba7c11277c tdf#169505 Drop one level of abstraction for ColorPickerDialog It will be available in 26.2.0.0.beta2. 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 "libreoffice-26-2": https://git.libreoffice.org/core/commit/cbfae1c3be2d1cc2ee75f93c8f0dc6d7f26ae5be tdf#169505 Use ColorDialog in ColorPicker It will be available in 26.2.0.0.beta2. 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 "libreoffice-26-2": https://git.libreoffice.org/core/commit/3238177f56fa1bfc0e39bb737f6158893911d352 tdf#169505 Add abstract ColorDialogController It will be available in 26.2.0.0.beta2. 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 "libreoffice-26-2": https://git.libreoffice.org/core/commit/da8ee1416eaceb37ba14598b22eef1fa38b5f9b5 tdf#169505 Let ColorPickerDialog subclass ColorDialogController It will be available in 26.2.0.0.beta2. 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 "libreoffice-26-2": https://git.libreoffice.org/core/commit/41a64827813cba241da052e885ada2d7f8f52536 tdf#169505 Allow disabling native color pickers It will be available in 26.2.0.0.beta2. 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 "libreoffice-26-2": https://git.libreoffice.org/core/commit/911c64072910c19da3bd5e7d38173e651f21e2d2 tdf#169505 Add checkbox to enable/disable native color dialog It will be available in 26.2.0.0.beta2. 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.
(In reply to Michael Weghorn from comment #31) > I'll look into potential adjustments for help/documentation next week. -> https://gerrit.libreoffice.org/c/help/+/195221
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/help/commit/7adc0959ddec5bb8f54e2b773ed4bb9a4e309684 tdf#169505 Mention option to disable native color dialogs
Michael Weghorn committed a patch related to this issue. It has been pushed to "libreoffice-26-2": https://git.libreoffice.org/help/commit/512d120244b638b6d0667024adf00905bda113dd tdf#169505 Mention option to disable native color dialogs