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).
What do people think about lists.plist file?
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?
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.
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.
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.
CPColorList first commit with example color lists that will need expa…
ColorList fixes for cocoa compatability
'Apple' Color list from cocoa
This should be @import <Foundation/CPNotificationCenter.j>
Should change this to isKindOfClass:
A couple of comments (which don't answer any of your question).
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 ;)
Hey Klass, thanks for the comments,
yeah I will change these when I get a moment :)
I put the demo code on a gist / https://gist.github.com/751371
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
Corrections to class type checks
Label: #new. What's next? A reviewer should examine this issue.
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.
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.
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. :)
Well NSColorList is a thing so this should probably be included, yes. :)
And I agree this should probably be used by our colour panel.
For me it's a low priority, I'd rather fix bugs first.
The color panel needs a complete rewrite, it is still using Aristo 1 artwork, that is a higher priority than this.
@aparajita should we close this one now? IMHO it is not going anywhere.
@daboe01 Don't close it, maybe it will be useful someday.