John Anderson wrote:
My
plan was to let each block handle the notification, which was suppose
to include information about what changed (e.g. the attribute). Each
block would decide what to keep around so that synchronizing the widget
was efficient.
Right, you're describing exactly what I just implemented.
So
I'd vote against accumulating hints for all blocks and just do it for
calendar, if you think it's the best solution for calendar. I'll
implement a quite different scheme for the table, which probably
doesn't need to keep track of anything except a dirty bit.
Well, the hint accumulation only happens for async events - i.e. before
we were setting self.dirtyBlocks[blockUUID] to 'True' and so instead of
'True' I'm assigning a list of hints. Then when synchronizeWidget() is
called, it just passes this hint list along and then destroys it. The
hints do not accumulate for anything more than the time until the next
idle event that calls synchronizeWidget()
This lets the widget itself decide how to handle the list of hints - it
can ignore them all and completely redraw (which is what they all do
now) or they can specifically look at the parameters to
synchronizeWidget or wxSynchronizeWidget and look through the hints for
specific item or attribute information.
Also,
last I checked, the notification doesn't include the attributes that
changed, which is necessary for table.
Right, it would sure help the calendar as well, but the contents of the
hint are orthogonal to the actual hint mechanism.
Alec
John
Andi Vajda wrote:
A while back 'we' said that we'd add the names of changed attributes in
the notifications that are sent out from OnIdle. It would go a long way
in knowing what changed and how relevant a notification is.
The repository provides all this information to OnIdle via the
mapChanges() API used to poll for changes.
Andi..
On Thu, 20 Oct 2005, Alec Flett wrote:
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
|
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
