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
