On 2006-05-10, Sascha Silbe <[EMAIL PROTECTED]> wrote:
> I'm currently trying to write a prototype implementation for VIS, but=20
> some things were not quite clear (at least to me) in the paper:
The paper only has a draft implementation of what a Vis-like system
would really be; don't take the API too literally. Infact, if I wrote
this Vis paper now, I'd probably try do the example in Haskell with
static typing :). In any case, it's nice to see someone take on
implementing Vis or something like, and I'll gladly help what I can.
Also, I certainly don't think that the Vis core should be implemented
in Lua, after all, but in C, as that's the only language easily
accessible from other langueges (Lua binding should, however, obviously
be provided.)
> 1. Vis.Command is mentioned/used, but not defined anywhere.
It should be a data type (vis.Accessible) along with vis.Bool etc.
> 2. Are the parameters to Vis.Command specified in the name (separated by=20
> dots) string literals or variable names?
I haven't actually fully specified how commands receive parameters.
Looking at the examples, a method of some data e.g. in
cv:def('std/view.area:changed', vis.Command):setv(set_viewarea)
would receive 'std/view.area' as parameter, but a non-method would
get no parameters. But, really, it's up to you do decide how to do it.
Don't pay too strict adherence to the Vis paper.
> 3. How exactly are Sets expected to work? What's meant with "set (of=20
> sets) that is a cross-section of the sets in the hierarchy" (Section=20
> 5.1, Vis.Struct:get)? Some examples would be great.
Suppose you have the data 'something/foo[]' of Strings. Then
requesting this would return a set of strings, say {"a", "b", "c"}, etc.
Suppose then that you have the data 'something/foo[].bar[]' of Integers.
If you request all of this, you might get {{1,2,3},{1,5,9},{2,3,7}}
> 4. What is vis.Context:clear() expected to clear? Only the "internal"=20
> state or the defined Accessibles, too?
I guess it's supposed to undefine (hey, it's a long time since I wrote
that paper) any defs, and put the context in such a state that it
can not be interacted with before :realise() is called again.
> 5. What's expected to happen if there are both 'std/foo' and=20
> 'libbar/foo'? Raise a name collision exception?
Both can exist with collision.
> 6. In Section 5.2, fifth paragraph, it's defined that command entries=20
> must end in '()'. But several occurances of command definition examples=20
> (like "ctx:def('std/content.location:changed', vis.Command)" in the box=20
> at the end of section 5.3) don't use that notation. Is that a typo or=20
> have I overlooked something?
Infact, the '()' notation is missing from methods of data. Maybe it
should be there. It would seem logical. But again, do it how you want
to do it.
> 7. How is Context:realise() expected to work? When does it return? How=20
> does it interact with std/seq.next() and vis.mainloop()?
It's a bit like XMapWindow, but may, of course, do a lot more. It returns
when the context is ready to interact with the user, and this depends on
the UI back-end. Now that I think of it, maybe the "Vis may require user
interaction while doing this to, for example, query the user for for
startup parameters" part should be done some other way. One approach
would be to pass :realise() a continuation function from which to
continue from after all has been taken care of in the main loop.
And, yes, 'std/seq.next()' or _any_ command could call realise(),
and that could perhaps have nasty effects in the original plan.
Thus the continuation approach seems even better. I'm using a similar
principle in some extent in Ion as well; everything "dangerous" is
deferred to the main loop.
> 8. What are the parameters of foo:changed? Canvas containing foo and foo=20
> itself (example in section 6.2, function set_viewarea)? What if it's=20
> used below vis.maincontext() instead of below vis.create_canvas()?
See the answer to question 2.
--
Tuomo
