|
I've just checked in a first cut at a "hints" system for
wxSynchronizeWidget The problem I'm running into is that the calendar is getting wxSynchronizeWidget messages for every minor change under the sun, and with each sync, we completely rebuild the calendar.. but we have no choice because we don't know what exactly initiated the sync. It would be nice to know that if some minor attribute on an item changed (like contentsOwner) then the calendar could safely ignore wxSynchronizeWidget. So my first cut was to pass in a dictionary of hints along with each call to wxSynchronizeWidget() - I've hooked this up for collection notifications, and updated all the synchronizeWidget/wxSynchronizeWidget definitions appropriately, though all the hints are currently just ignored. The dictionary contains well known keys like 'collectionChanged' which would contain a list of hints for that type of change, each of which is a tuple which is the arguments passed from the repository to the change listener... We talked a while back about unifying the various notification systems (collections, monitors, etc) and this seems like a good time to think about this. The reason I pass in a dictionary of hints rather than just a list, is that each hint's tuple is in a different format, depending on the callback parameters for the particular notification system. I'm just realizing that a downside of this is that we are clumping the different types of notifications together, rather than ordering them by the time they arrived. (well, they're ordered within each notification type - so all the 'collectionChanged' hints are in order of how they arrived) Perhaps instead we should pass in simply an array of tuples, in order, where the first entry in the tuple is the well-known type (like 'collectionChanged') and the rest of the tuple is the list of parameters. I'll work on that tomorrow. Thoughts? Alec |
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
