On Sat, 22 Nov 2008, Frank Niessink wrote: > 2008/11/22 Jerome Laheurte <[EMAIL PROTECTED]>: >> On Sat, 22 Nov 2008, Frank Niessink wrote: >> >>> - Mac OS X 10.4.11 >> >> This is it. I wonder if the bundles built on 10.4 work on MacOS 10.3, >> I guess they don't... I think I'll use my PowerBook as the MacOS build >> slave instead of the Mini, but for various reasons I'll have to >> reinstall the system first. No big loss, the thing is almost unusable >> since a friend of mine dropped a whole glass of vodka-grapefruit on >> the keyboard :) > > Ouch.
Bah, it's obsolete anyway. I bought my Mini in order to install the iPhone SDK and make enough bucks on AppStore to buy a MacBook Pro and a MacBook Air... Apple's BM is quite efficient :) > I'm currently working on improving performance too. I'm doing some > preparation first, that I'll check in tonight hopefully. In trunk I hope ? Heavy changes are not well-suited to be committed in release branches, it makes merges more difficult. And such an improvement deserves a 0.72 release anyway. > I noticed > that for each item deleted a notification is sent: that's very > expensive. I think the whole bookkeeping done for synchronization > should be moved out of the domain classes. I'm currently trying to > have viewers and other classes use the taskfile object (to be split in > two parts later: one part representing the file and one part > representing the whole 'domainmodel') as their main object instead of > either a tasklist or a categorylist, etc. Then I can make the taskfile > object be responsible for keeping track of deleted, modified, new > items and have the synchronization code query the taskfile for that > information. No more need for filtering out deleted tasks. I'm too tired to understand all of this, but you know the internals better than me. My first approach would have been to "aggregate" change notifications from the Publisher, something like waiting 200 ms or so before dispatching notifications, the timer being reset on each new one. But it's just a track, I can't tell if it would actually make things better or worse. > Also, I hope this change will make the different viewers more alike, > maybe even to such an extend that we can have one viewer that can > switch between different types of domain objects, just as the effort > viewer can switch between individual effort records and composite > effort records. Aaah, the "universal viewer"... That would be great. I honestly think the main target for 1.0 would be a viewer that displays all domain objects, that is efforts as children of tasks, task-specific notes and attachments as children of tasks, etc. Not an easy target though. Cheers Jérôme
