Re: GailTreeView Changes Proposal

>> Is the plan to keep instances of the accessible object which is related to
>> each cell around in memory?  We specifically decided to NOT do this in the
>> Java realm because the number of cells (for example in a large tree or
>> table) could be huge.

As Brian pointed out, in GTK we don't have "cell" objects to work with.  We only cache 
instances of AtkObject that have been referenced (and not subsequently un-referenced) 
by the AT.  In the case of those objects we must keep backpointers and event 
notification mechanisms for the flyweights since in the context of an asynchronous SPI 
they may be stale "on arrival" - in otherwords, if the AT asked for a cell, it needs 
to be informed if the cell becomes out-of-date while it is being manipulated.

Furthermore if a cell is editable, it needs to relay its state changes back to the 
backing store.

At any rate we have what we think is a good solution for the original problem of 
renderers being re-used in different contexts.


Bill Haneman x19279
Gnome Accessibility / Batik SVG Toolkit
Sun Microsystems Ireland 

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]