[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [e4-dev] Toolkit model
|
Hallvard,
Just a question about :
The event itself is transient, while the affected property is not. E.g.
a toggle button (and a checkbox) has a transient selectionEvent
attribute and a persistent selection attribute, while a push button only
has the transient selectionEvent attribute.
What is the relevance between a selectionEvent of a push button and the
one of a checkbox ???
Do you really need a such event for checkbox since it is easy to use
adapter on 'selection' property ... wich is not possible on push button?
In SWING or in SWT, checkboxes, toggle & push buttons derive all from
the same class (sometime abstract), even if they share a large part of
common behavior, the major difference is, for a SWT push button, that
the 'pressed' state is not present, then in theory the selection change
occurs always twice: false->true and true->false with no way to
intercept only one (in SWING it is possible, there is states like
'armed', 'pressed' ...).
Olivier
Hallvard Trætteberg a écrit :
Olivier,
Olivier Moïses wrote:
Nice to peak with you again after the last pizza (private joke ;-) ).
:-) It was nice to speak and eat with you at ESE. Very inspiring!
Regarding wazaabi 2.0, I did not add new widgets recently because I
strongly believe that a binding model is requiered before!
Binding is important, I agree. Modeling it needn't be that difficult,
if all the objects, including domain and toolkit, are Ecore objects.
I may have mentioned my dialog modeling language diamodl, which is my
line of research. Besides activation logic, it models dataflow to/from
the model and UI components, i.e. databinding. There are three main
concepts: variables for holding data, computations for transforming
data, and widgets for referencing the toolkit objects. The model is
translated to EClasses (which is combined with the domain model to a
large Ecore model), and the runtime consists mainly of instances of
these (and domain data), with references to the toolkit model objects
and databinding for moving data inside the UI and to/from the toolkit.
So, in practice databinding is modeled as a link between a structural
feature of one Ecore instance to a structural feature of another.
How do you validate the move from SWT specific to generic one ? The
policy I apply (but I am definitely not sure) is "each time a piece
of behaviour appears in SWT and SWING, then move it into
Abstract/Generic metamodel).
Yes, something similar.
- Package structure: Like wazaabi, I've split the model into
widgest, layouts and styles packages. The disadvantage is that the
generated package and factory classes will have the same names
(although in different Java packages).
Couldn't you add an annotation for the generated classe name?
The classes are generated from genmodels, so (re)naming must be
handled there. In practice, the name collision is not a problem, as
specific Builder classes mainly use classes generated from one model.
- Events: Events are modelled as transient attributes that
invalidate the reference/attribute corresponding to the input value.
This means that event info. is available for the application. In my
experience this is needed, e.g. to detect whether a change to a Text
widget resulted from a keystroke or a programmatic change.
Why only transient attributes?? for instance, the selection of a
checkbox could/should be persisted. Independently, the selection
change will trigger an adapter.
The event itself is transient, while the affected property is not.
E.g. a toggle button (and a checkbox) has a transient selectionEvent
attribute and a persistent selection attribute, while a push button
only has the transient selectionEvent attribute.
Hallvard
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
