On 4/30/07, David Chisnall <[EMAIL PROTECTED]> wrote: > > On 30 Apr 2007, at 19:24, Quentin Mathé wrote: > > > - Nicolas sent Login Panel and Sketch applications to Yen-Ju who is > > on the way to make improvements and bug fixes necessary for the > > LiveCD release. Yen-Ju committed both applications to the repository > > during the past two days. > > I seem to recall that Sketch had some bugs that were highly dependent > on the text system. Did these get resolved?
No, I think. But it falls into my 2-teir for bug fixing. [snip] > > > but not yet on GNUstep (though it already > > compiles and runs). > > Update: It (apparently) works for Yen-Ju on GNUstep too. I think > that's because he's updated to the latest GNUstep, and I haven't > yet. It should be okay to go into stable now. I've done a lot of > bug fixing in the last two days, and more use / testing would be > helpful. I still have problems here and there on GNUstep. I guess I have to convert all nib into gorm first to reduce the possibilities. There are something regarding Apple DTD is not well-formated. I haven't figure what might be the problem. I will try to find time to work on it. > > > 5/ Maintainers and Modules Without Official ones > > > > - In the middle of Open Bugs topic, we discussed about the need of > > new maintainers for modules like Grr, DictionaryReader, Vindaloo, > > RSSKit, PDFKit, Addresses etc. It becomes more critical with Günther > > departure. However we have decided it's better to continue > > development in an informal way at least for this release. We hope the > > LiveCD could bring new developers that may eventually take over > > unmaintained modules. > > At some point, it might be a good idea to look at RSSKit and see if > it should be sharing code (e.g. XML parser) with the Jabber stuff. > Not yet though, because I am considering gutting my XML parser and > replacing the innards with some Ragel stuff. I'd also like to take a > poke at Addresses at some point. It lags a lot, usability-wise, > behind its OS X counterpart, and this should be remedied. The CollectionKit was originally designed to be a more general framework ported from AddressBook. The API is good enough for many general usage. Many manager has group and item relationship, like RSSReader, Music Manager, AddressBook, etc. Then the BookmarkKit is built on top of CollectionKit. It is a case where one item only belongs to one group. I was thinking to rewrite AddressBook on top of CollectionKit. But there are two concerns. First is storage format. CollectionKit stores everything in a single property list file, which is the same as iTunes. While it is easy to maintain, it may be difficult to deal with multiple thread/process reading and writing when the data is shared. And it may be harder for file-based indexer like LuceneKit. The second is for compatibility with Apple's AddressBook. There is the current subclass relationship: CKRecord -> CKGroup -> BKGroup CKRecord -> CKItem -> BKItem So the only way to build AddressBookt on top of CollectionKit is CKRecord -> CKGroup -> ADGroup CKRecord -> CKitem -> ADPerson But there is a ADRecord as superclass of ADGroup and ADPerson. A trick to use #define ADRecord CKRecord. It is how original ADRecord is compatible to ABRecord. But again, it becomes a 2-tier issue for now. So I leave it open to any option. Yen-Ju > > > Thanks to all and sorry for the moving date of this conference > > initially planned on April 8th. > > By the way, next conference is not yet planned. > > I'm in the SILC channel most of the time I'm awake and near a > computer, so feel free to poke me there. > > David > _______________________________________________ > Etoile-dev mailing list > [email protected] > https://mail.gna.org/listinfo/etoile-dev > _______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
