[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [e4-dev] Declarative UI in E4
|
Tom,
Tom Schindl wrote:
[...]
What you describe here is exactly what UFaceKit solves already. Without
having had time to look at both. I think UFaceKit is somewhere in
between those 2. We have a Button, Input, ... -Control but hide
completely from the user how the real UI-Widget-Structure looks like.
My guess is that UFaceKit and my work is at the same level, but that UFaceKit is
much more complete and mature, feature-rich etc (knowing your skills and the
time you and others have devoted to it).
The nice thing with this wrapping is that as long as there's margin set
an Input-Widget is simply an SWT control but when a margin is set we
dispose the original Text-Widget and recreate it wrapped with a
Composite. The other advantage is that this wrapping can take in account
how a CSS-Information is implemented most effeciently for the widget.
Yes, that's one of the very important advantages of a UI model. You can fake
features that's not directly available, in the mapping code.
By the way UFaceKit already has an EMF-Model to describe the UI.
You mentioned that you considered this in a previous posting, but you move so
fast it's difficult to keep track of your progress. I hope the model is "live",
in the sense we have discussed before? I.e. that you in principle can use the
model as your API + some kind of toolkit-specific renderer?
Just to make it clear: I don't really want to compete with you (or others), I
just want the technology to have certain desirable features. I made the TM model
to try out certain modeling and implementation strategies (kind of
proof-of-concept).
I'll take a look at the model and code for UFaceKit. If it is what I hope it is,
I will join you (if I may) and try to devote some time to it. I think there are
some good ideas in TM, particularly the way annotations are used to make the
renderer generic and the model easy to extend. I really hope you are open for a
discussion about the model, architecture and implementation!
I take the position that:
* we need to look at CSS (or Declarative-Styling) and Declarative-UI as
a whole and not make them seperate areas.
I agree. They go hand in hand.
* we don't need 100% CSS
* we should make things easy to style with CSS even if this means we are
adding e.g. custom attributes or teaching CSS custom attributes.
Again, I agree. For me the technique of styling is more important than the
standardization of the vocabulary.
By the way one of the most exiting toolkits when it comes to declarative
ui styleing is QT [1] and we could e.g. learn from the how to style our
tabs in an easy way.
I'm pleased to hear people say nice things about QT. The guys behind the
original QT all graduated at my department, about the same time I graduated.
Just after I finished my master thesis on dialog modeling in 1991 (yes, I'm that
old), I worked with them as part of my alternative military service, and had
discussions about how to bind dialog elements together and to data. I remember
one of them (Eirik Eng) worked on the compiler/pre-processor for the signal and
slot system, which BTW is very similar to the mechanism used by Garnet, a lisp
UI toolkit developed at that time by Brad Myers at CMU (and later reimplemented
in C++ as Amulet).
Of course, QT as changed and grown a lot since then, and CSS didn't exist, but
it's interesting to see that we're struggling with the same issues as back then.
Hallvard
