[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [gmf-dev] Conversation starter...
|
Hi all,
thanks to IBM a solid starting point for the runtime framework of GMF
is available.
So I agree with Henrik, the most challenging part of the GMF project
seems to be the diagram definition which shall
support the specification of a large variety of graphical editors. The
diagram definition should comprise the
definition of the kind of diagrams supported as well as the editor
features, i.e. user interaction.
The kind of diagrams can be defined by an EMF model where ideally
notational and semantic information is
separated.
The concepts for defining the editor features are much more open. Having
only the EMF model at hand, I can
imagine a simple default editor which allows to insert and modify
symbols and connections. If OCL constraints
are formulated, they can be checked in live or batch mode (as mentioned
in the IBM talk). But the definition
of non-standard or more complex editor commands is not supported by this
approach, at least I don't see how.
How shall we define an operation which inserts several symbols and
connections at once, dependent on the diagram
syntax? One example might be the insertion of a new composite state
which to include an initial state and history
vertices, into a state diagram.
Here, we could contribute with ideas coming from graph rules in AGG.
Rules are well-suited to describe pre and
post-conditions of editor operations which could be formulated directly
on the EMF model. In the Tiger project
we developed a strategy how to interpret rules as editor operations and
to generate corresponding code based
on GEF. Moreover it might be interesting to support the adaptabilitiy of
the graphical user interface of the graphical
editor to special user needs.
Of course, it is a good idea to examine several different examples for
graphical editors to find out what we want
to define.
Best wishes,
Gabi
Henrik Rentz-Reichert wrote:
Hi all,
IBM's contribution really is impressive and I'm quite sure that this
(with maybe some modifications) will be the runtime framework of GMF.
That will save us a lot of work. Thanks to IBM :-)
The most challenging part of the GMF project in my opinion will be to
create a framework for the definition of the graphical editors for a
given model which is very general AND easy to use at the same time. This
definition probably will be a model describing the editors (say gcore as
opposed to ecore) plus (or including) a mapping of the editor to the
underlying domain model.
I have no idea yet how those editors could by defined. But I cannot
imagine, that the definition of a visual alphabet of allowed graph
modifications like in the Tiger project is general enough.
I would say in a first step we should define a couple of editor examples
together with some use cases to get an impression of the spectrum of
possibilities we will have to handle. Of course we will have example
editors from the UML context. But we should also have examples from
completely other domains, the more different the better.
Once we have a definition of the graphical editors it should be more or
less straight forward to create a JET based generator for the editor
plugins.
Best Regards,
Henrik
Richard Gronback wrote:
Hello All,
First of all, I just want to again thank all who have presented
potential contributions, those who will, and those who have provided
feedback and expressed interest in GMF.
We have a bit of a lull before the next presentations on the 20^th and
27^th , so I think it is a good time to begin discussing what our
impressions are so far regarding the starting point for GMF.
To start the thread, I will offer my perspective (with the understanding
that we still have GME, Patternset, Sybase, and VE to review).
For the runtime framework, I think it’s pretty clear that the IBM
contribution is desirable. Although portions of their contribution may
ultimately find a home in EMF and possibly GEF, it seems like a good
choice to be the target of the generation framework portion of GMF.
The AGG portion of the Tiger project seems intriguing as a means to
define operations in a visual manner, although my feeling is that it may
suffer from scalability issues in large, complex diagram definitions.
However, I think we should investigate it more closely for inclusion in
GMF, if not as part of an initial milestone.
The Borland prototype is progressing well and is currently being
refactored to better align with the requirements. Also, less attention
is being paid to the runtime target in light of the pending IBM
contribution. We hope to have this contribution available for close
review at the July kickoff meeting, if not beforehand.
Merlin’s mapping model approach is something we’d like to emulate/extend
and welcome Joel’s feedback and participation in this area.
In the case of M1 and oAW, as neither have a basis in EMF, and with the
expectation that it would be IBM’s runtime we would target for
generation after refactoring, I’m not sure where that leaves us aside
from leveraging their experience and future contributions.
Please provide your comments and feedback for discussion. We need to
maintain an active and diverse community, particularly following this
contribution review phase. And as mentioned, now seems like a good time
to discuss contributions, approaches, and architecture, as we have some
time before the next reviews.
Thanks again to all.
Best Regards,
Rich
*Richard C. Gronback***
Borland Software Corporation
richard.gronback@xxxxxxxxxxx <mailto:richard.gronback@xxxxxxxxxxx>
860 227 9215
------------------------------------------------------------------------
_______________________________________________
gmf-dev mailing list
gmf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gmf-dev
--
--------------------------------------
Address: Dr. Gabriele Taentzer
Technische Universität Berlin
Fakultät IV, Sekr. FR 6-1
Franklinstr. 28 / 29
D-10587 Berlin, Germany
Phone: +49-30-314-27787
Fax: +49-30-314-23516
E-mail: gabi@xxxxxxxxxxxxxxx
--------------------------------------
