Le 8 mai 07 à 07:51, Yen-Ju Chen a écrit : > On 5/7/07, Quentin Mathé <[EMAIL PROTECTED]> wrote: > > A plan I have is to merge CollectionKit and BookmarkKit. > Since we probably won't need to maintain AddressKit in the future, > CollectionKit/BookmarkKit can be more flexible.
What would be the interest of merging BookmarkKit back into CollectionKit? Reducing maintenance and unifying APIs even more? Distinct API looks cleaner to me if you consider it will be used very often and even in applications that already use CollectionKit in their own way. If we use only CollectionKit, how would you support dedicated extensions? For example, AddressBook has extensions like LDAP support or ABImageClient protocol. Also it implies we are going to lose Cocoa compatibility (used by StepChat and others). >> - tabbed document support in PaneKit (this means all applications >> that use NSDocument would automatically benefit from PaneKit features >> for combining/displaying several documents in one window) > > I am not sure PaneKit can fit with NSDocument well. > An assumption of NSDocument is that a document can > have one or more windows. > When tab is involved, the relationship is reverse. > A window can have one or more documents. > It is still doable, but probably parallel with NSDocument > instead of subclass. It might make things easier. It's sure it will mean restriction to NSDocument. If you think about it, really few applications use NSDocument possibility to have one-to- many relationship with windows. For this last case, it doesn't make sense to use tabs in my opinion. In the end, depending on its application style, the developer would decide to adopt the feature or not (by linking PaneKit and writing few lines of glue code). I must say I haven't put a lot of thoughts into this yet :-) Cheers, Quentin. _______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
