On Mon, Apr 12, 2004 at 11:17:12PM +0200, Felix Breuer wrote: > After first reading your paper I have two things to remark concerning > your proposed Vis API:
The proposed API is just one possibility, and before the API converged to the one the paper, there were, infact, versions that implement the issues you describe more explicitly. > 1) Where to store application data? > My proposal on how to solve this: provide Vis with callback functions > that Vis' can call to retrieve the Accessibles whenever it becomes > necessary. I originally had callbacks for retrieving the data, but at some point changed to the current method. The UI may actually need some of the data a lot more often than the application: every time it needs to redraw itself and while I hadn't thought about it before, storing the data on the Vis side would help network transparency. Of course Vis could just cache stuff, but to this end all the same mechanisms and more should be in place as in the current proposal, in which I've tried to reach certain minimalism. Of course, it is only a proposal and this is not a big change to it, if it is considered better to have the application only store the data. The amount of data stored in Accessibles should, however, never be that big. Data that amounts to a document should be displayed in a canvas. Or at least that's how I've thought to do things. > 2) State-full applications. > How do you want to the application to communicate to Vis which kinds of > states it has and how these states are reflected in the available > Accessibles? Just toggleing the "enabled" attribute of an Accessible > does not seem good enough to me. I originally had vis.Context:setsub/getsub functions for setting a sub-context to allow for this sort of stuff. However, UI modules might be able to make better decisions on control placement if they're aware of all possible sub-contexts when the canvas is initially realised. To this end I moved the sub-context stuff to the 'std/subcontext' structure, where active contexts are indicated with the 'enabled' attribute. Because it is known that the 'std/subcontext' hierarchy contains accessibles for sub-contexts or modes, UI modules will be able to handle changes to the 'enabled' attribute as a sub-context or mode change. > Well, it's past time I stop writing ;) I really hope Vis is actually > realized, I am even willing to help making it happen. What are your > plans on how to proceed? I currently have no plans with regard to Vis. I just needed to write this paper so I don't have to explain the idea all the time, and to make sure there's prior art in case someone decides to patent something like it :). (Oh, well, most likely Vis is already covered by hundreds of patents.) What I plan to do next is finish Ion3 -- which will be the "final" Ion from me unless something new and revolutionary comes up -- and then move on to working on something new for a change. Vis? I don't know. -- Tuomo
