| Making GEF and EMF work together [message #22371] |
Thu, 04 March 2004 06:59  |
Eclipse User |
|
|
|
What do you all think about an abstract layer (framework or/and library)
that helps developers to use GEF on top of EMF based data models?
We already thougt about that topic. Some prototypes have been created and
seem to work perfectly.
Examples:
Command Stack
Can be used as GEF command stack and as EMF command stack. Can work with
GEF and EMF commands. => EMF editing domain and GEF edit domain can work
on he same command stack instance. => no synchronisation problems
Edit Parts
Abstract edit part implementation representing an EMF object graphically.
Registers for changes in object and refreshes visuals automatically.
Overview Outline
Eclipse view that shows the whole 'picture'.
Further Ideas:
- Graphics model (EMF); layout contraints, colors, font, line width,...
- Generic property sheet support: supports attributes of 'graphids model'
- ...
Christian Brand
|
|
|
|
| Re: Making GEF and EMF work together [message #23395 is a reply to message #23250] |
Mon, 08 March 2004 03:06  |
| Eclipse User |
|
|
|
Thank you for an elaborate answer.
Best regards,
Christian Brand
"Joe Winchester" <winchest@uk.ibm.com> wrote in message
news:4049153D.54C6AB78@uk.ibm.com...
> Hi Christian,
>
> > What do you all think about an abstract layer (framework or/and library)
> > that helps developers to use GEF on top of EMF based data models?
> > We already thougt about that topic. Some prototypes have been created
and
> > seem to work perfectly.
>
> This is a good idea and has been thought about several times before within
> IBM. For GEF it was felt that it should be model neutral, so having EMF
> there would limit its usages and GEF does a great job of finding the right
> balance. For the VE we use EMF and have abstracted a lot of the common
stuff
> into the org.eclipse.jem packages. At one point we did have examples of
> editors that used this and were just using raw EMF models. A lot of what
> goes on with edit policies is based around traversing and adding to a
single
> EMF relationship, and you're right about the command stack stuff (although
> for the VE we integrate with the JDT undo so the scenario of user changes
GUI
> then source then GUI is all undone correctly).
>
> The graphical stuff is harder to do in abstract. A lot of models just
want
> custom rendering, but an abstract impelementation could do some kind of
UML
> type relationship diagram. Another possibility is boxes within boxes for
> isContainment=true and lines between boxes for isContainment=false.
> EditPolicies could know what to do for dropping inside boxes and dragging
> lines could be done. However for the VE we decided somewhere along the
way
> that we needed to focus on a few goals and do them well rather than spead
> ourselves too thin and over-engineer. Therefore we are concentrated on
the
> out of the box GUI builder and also making this extensible for people
wanting
> to do other graphical runtime builders.
>
> So ... we do have the plugins and classes to do a lot of what you want,
> however it's not a priority for us to promote this just cause we're heads
> down on SWT and performance right now. However the VE is open-source so
if
> you want to get involved please join the ve newsgroup and it can be
discussed
> there further.
>
> Best regards,
>
> Joe Winchester
>
|
|
|
| Re: Making GEF and EMF work together [message #583607 is a reply to message #22371] |
Fri, 05 March 2004 19:03 |
| Eclipse User |
|
|
|
Hi Christian,
> What do you all think about an abstract layer (framework or/and library)
> that helps developers to use GEF on top of EMF based data models?
> We already thougt about that topic. Some prototypes have been created and
> seem to work perfectly.
This is a good idea and has been thought about several times before within
IBM. For GEF it was felt that it should be model neutral, so having EMF
there would limit its usages and GEF does a great job of finding the right
balance. For the VE we use EMF and have abstracted a lot of the common stuff
into the org.eclipse.jem packages. At one point we did have examples of
editors that used this and were just using raw EMF models. A lot of what
goes on with edit policies is based around traversing and adding to a single
EMF relationship, and you're right about the command stack stuff (although
for the VE we integrate with the JDT undo so the scenario of user changes GUI
then source then GUI is all undone correctly).
The graphical stuff is harder to do in abstract. A lot of models just want
custom rendering, but an abstract impelementation could do some kind of UML
type relationship diagram. Another possibility is boxes within boxes for
isContainment=true and lines between boxes for isContainment=false.
EditPolicies could know what to do for dropping inside boxes and dragging
lines could be done. However for the VE we decided somewhere along the way
that we needed to focus on a few goals and do them well rather than spead
ourselves too thin and over-engineer. Therefore we are concentrated on the
out of the box GUI builder and also making this extensible for people wanting
to do other graphical runtime builders.
So ... we do have the plugins and classes to do a lot of what you want,
however it's not a priority for us to promote this just cause we're heads
down on SWT and performance right now. However the VE is open-source so if
you want to get involved please join the ve newsgroup and it can be discussed
there further.
Best regards,
Joe Winchester
|
|
|
| Re: Making GEF and EMF work together [message #583731 is a reply to message #23250] |
Mon, 08 March 2004 03:06 |
| Eclipse User |
|
|
|
Thank you for an elaborate answer.
Best regards,
Christian Brand
"Joe Winchester" <winchest@uk.ibm.com> wrote in message
news:4049153D.54C6AB78@uk.ibm.com...
> Hi Christian,
>
> > What do you all think about an abstract layer (framework or/and library)
> > that helps developers to use GEF on top of EMF based data models?
> > We already thougt about that topic. Some prototypes have been created
and
> > seem to work perfectly.
>
> This is a good idea and has been thought about several times before within
> IBM. For GEF it was felt that it should be model neutral, so having EMF
> there would limit its usages and GEF does a great job of finding the right
> balance. For the VE we use EMF and have abstracted a lot of the common
stuff
> into the org.eclipse.jem packages. At one point we did have examples of
> editors that used this and were just using raw EMF models. A lot of what
> goes on with edit policies is based around traversing and adding to a
single
> EMF relationship, and you're right about the command stack stuff (although
> for the VE we integrate with the JDT undo so the scenario of user changes
GUI
> then source then GUI is all undone correctly).
>
> The graphical stuff is harder to do in abstract. A lot of models just
want
> custom rendering, but an abstract impelementation could do some kind of
UML
> type relationship diagram. Another possibility is boxes within boxes for
> isContainment=true and lines between boxes for isContainment=false.
> EditPolicies could know what to do for dropping inside boxes and dragging
> lines could be done. However for the VE we decided somewhere along the
way
> that we needed to focus on a few goals and do them well rather than spead
> ourselves too thin and over-engineer. Therefore we are concentrated on
the
> out of the box GUI builder and also making this extensible for people
wanting
> to do other graphical runtime builders.
>
> So ... we do have the plugins and classes to do a lot of what you want,
> however it's not a priority for us to promote this just cause we're heads
> down on SWT and performance right now. However the VE is open-source so
if
> you want to get involved please join the ve newsgroup and it can be
discussed
> there further.
>
> Best regards,
>
> Joe Winchester
>
|
|
|
Powered by
FUDForum. Page generated in 0.59732 seconds
Home