Hi,
I just thought about a color picker in tm_dialog. But do we need it?
Background: I simply added to TextMate's MainMenu.nib Menu the following: Format Font Show Fonts Show Colors Text Align Left Center Justify Align Right
without key bindings.
If I invoke 'Show Colors' in TM a color palette will be displayed, I can choose a color, and finally I can drag&drop the color which is shown in the rectangle to a document in TM, and I get e.g. #FF33DC. This should work for HTML, CSS, etc. stuff properly. The same for Show Fonts. I can drag&drop the name for instance.
All items under Format>Text also work but with the limitation that all commands interact only with the current size of the document's window. [This, of course, is ONLY a side note ;)]
OK.
If someone needs a tm_dialog nib which asks the user, among others, to choose some colors, one could such a nib by using NSColorWell easily. I wrote a routine for tm_dialog to parse the result dictionary for NSColor objects. If there are some the routine will replace the content of these dictionary's keys with an array containing the following strings: {example for red; 'color' is the selection value in the nib} <key>color</key> <array> <string>#FF0000</string> <string>255 0 0</string> </array>
Each programming language I know can use at least one of the color's representation for further calculations. It would be easy to add also the values for the HSB and CMYK models.
So my question is: Is there something which I didn't consider?
Regards,
Hans
Oops. I forgot something.
One could write a default ColorPicker.nib like 'RequestString' to make it easier for users who don't like to write nibs. [It is already done, except for the issue that I didn't find a way to close the color palette if the user closes this ColorPicker .nib]
Hans
On 1. Aug 2007, at 15:30, Hans-Joerg Bibiko wrote:
[...] I wrote a routine for tm_dialog to parse the result dictionary for NSColor objects. If there are some the routine will replace the content of these dictionary's keys with an array containing the following strings: [...]
Sorry, I forgot to address that in a previous letter.
The solution is to specify a value transformer for the binding, which should be: OakStringToColorTransformer
We do that in TODO’s Preferences.nib.
On 1 Aug 2007, at 16:14, Allan Odgaard wrote:
On 1. Aug 2007, at 15:30, Hans-Joerg Bibiko wrote:
[...] I wrote a routine for tm_dialog to parse the result dictionary for NSColor objects. If there are some the routine will replace the content of these dictionary's keys with an array containing the following strings: [...]
The solution is to specify a value transformer for the binding, which should be: OakStringToColorTransformer We do that in TODO’s Preferences.nib.
Yes, I saw it but I have two tiny things to mention: 1) The transformer converts a NSColor "only" to a String à la "#RRGGBB". If this is enough for the color picker's output, fine.
2) I always got an error if I tried to set the color for NSColorWell via -p 'color="#FF0000";'. The error was: NSCFString alphaComponent: selector not recognized. I also tried -p 'color="#FF0000FF";' but no success.
If I copy the same NSColorFromString routine from ValueTransformer.mm and use it for setting the color in Dialog.mm, it works!?
Hans
On 2. Aug 2007, at 10:31, Hans-Joerg Bibiko wrote:
The solution is to specify a value transformer for the binding, which should be: OakStringToColorTransformer We do that in TODO’s Preferences.nib.
Yes, I saw it but I have two tiny things to mention:
- The transformer converts a NSColor "only" to a String à la
"#RRGGBB". If this is enough for the color picker's output, fine.
You mean not supporting the full range of color spaces provided by NSColor?
It is true that this is a lossy (at least irreversible) conversion into the RGB space, for colors specified in some other space. But in practice, the receiver of this color would unlikely be able to handle colors other than RGB colors.
-
Allan Odgaard -
Hans-Joerg Bibiko