4 ms·

The colour swatch honestly seems much more functional in the old version, with the ability to store custom colours, specify hue, saturation and luminosity etc.

The colour swatch honestly seems much more functional in the old version, with the ability to store custom colours, specify hue, saturation and luminosity etc. The new swatch is frankly neutered down. Apart from that the other changes seem okay.

cytzol 7y ago
I agree — I prefer the old colour picker, too. Not only is it more functional, but it's the standard colour picker! If you've used any other Windows program that uses it, even if it was Paint in Windows 95, you already know how it works. I don't mind people trying to re-invent the wheel, but I'm getting tired of having to use a dozen different interfaces for the same task.
- 52-6F-62 7y ago
  I generally agree. I think the only thing I do like is that the new picker appears to be locally attached instead of a separate dialog that is called out and not closed once a selection is made (at least that's the behaviour on mac. I'm not sure if that's been the same recently on Windows)
einr 7y ago
Fun fact: the old colour picker is literally unchanged since Windows 95 (https://guidebookgallery.org/pics/gui/interface/dialogs/colourselector/win95.png https://guidebookgallery.org/pics/gui/interface/dialogs/colo...), complete with the really awkward use of a pipe character as separator between "color" and "solid" (which was used for the closest non-dithered colour match back when we had 4- and 8-bit displays) And to this day, 24 years later, adding custom colours is bugged. It does not "add" colours, it overwrites the first colour in the list. EDIT: to clarify, the above is only true if you exit the dialog and then return to it. It has no concept of previously defined custom colors, it just overwrites whatever you had before, instead of appending to the list. All that having been said, yes, it does appear to be better and more functional than the new proposal.
- Jaruzel 7y ago
  > It does not "add" colours, it overwrites the first colour in the list. It's not bugged. It's just non-obvious. Select the empty custom colour first, then select from the colour box the colour you want to add, then select 'add to custom colours'. Simple really. /s
  - einr 7y ago
    It's actually somewhat more complicated than that even: clicking an "empty" custom colour (I put "empty" in quotes because it actually has no concept of empty, they're just white -- it keeps track of how many colours you've added since opening the dialog but it does not know if the colors you're overwriting are "empty" or not) selects the starting point where you want to start overwriting the list. So clicking multiple times will keep overwriting your colors, you just get to choose your starting point. So there is kind of a way to use it but it is non-intuitive and backwards as all heck. What the "add" button does, then: 1. overwrite colors step by step in the list (with no undo), 2. in order from top to bottom and then left to right, 3. starting at the most recently clicked custom color, 4. or at the first color in the list if no custom color has been clicked since opening the dialog Easy! :)
  - machinecoffee 7y ago
    I cannot tell you how long I've spent frustratingly re-discovering this fact over the years and different Windows versions.
- pedrow 7y ago
  That wasn't a great leap from Windows 3.0, either (https://guidebookgallery.org/pics/gui/interface/dialogs/colourselector/win30.png https://guidebookgallery.org/pics/gui/interface/dialogs/colo...)
  - dfox 7y ago
    This screenshot shows only the right part of the color selector dialog, which is otherwise exactly same as the W95+ version. CHOOSECOLOR.Flags has few bits that determine which variant is shown, and this particular variant is not documented in current winapi docs. I believe that this version is only used by Windows 3.x Color control panel applet. [Edit: and as this dialog is present in Windows 3.0 it almost certainly isn't implemented by same code as Color Dialog from Common Dialog library, because Common Dialogs were introduced in Windows 3.1] [Edit2: when I think about it probably the only common dialog that actually changed since W3.1 is Print Dialog. Other changes to the library were implemented as adding new dialog types. Notably the ComCtl/COM based W95 file/folder dialogs, which actually aren’t API compatible with previous versions, because they deal in shell objects (ie. ItemIDLists) and not in filenames. (This is also probably the reason why various parts of Windows Setup use really weird looking directory selection dialog)]

cytzol 7y ago

I agree — I prefer the old colour picker, too. Not only is it more functional, but it's the standard colour picker! If you've used any other Windows program that uses it, even if it was Paint in Windows 95, you already know how it works. I don't mind people trying to re-invent the wheel, but I'm getting tired of having to use a dozen different interfaces for the same task.

52-6F-62 7y ago
I generally agree. I think the only thing I do like is that the new picker appears to be locally attached instead of a separate dialog that is called out and not closed once a selection is made (at least that's the behaviour on mac. I'm not sure if that's been the same recently on Windows)

einr 7y ago

Fun fact: the old colour picker is literally unchanged since Windows 95 (https://guidebookgallery.org/pics/gui/interface/dialogs/colourselector/win95.png https://guidebookgallery.org/pics/gui/interface/dialogs/colo...), complete with the really awkward use of a pipe character as separator between "color" and "solid" (which was used for the closest non-dithered colour match back when we had 4- and 8-bit displays) And to this day, 24 years later, adding custom colours is bugged. It does not "add" colours, it overwrites the first colour in the list. EDIT: to clarify, the above is only true if you exit the dialog and then return to it. It has no concept of previously defined custom colors, it just overwrites whatever you had before, instead of appending to the list. All that having been said, yes, it does appear to be better and more functional than the new proposal.

Jaruzel 7y ago
> It does not "add" colours, it overwrites the first colour in the list. It's not bugged. It's just non-obvious. Select the empty custom colour first, then select from the colour box the colour you want to add, then select 'add to custom colours'. Simple really. /s
- einr 7y ago
  It's actually somewhat more complicated than that even: clicking an "empty" custom colour (I put "empty" in quotes because it actually has no concept of empty, they're just white -- it keeps track of how many colours you've added since opening the dialog but it does not know if the colors you're overwriting are "empty" or not) selects the starting point where you want to start overwriting the list. So clicking multiple times will keep overwriting your colors, you just get to choose your starting point. So there is kind of a way to use it but it is non-intuitive and backwards as all heck. What the "add" button does, then: 1. overwrite colors step by step in the list (with no undo), 2. in order from top to bottom and then left to right, 3. starting at the most recently clicked custom color, 4. or at the first color in the list if no custom color has been clicked since opening the dialog Easy! :)
- machinecoffee 7y ago
  I cannot tell you how long I've spent frustratingly re-discovering this fact over the years and different Windows versions.
pedrow 7y ago
That wasn't a great leap from Windows 3.0, either (https://guidebookgallery.org/pics/gui/interface/dialogs/colourselector/win30.png https://guidebookgallery.org/pics/gui/interface/dialogs/colo...)
- dfox 7y ago
  This screenshot shows only the right part of the color selector dialog, which is otherwise exactly same as the W95+ version. CHOOSECOLOR.Flags has few bits that determine which variant is shown, and this particular variant is not documented in current winapi docs. I believe that this version is only used by Windows 3.x Color control panel applet. [Edit: and as this dialog is present in Windows 3.0 it almost certainly isn't implemented by same code as Color Dialog from Common Dialog library, because Common Dialogs were introduced in Windows 3.1] [Edit2: when I think about it probably the only common dialog that actually changed since W3.1 is Print Dialog. Other changes to the library were implemented as adding new dialog types. Notably the ComCtl/COM based W95 file/folder dialogs, which actually aren’t API compatible with previous versions, because they deal in shell objects (ie. ItemIDLists) and not in filenames. (This is also probably the reason why various parts of Windows Setup use really weird looking directory selection dialog)]