Colors Beta

[Tyler Eich]

Colors 2.0 is currently in the works. Improvements include:

• Speed (written in Objective-C; near-instantaneous results)
• Full support for NSColor and UIColor
• Better preview images (uses a different, higher-contrast transparency background)
• ⌘C will copy the result's text
• Opacity slider in the OS X color panel
• Hotkey for revealing the OS X color panel

Download • View on Github

 

Looking for the stable release? Check out the main Colors thread

 

You can run the beta parallel to the stable release; it uses a different BundleID (until v2.0 is stable, at least). Beta testing is strictly voluntary, with no obligation to myself or the beta tester.

I'm mainly trying to stabilize the code (e.g. removing bugs, fixing performance issues, etc.), but feature requests are welcome!

Here are some images of the workflow in action:



And the workflow editor:


Cheers, and many thanks for your help

Edited January 27, 2014 by Tyler Eich

[Florian]

What is to be gained here?

[Tyler Eich]

What is to be gained here?

 

Beta testing is strictly voluntary.

 

Workflow improvements include speed, ability to ⌘C results, and opacity slider in OS X color panel.

[Tyler Eich]

Update released: fixes an issue with [NSColor colorWithDeviceHue: ... ]; inputs.

[twinpeaks]

What is to be gained here?

@Florian, straight to the point while still confusing! What is to be gained from the workflow or gained from beta testing? Either way, I needed the laugh.

- You gain a better workflow, maybe someone who can provide feedback and fixes on your workflows along with some good karma. 

 

@ Tyler Eich - I think you blew everyone away with colors 1.0, I am glad to see your challenging yourself and not resting on your laurels so to speak. +1 for sharing the results of your hard work with us and even allowing open participation for sought after features, those which you haven't found a use case for at least. This workflow takes the cake for number of "connectors," even the guts are aesthetically pleasing. Again, thank you for keeping us leeches in your thoughts and I'll attempt to give some feedback if anything appears out of order, both appearance wise and functionality.

[Florian]

@Florian, straight to the point while still confusing! What is to be gained from the workflow or gained from beta testing? Either way, I needed the laugh.

- You gain a better workflow, maybe someone who can provide feedback and fixes on your workflows along with some good karma. 

 

Ah ah ! Don't get me wrong, I love beta testing. What I was asking was about the new version itself, not from beta testing.

 

And yeah you're right, v1.0 was indeed awesome.

[Tyler Eich]

@twinpeaks @Florian Thanks guys! I'm happy you liked v1.

In true Alfred spirit, I want this rewrite to greatly improve the existing workflow. Though bug fixes and polish are the focus, feature requests are always welcome

[Tyler Eich]

Update released: fixes an issue with RGBA and HSLA outputs. I originally forgot the 'a' (e.g. rgba(255, 0, 0, 0.5)) in the format string, meaning invalid CSS notations.

[greghoch]

Great that you keep improving the workflow! Is there any way to exclude '[ns', 'ns', '[ui' and 'ui'? Never using that and prefer a more concise display.

[Tyler Eich]

Great that you keep improving the workflow! Is there any way to exclude '[ns', 'ns', '[ui' and 'ui'? Never using that and prefer a more concise display.

 

At the moment, there isn't

 

I did consider this during development. I ultimately came to two options:

• Create multiple workflows, one for CSS, one for NSColor, one for UIColor. Let the workflow scan the 'info.plist' in every workflow folder, looking for the other workflows. (For example, if the CSS workflow is installed, it would look for the Objective-C workflows. If not found, it would return only CSS results. If found, it would return additional results according to that workflow.)
• Create one workflow that intelligently sorts results before Alfred learns your preferences. (For example, for each input listed, the results will be ordered as follows (by default; Alfred will sort them into your preferred order as you use them)):
  • 'rgb 200 70 80'
    • CSS
    • NSColor
    • UIColor
  • 'ns .1 .2 .5'
    • NSColor
    • UIColor
    • CSS
  • 'ui hue .8 .7 .4'
    • UIColor
    • NSColor
    • CSS

I opted for the second choice because it allowed me to put the hotkey into a single workflow. If there were multiple workflows, I'd need to figure out how to handle the multiple hotkeys. The multiple workflows would be messier.

 

I'm open to recommendations, especially if more people say they prefer a 'more concise display'. It would be more work, but it might be fun

Edited January 6, 2014 by Tyler Eich

[greghoch]

What's about including all the colors by default (as you have done) and providing an option that allows users to exclude things like 'UIColor'? I always thought the way Alfred manages settings for workflows is not very good but I think there are several solutions out there.

[Tyler Eich]

What's about including all the colors by default (as you have done) and providing an option that allows users to exclude things like 'UIColor'? I always thought the way Alfred manages settings for workflows is not very good but I think there are several solutions out there.

 

Hmm...It's not a bad idea. Several other developers have done this.

 

Pros and cons of each system:

• Always return all results, sorted — Good
  • Pro: Easy to maintain
  • Pro: 'Just works'
  • Con: May return more results than necessary; bad for some users' aesthetic
• Separate functions into multiple workflows — Too many disadvantages
  • Pro: Unnecessary results are excluded
  • Pro: Unnecessary script filters are excluded
  • Con: More work to maintain
  • Con: Larger workflows (each one would work independently, so each would contain the binary)
• Configurable workflow settings — Best choice
  • Pro: Easy to maintain
  • Pro: 'Just works', no extra work necessary
  • Pro: Allows user to disable results (s)he doesn't want
  • Con: Script filters are left behind; messy workflow

 

At this point, I know I won't use multiple workflows. Too many cons for too few/insignificant pros.

 

A configurable workflow appears to be the best option. The extra script filters should return results as well. For example, a user disables 'NSColor' and 'UIColor' results. The user types 'ns 0.3 1 .9' into Alfred; Colors processes this input as an NSColor, but still returns only CSS colors (since the user doesn't care about anything else). Simple to code, and flexible for the end user.

 

Any thoughts/confirmations are welcome

Edited January 7, 2014 by Tyler Eich

[Tyler Eich]

I need help from someone with a knowledge of Objective-C, namely, XIB files

 

I created a settings dialog for Colors, but I don't know how to use it in my implementation file. I need this interface to:

• Open the settings dialog when the binary receives 'preferences' as the argv
• Connect the checkboxes in said dialog to a plist file, able to be read by the colors binary

If you want to take a stab, please fork the objective-c branch on my Github repo. Any help is, as always, greatly appreciated

[rice.shawn]

 

A configurable workflow appears to be the best option. The extra script filters should return results as well. For example, a user disables 'NSColor' and 'UIColor' results. 

 

Sounds like a good plan. Maybe just make it so there is a list of check boxes that the user sets. Since you're doing it in xcode, you might be able to code that. Otherwise, you could do a less elegant version by grabbing the config file applescript setup from my Caffeinate workflow.