! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
GTK3 color pickers are less useful than the GTK2 variant and inconsistent
Status:
RESOLVED: FIXED
Product:
Xfce4-terminal
Component:
General

Comments

Description Yves-Alexis Perez editbugs 2017-07-14 15:01:36 CEST
Hi,

I had a Debian user report a bug (bugs.debian.org/867888) about the color pickers in xfce4-terminal. Since the switch to GTK3 it seems that there are two color pickers (one for the element colors, the other for the palette colors) and they're both less usefull than the GTK2 one.

You can see more details from the original reporter in the Debian BTS but basically it might be nice to have only one color picker, and have the same features as the GTK2 one.
Comment 1 Igor editbugs 2017-07-14 16:13:05 CEST
0. I agree that gtk3 color picker is less useful that gtk2 one but cannot do anything about this, unfortunately.
1. In fact. there is only one picker used, but it has 2 parts: one allows to select color from a predefined set, and the other one allows to fine tune the color.
2. Palette color picker goes straight to the editor (part 2) as it's unlikely that a user would choose palette color from a preset; see also https://bugzilla.gnome.org/show_bug.cgi?id=756192
3. Individual color pickers (text, cursor, etc) allow bot choosing from a present and fine tuning. Right clicking a color will open the editor for this specific color, as opposed to clicking the "+" button.

So I think all original reporter's issues are addressed, do you agree?
Comment 2 Adam Borowski 2017-07-14 16:31:53 CEST
[Original reporter here.]

That "individual color picker" is massively less useful than the editor.  I can't really see how the GTK palette would be useful.

Populating the preset palette with currently defined colors and some reasonable values instead of using GTK3's stock could be another option, but that's probably not worth the effort, and would still be less ergonomic than just using the editor.

