[Bug 169505] RGB, HSB, CMYK textboxes gone from color picker dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=169505 Michael Weghorn changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|[email protected] |[email protected] |desktop.org | --- Comment #13 from Michael Weghorn --- (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 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 169505] RGB, HSB, CMYK textboxes gone from color picker dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=169505 V Stuart Foote changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #12 from V Stuart Foote --- 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. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 169505] RGB, HSB, CMYK textboxes gone from color picker dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=169505 --- Comment #11 from Eyal Rozenberg --- (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. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 169505] RGB, HSB, CMYK textboxes gone from color picker dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=169505 --- Comment #10 from Telesto --- (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) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 169505] RGB, HSB, CMYK textboxes gone from color picker dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=169505 Heiko Tietze changed: What|Removed |Added Keywords|needsUXEval, regression | CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org --- Comment #9 from Heiko Tietze --- 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 are receiving this mail because: You are the assignee for the bug.
[Bug 169505] RGB, HSB, CMYK textboxes gone from color picker dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=169505 --- Comment #8 from Telesto --- 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? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 169505] RGB, HSB, CMYK textboxes gone from color picker dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=169505 --- Comment #7 from Eyal Rozenberg --- (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. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 169505] RGB, HSB, CMYK textboxes gone from color picker dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=169505 --- Comment #6 from Heiko Tietze --- (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 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 169505] RGB, HSB, CMYK textboxes gone from color picker dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=169505 --- Comment #5 from Michael Weghorn --- (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. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 169505] RGB, HSB, CMYK textboxes gone from color picker dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=169505 Eyal Rozenberg changed: What|Removed |Added Blocks||99525 --- Comment #4 from Eyal Rozenberg --- (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. Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=99525 [Bug 99525] [META] Enhance Draw's DTP (Desktop Publishing) capabilities -- You are receiving this mail because: You are the assignee for the bug.
[Bug 169505] RGB, HSB, CMYK textboxes gone from color picker dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=169505 V Stuart Foote changed: What|Removed |Added CC||[email protected] --- Comment #3 from V Stuart Foote --- 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). -- You are receiving this mail because: You are the assignee for the bug.
[Bug 169505] RGB, HSB, CMYK textboxes gone from color picker dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=169505 Eyal Rozenberg changed: What|Removed |Added OS|All |Linux (All) CC||libreoffice-ux-advise@lists ||.freedesktop.org, ||[email protected] Keywords||needsUXEval --- Comment #2 from Eyal Rozenberg --- Ok, this happens with GTK3. Apparently, we downgraded our color picker to Gtk3's, in: https://bugs.documentfoundation.org/show_bug.cgi?id=167669 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 169505] RGB, HSB, CMYK textboxes gone from color picker dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=169505 --- Comment #1 from Eyal Rozenberg --- 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 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 169505] RGB, HSB, CMYK textboxes gone from color picker dialog
https://bugs.documentfoundation.org/show_bug.cgi?id=169505 Eyal Rozenberg changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=16 ||7669 -- You are receiving this mail because: You are the assignee for the bug.
