[Dev] wxSynchronizeWidget hints

[John Anderson]

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. What you need to keep around for a Calendar block might 
be quite different from what you need for a Table block, and keeping 
around a list of all the changes could lead to way too much information 
in some cases. Some widgets, like tables and calendars can completely 
ignore changes to data that aren't on the screen, which is a giant win 
for large lists, and doesn't require us to keep around any information.

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.

Also, last I checked, the notification doesn't include the attributes 
that changed, which is necessary for table.

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