There's also no convenient discoverable way to read or adjust the color.  There's no hint whatsoever the marked color (it's also not visible from beyond the selection marker!) can be right-clicked, and requiring multiple steps to read or adjust it makes any fine tuning tedious.

Thus, I understand why you stick with the crippled GTK3 picker (you'd need to reimplement one yourself), but I'd still urge you to at least consistently use the "editor" picker in both cases.
Comment 3 Igor editbugs 2017-07-14 16:57:20 CEST
Hi Adam, thanks for elaborating your request!

I do, however, use color picker, in fact even more often than fine tuning, so I wouldn't like to get rid of it.
But I can understand your confusion about color dialog and the palette - I'm also not sure how it can be useful.

Since you like editing colors - you know you can put hex value directly to ~/.config/xfce4/terminal/terminalrc, right?
Comment 4 Igor editbugs 2017-07-14 17:00:44 CEST
BTW, can you give an example of a color chooser you're happy with (leaving aside gtk2 dialog)?
Comment 5 Adam Borowski 2017-07-16 00:15:07 CEST
> you know you can put hex value directly to ~/.config/xfce4/terminal/terminalrc, right?

Uhm, what -- xfce4-terminal keeps watching the config file and cleanly reloads it?  Good to know, but that's neither documented nor discoverable, I'd expect most people believe what I did, that you need to restart the program, which is pretty unfun if you have 30+ tabs in multiple windows.  Could you please document this?  A remark in the manpage that the config file is inotify-watched would do the trick.


As for interface I'd prefer:
my types would be satisfied by just being able to write, read and adjust RGB/hex colors, as long as there's immediate feedback, so I can judge whether the color looks right or needs to be made brighter/darker/whatever.

(Having the config file open in an editor and repeatedly saved would do the trick, had this functionality not be a hidden easter egg.)

As for what an ordinary user would want, I'm not sure.  The RGB color space isn't that good -- for some of its flaws, you can play with my https://github.com/kilobyte/vtgamma (works on VT and on certain terminals, xfce4-terminal included): merely jacking up blue in RGB is pretty limited, not even adequate for doing what an user would expect.

Thus, if you don't have the time to implement a nice color picker, even the current "editor" one would be acceptable, as it's primary clicky-clicky way operates in HSV which is more intuitive, with RGB hex being readily available.
Comment 6 Igor editbugs 2017-07-17 20:13:38 CEST
(In reply to Adam Borowski from comment #5)
> > you know you can put hex value directly to ~/.config/xfce4/terminal/terminalrc, right?
> 
> Uhm, what -- xfce4-terminal keeps watching the config file and cleanly
> reloads it?  Good to know, but that's neither documented nor discoverable,
> I'd expect most people believe what I did, that you need to restart the
> program, which is pretty unfun if you have 30+ tabs in multiple windows. 
> Could you please document this?  A remark in the manpage that the config
> file is inotify-watched would do the trick.
That's a good idea, thanks! I will update the man page.

> As for interface I'd prefer:
> my types would be satisfied by just being able to write, read and adjust
> RGB/hex colors, as long as there's immediate feedback, so I can judge
> whether the color looks right or needs to be made brighter/darker/whatever.
> 
> (Having the config file open in an editor and repeatedly saved would do the
> trick, had this functionality not be a hidden easter egg.)
> 
> As for what an ordinary user would want, I'm not sure.  The RGB color space
> isn't that good -- for some of its flaws, you can play with my
> https://github.com/kilobyte/vtgamma (works on VT and on certain terminals,
> xfce4-terminal included): merely jacking up blue in RGB is pretty limited,
> not even adequate for doing what an user would expect.
> 
> Thus, if you don't have the time to implement a nice color picker, even the
> current "editor" one would be acceptable, as it's primary clicky-clicky way
> operates in HSV which is more intuitive, with RGB hex being readily
> available.
What if I add an ability to directly open color editor by, say, Ctrl+click. Meaning, left click would still open a color chooser dialog, and Ctrl+click would go to the editor, as if you clicked and then selected "Customize".
What do you think?
Comment 7 Adam Borowski 2017-07-17 20:30:04 CEST
I doubt a yet another undiscoverable feature would be a good idea, documented or not.  Thus, I'd suggest a consistent behaviour for both palette and special colors.  Ctrl+click to use different pickers would be reasonable only if the hint that you can do so is written right on the dialog -- such as a remark "Ctrl-click for editor".  The "Compatibility" tab already has a similar explanation, and it's long-winded rather than four words.
Comment 8 Igor editbugs 2017-07-17 20:36:39 CEST
(In reply to Adam Borowski from comment #7)
> I doubt a yet another undiscoverable feature would be a good idea,
> documented or not.  Thus, I'd suggest a consistent behaviour for both
> palette and special colors.
No, I won't remove the ability to use color picker dialog - as I've said, I actually use it sometimes.

> Ctrl+click to use different pickers would be
> reasonable only if the hint that you can do so is written right on the
> dialog -- such as a remark "Ctrl-click for editor".  The "Compatibility" tab
> already has a similar explanation, and it's long-winded rather than four
> words.
Yes, I meant to have a note on the "Colors" tab.
Comment 9 Adam Borowski 2017-07-17 20:39:53 CEST
By "undiscoverable feature" I meant ctrl-click doing something different.  With a note either way sounds acceptable.

A much better way would be to have a preset palette and the editor in one dialog, but that would require coding that would take to much of your time.
Comment 10 Igor editbugs 2017-07-17 20:41:53 CEST
(In reply to Adam Borowski from comment #9)
> By "undiscoverable feature" I meant ctrl-click doing something different. 
> With a note either way sounds acceptable.
OK.

> A much better way would be to have a preset palette and the editor in one
> dialog, but that would require coding that would take to much of your time.
Yes, both your statements are true. Patches are always welcome, though :)
Comment 11 Igor editbugs 2017-07-18 17:54:40 CEST
Fixed by https://git.xfce.org/apps/xfce4-terminal/commit/?id=976a79566b759997db66c916238b9e8349ca4728

Again, thanks for bringing this up, Adam!

Bug #13715

Reported by:
Yves-Alexis Perez
Reported on: 2017-07-14
Last modified on: 2017-07-18

People

CC List:
1 user

Version

Attachments

Additional information