CPColorList #1037

wants to merge 3 commits into


None yet
8 participants

stevegeek commented Dec 16, 2010

Hey guys, here is an implementation of NSColorList for cappuccino (sans file write/delete).

Demo here: http://www.stephenierodiaconou.com/colorlistdemo/
(based on an example in Cocoa Programming for Mac OS X , Hillegass)

I wanted to get some feedback on what should be the format of the ColorLists themselves. In Cocoa ColorLists are stored as bundles in a number of possible formats, so far i have seen either a simple text format or as binary archived objects. Cocoa color lists can be localised and can represent colors in numerous color spaces from what I can tell. Cocoa determines available color lists from the system and user by searching in certain folders (eg /System/Library/Colors/).

For Capp I decided to implement a slightly different plist based format for the lists that encapsulated the colorspace, colors and localised strings, (the localised strings at the moment dont do much as there obv isnt such support in Capp anyway).

The available lists are noted in either the /Colors/lists.plist for framework lists or Colors/lists.plist for app lists. Lists can be either included right in this plist or can simply reference another file to be loaded lazily as required. For each list a dictionary contains the keys "Mode", "Names", "Keys" and "Colors" where Mode is a string representing the color space, "Names" is a dictionary containing the localised key/names pairs, "Keys" is an ordered list of the color keys, and "Colors" is a dictionary of key/array pairs where the array contains the color components for the particular color (as many as needed depending on the Mode).

  1. What do people think about lists.plist file?

  2. At the moment im using XML plist format but I suppose it should detect if the plist is XML or 280N? Does cappuccino have a way to do this automatically?

  3. Archived versions of the lists could be created in advanced as 280N Plists and used, as in Cocoa, but that would need some simple modification of the plist parsing code to detect whether the loaded file is an archived object or a plist in the format described above, and then unarchive the object as appropriate.

  4. The localised strings at the moment dont matter too much, but in general for the future I suppose including them in the plist is not a good idea as the plist size will grow unnecessarily , hence I think that for each language code in "Names" maybe they should also support referencing another file to be loaded if needed.

  5. At the moment I have implemented only 1 color list, the "Apple" colour list. I will implement the rest when the above has been sorted.

Feedback/comments/etc please

stevegeek added some commits Dec 15, 2010

@stevegeek stevegeek CPColorList first commit with example color lists that will need expa…

ColorList fixes for cocoa compatability

Coder fix

Clean up
@stevegeek stevegeek 'Apple' Color list from cocoa
Test fixes

This should be @import <Foundation/CPNotificationCenter.j>

Should change this to isKindOfClass:



klaaspieter commented Dec 22, 2010

A couple of comments (which don't answer any of your question).

  1. Please fix the things you commented about yourself. I believe the pull request system will automatically pick up new commits when you add them to the same branch. (assuming this pull request is based on a separate branch).
  2. Could you add a test project showing an example of how one could use this. I personally have never used with this (nor needed it). I would like to be able to see what this can be used for.
  3. Apple states in their documentation that color lists are used in NSColorPanel would it be hard to make CPColorPanel use this as well?

Like I said, these don't answer any of your other questions. I don't know to much about the archiving / plist parts of Cappuccino. I'll try to get someone who does commenting on this as well ;)


stevegeek commented Dec 22, 2010

Hey Klass, thanks for the comments,

  1. yeah I will change these when I get a moment :)

  2. I put the demo code on a gist / https://gist.github.com/751371

  3. yeah that was going to be the next step, to add the tab to the colorpanel that has the colors by name

The demo code is a simpler version of the demo in Hillegass' book

cappbot commented May 9, 2012

Label: #new. What's next? A reviewer should examine this issue.


ggsato commented May 24, 2012


cappbot commented May 24, 2012

Labels: #needs-review, #new, AppKit, feature. What's next? This issue is pending an architectural or implementation design decision and should be discussed or voted on.


ahankinson commented Feb 15, 2013


cappbot commented Feb 15, 2013

Milestone: Someday. Labels: #needs-review, AppKit, feature. What's next? This issue is pending an architectural or implementation design decision and should be discussed or voted on.


ahankinson commented Feb 26, 2013

Any comments on this one? I think it needs a decision on whether it should be included or not. If a core dev wants to move this forward, I can review the PR for merging issues, style, etc.

Or, if @stevegeek is still around and wants to do that, be my guest. :)


aljungberg commented Feb 26, 2013

Well NSColorList is a thing so this should probably be included, yes. :)


aljungberg commented Feb 26, 2013

And I agree this should probably be used by our colour panel.


aparajita commented Feb 26, 2013

For me it's a low priority, I'd rather fix bugs first.


aparajita commented Feb 27, 2013

The color panel needs a complete rewrite, it is still using Aristo 1 artwork, that is a higher priority than this.


daboe01 commented May 16, 2016

@aparajita should we close this one now? IMHO it is not going anywhere.


aparajita commented May 16, 2016

@daboe01 Don't close it, maybe it will be useful someday.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment