On 2005-03-15, Felix Breuer <[EMAIL PROTECTED]> wrote:
> The difference to Vis, of course, is, that Vis plans to autogenerate a UI
> and with Edje every theme for every app has to be hand-written, but IMHO
> the two approaches do have a lot in common.
Vis also allows manually fine-tuning every interface to every application.
But one of the main point of Vis is a set of standardised action/data
patterns so that user interfaces for certain standard operations can be
generated automatically or based on standard templates by UI backends that
know of those patterns without bloated libraries with functions to implement
every different type of dialog imaginable. And backends that don't know of
all patterns that others do can still do something relatively reasonable
with the data. Vis is not just about encoding UI structure in a manner that
doesn't depend on the type of UI, it also encodes some semantics of it.
Analogy: XML-style markup alone is meaningless. HTML with known structural
tags is very meaningful.
For example, in the section 6.2 example in the Vis paper we have
pgtcx:def('std/control.openfile()', vis.Command)
:setv(openfile)
pgtcx:def('std/control.openfile().filename', vis.String)
Now, when an UI backend understands the pattern,
std/control.openfile() :: Command
AND
std/control.openfile().filename :: String
it can decide to open a special file input query/dialog instead of
a plain string input box.
(Arguably it would be better to base the decision on some filename
parameter having type FileName subtyping String, but those are
implementation details, and the Vis paper is just a handwavy position
paper...)
As so many things, something like Edje seems like it could fit as a
fancy UI backend in the Vis framework, but it doesn't seem to be at
all close to what Vis is about.
--
Tuomo
