[Chandler-dev] Moving color/etc out of ContentCollection

[Alec Flett]

An update:
I just checked in changes that pull the following attributes out of 
collections.py:
- renamable
- color
- outOfTheBoxCollection
- iconName
- iconNameHasKindVariant
- colorizeIcon
- dontDisplayAsCalendar
- displayNameAlternatives

and got rid of the setup() method for ContentCollection. Note that I did 
not get rid of InclusionExclusionCollection's setup() method.. we can 
fix that in another step.

I took pje's suggestion and I moved it into an annotation in 
osaf.usercollections called UserCollection.

 'setup()' became 'ensureColor()'  and is only called by consumers who 
care about color, such as the sidebar and calendar (instead of 
distributing this requirement on anyone who makes a collection)

Everything else stayed just where it was before. There's a slight 
reduction in dependencies as a result. Whee!

Alec

Alec Flett wrote:
> I'm in the process of (finally) moving color, outOfTheBoxCollection, 
> etc out of 'ContentCollection' and into an Annotation called 
> 'UserCollection' The basic idea is that if a collection does need to 
> be user-facing, and thus have things like color, etc., then we can use 
> this annotation to attach those attributes.
>
> I'm putting this annotation in osaf.app, so that all consumers of 
> these attributes now must import UserCollection from osaf.app..
>
> Whereas before they would say:
>
> foo.color = blah
>
> now they say
>
> from osaf.app import UserCollection
> ...
> UserCollection(foo).color = blah
>
> I personally like the explicit-ness of this, so consumers understand 
> that they are expecting the collection to be a user collection.
>
> As a side effect of this, I'm finding that I can keep dependencies to 
> a minimum by moving in/out/all/trash to osaf.app. This seems like the 
> right thing to do anyway because it seems like these chandler-specific 
> collections belong at a higher level than osaf.pim.
>
> I don't see this being a problem other than making changes across the 
> whole codebase, but I'm doing that right now. Does anyone have any 
> issues with this change? I'm feeling pretty positive that I can move 
> these from osaf.pim into osaf.app without creating a dependency from 
> osaf.pim to osaf.app (that dependency would defeat the purpose of this 
> whole exercise!)
>
> Thoughts?
>
> Alec
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "chandler-dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/chandler-dev