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.