On 01:07 Tue 13 Apr , Tuomo Valkonen wrote: > 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.
That's true. > 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. Minimalism is probably the best approach towards a framework as general as Vis. > 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. Applications may want to expose (most of the) document data to the user via "widget" i.e. as Accessibles. I, for example, am toying with ideas for a scientific drawing application: of course the canvas would play an important role presenting the data to the user. But a lot of the parameters for generating the data (e.g. function plots, graphs, simplicial complexes, tilings of the plane...) should be entered textually or through widgets instead of by "point-and-click"-means. Also I might want to give the user a hierarchical view of the document - best present by a tree view... > 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. Ah, I get it. Regards, Felix
