Home » Eclipse Projects » GEF » GEF/GMF: choice criteria
| GEF/GMF: choice criteria [message #238222] |
Fri, 31 August 2007 18:58  |
Eclipse User |
|
|
|
Originally posted by: pagrus+eclipse.gmail.com
Greetings,
Is there a good criteria to choose GEF over GMF or vice versa?
In my application I'd like to expose graphical editor, which is not objects
and connections, but mostly diagrams with range selection tool. For a couple
of reasons the model needs to be persisted with JDO/JPOX.
So at first glance it seems that GEF is sufficient and less complicated. On
the other hand I've got the feeling that GMF is more actively developed
framework (just a feeling, no real facts =)).
Can you please suggest the way to make a good choice?
There are two distinct questions actually:
1. General criteria for GEF vs GMF.
2. Suitable choice for my case.
I'd be happy to know your opinion on both.
Thanks,
Pavel
|
|
|
| Re: GEF/GMF: choice criteria [message #238227 is a reply to message #238222] |
Fri, 31 August 2007 19:58  |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
This is a multi-part message in MIME format.
--------------020701060401020204020106
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Pavel,
Comments below.
Pavel wrote:
> Greetings,
>
> Is there a good criteria to choose GEF over GMF or vice versa?
>
> In my application I'd like to expose graphical editor, which is not objects
> and connections, but mostly diagrams with range selection tool. For a couple
> of reasons the model needs to be persisted with JDO/JPOX.
>
Did you know that EMFT's Teneo project supports persisting models using
JDO/JPOX:
http://www.eclipse.org/modeling/emft/?project=teneo#teneo
> So at first glance it seems that GEF is sufficient and less complicated. On
> the other hand I've got the feeling that GMF is more actively developed
> framework (just a feeling, no real facts =)).
>
GMF is definitely a more complex framework but also a richer one. Since
you can quickly generate a fully functional editor from a model
description, it seems a good way to get started quickly without having
to understand all the details of the whole framework.
> Can you please suggest the way to make a good choice?
>
> There are two distinct questions actually:
> 1. General criteria for GEF vs GMF.
>
If you have a model, you'll have a working prototype generated by GMF.
This might well address your needs. If it doesn't you'll still have a
functional example based on your domain that might prove useful. GEF
from scratch will likely involve significant up front work before you
have something cool working.
> 2. Suitable choice for my case.
> I'd be happy to know your opinion on both.
>
I think GEF is excellent. It's just that in most cases there is also an
underlying model being edited and for that EMF provides much value. And
when you want to combine the two GMF provides the glue and a great deal
of additional value.
> Thanks,
> Pavel
>
>
>
--------------020701060401020204020106
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Pavel,<br>
<br>
Comments below.<br>
<br>
Pavel wrote:
<blockquote cite="mid:fb9oc7$q3e$1@build.eclipse.org" type="cite">
<pre wrap="">Greetings,
Is there a good criteria to choose GEF over GMF or vice versa?
In my application I'd like to expose graphical editor, which is not objects
and connections, but mostly diagrams with range selection tool. For a couple
of reasons the model needs to be persisted with JDO/JPOX.
</pre>
</blockquote>
Did you know that EMFT's Teneo project supports persisting models using
JDO/JPOX:<br>
<blockquote><a
href="http://www.eclipse.org/modeling/emft/?project=teneo#teneo">http://www.eclipse.org/modeling/emft/?project=teneo#teneo</a><br>
</blockquote>
<blockquote cite="mid:fb9oc7$q3e$1@build.eclipse.org" type="cite">
<pre wrap="">So at first glance it seems that GEF is sufficient and less complicated. On
the other hand I've got the feeling that GMF is more actively developed
framework (just a feeling, no real facts =)).
</pre>
</blockquote>
GMF is definitely a more complex framework but also a richer one.
Since you can quickly generate a fully functional editor from a model
description, it seems a good way to get started quickly without having
to understand all the details of the whole framework.<br>
<blockquote cite="mid:fb9oc7$q3e$1@build.eclipse.org" type="cite">
<pre wrap="">
Can you please suggest the way to make a good choice?
There are two distinct questions actually:
1. General criteria for GEF vs GMF.
</pre>
</blockquote>
If you have a model, you'll have a working prototype generated by GMF.
This might well address your needs. If it doesn't you'll still have a
functional example based on your domain that might prove useful. GEF
from scratch will likely involve significant up front work before you
have something cool working.<br>
<blockquote cite="mid:fb9oc7$q3e$1@build.eclipse.org" type="cite">
<pre wrap="">2. Suitable choice for my case.
I'd be happy to know your opinion on both.
</pre>
</blockquote>
I think GEF is excellent. It's just that in most cases there is also
an underlying model being edited and for that EMF provides much value.
And when you want to combine the two GMF provides the glue and a great
deal of additional value.<br>
<blockquote cite="mid:fb9oc7$q3e$1@build.eclipse.org" type="cite">
<pre wrap="">
Thanks,
Pavel
</pre>
</blockquote>
<br>
</body>
</html>
--------------020701060401020204020106--
|
|
|
| Re: GEF/GMF: choice criteria [message #238232 is a reply to message #238227] |
Sat, 01 September 2007 18:28 |
| Eclipse User |
|
|
|
Originally posted by: pagrus+eclipse.gmail.com
This is a multi-part message in MIME format.
------=_NextPart_000_0010_01C7ECDF.15A8BAB0
Content-Type: text/plain;
charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Ed,
Thanks for your comments. If I understand correctly, for cases with =
model involved (and this is, well, close to 100%) GMF would be a proper =
choice.
Is it correct that GMF provides a superset of GEF features? That is, if =
you can do something with pure GEF, that will be possible with GMF as =
well.
If not, what sort of things you think are going to be =
difficult/unavailable to implement with GMF?
Thanks,
Pavel
"Ed Merks" <merks@ca.ibm.com> wrote in message =
news:fb9rq3$hsj$1@build.eclipse.org...
Pavel,
Comments below.
Pavel wrote:=20
Greetings,
Is there a good criteria to choose GEF over GMF or vice versa?
In my application I'd like to expose graphical editor, which is not =
objects=20
and connections, but mostly diagrams with range selection tool. For a =
couple=20
of reasons the model needs to be persisted with JDO/JPOX.
Did you know that EMFT's Teneo project supports persisting models =
using JDO/JPOX:
http://www.eclipse.org/modeling/emft/?project=3Dteneo#teneo
So at first glance it seems that GEF is sufficient and less complicated. =
On=20
the other hand I've got the feeling that GMF is more actively developed=20
framework (just a feeling, no real facts =3D)).
GMF is definitely a more complex framework but also a richer one. =
Since you can quickly generate a fully functional editor from a model =
description, it seems a good way to get started quickly without having =
to understand all the details of the whole framework.
Can you please suggest the way to make a good choice?
There are two distinct questions actually:
1. General criteria for GEF vs GMF.
If you have a model, you'll have a working prototype generated by GMF. =
This might well address your needs. If it doesn't you'll still have a =
functional example based on your domain that might prove useful. GEF =
from scratch will likely involve significant up front work before you =
have something cool working.
2. Suitable choice for my case.
I'd be happy to know your opinion on both.
I think GEF is excellent. It's just that in most cases there is also =
an underlying model being edited and for that EMF provides much value. =
And when you want to combine the two GMF provides the glue and a great =
deal of additional value.
Thanks,
Pavel=20
=20
------=_NextPart_000_0010_01C7ECDF.15A8BAB0
Content-Type: text/html;
charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type =
content=3Dtext/html;charset=3DISO-8859-1>
<META content=3D"MSHTML 6.00.2900.2180" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Ed,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Thanks for your comments. If I =
understand=20
correctly, for cases with model involved (and this is, well, close to=20
100%) GMF would be a proper choice.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Is it correct that GMF provides a =
superset of GEF=20
features? That is, if you can do something with pure GEF, that will be =
possible=20
with GMF as well.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>If not, what sort of things you =
think are=20
going to be difficult/unavailable to implement with =
GMF?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Thanks,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Pavel</FONT></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Ed Merks" <<A =
href=3D"mailto:merks@ca.ibm.com">merks@ca.ibm.com</A>>=20
wrote in message <A=20
=
href=3D"news:fb9rq3$hsj$1@build.eclipse.org">news:fb9rq3$hsj$1@build.ecli=
pse.org</A>...</DIV>Pavel,<BR><BR>Comments=20
below.<BR><BR>Pavel wrote:=20
<BLOCKQUOTE cite=3Dmid:fb9oc7$q3e$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D"">Greetings,
Is there a good criteria to choose GEF over GMF or vice versa?
In my application I'd like to expose graphical editor, which is not =
objects=20
and connections, but mostly diagrams with range selection tool. For a =
couple=20
of reasons the model needs to be persisted with JDO/JPOX.
</PRE></BLOCKQUOTE>Did you know that EMFT's Teneo project supports=20
persisting models using JDO/JPOX:<BR>
<BLOCKQUOTE><A=20
=
href=3D"http://www.eclipse.org/modeling/emft/?project=3Dteneo#teneo">http=
://www.eclipse.org/modeling/emft/?project=3Dteneo#teneo</A><BR></BLOCKQUO=
TE>
<BLOCKQUOTE cite=3Dmid:fb9oc7$q3e$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D"">So at first glance it seems that GEF is =
sufficient and less complicated. On=20
the other hand I've got the feeling that GMF is more actively developed=20
framework (just a feeling, no real facts =3D)).
</PRE></BLOCKQUOTE>GMF is definitely a more complex framework but also =
a=20
richer one. Since you can quickly generate a fully functional =
editor=20
from a model description, it seems a good way to get started quickly =
without=20
having to understand all the details of the whole framework.<BR>
<BLOCKQUOTE cite=3Dmid:fb9oc7$q3e$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D"">Can you please suggest the way to make a =
good choice?
There are two distinct questions actually:
1. General criteria for GEF vs GMF.
</PRE></BLOCKQUOTE>If you have a model, you'll have a working =
prototype=20
generated by GMF. This might well address your needs. If =
it=20
doesn't you'll still have a functional example based on your domain =
that might=20
prove useful. GEF from scratch will likely involve significant =
up front=20
work before you have something cool working.<BR>
<BLOCKQUOTE cite=3Dmid:fb9oc7$q3e$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D"">2. Suitable choice for my case.
I'd be happy to know your opinion on both.
</PRE></BLOCKQUOTE>I think GEF is excellent. It's just that in =
most=20
cases there is also an underlying model being edited and for that EMF =
provides=20
much value. And when you want to combine the two GMF provides =
the glue=20
and a great deal of additional value.<BR>
<BLOCKQUOTE cite=3Dmid:fb9oc7$q3e$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D"">Thanks,
Pavel=20
</PRE></BLOCKQUOTE><BR></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_0010_01C7ECDF.15A8BAB0--
|
|
|
| Re: GEF/GMF: choice criteria [message #238236 is a reply to message #238232] |
Sat, 01 September 2007 18:40 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
This is a multi-part message in MIME format.
--------------000006000801000907010607
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Pavel,
I'm not absolutely sure, but I believe anything you can do with GEF
you'll be able to exploit in GMF.
Pavel wrote:
> Ed,
>
> Thanks for your comments. If I understand correctly, for cases with
> model involved (and this is, well, close to 100%) GMF would be a
> proper choice.
>
> Is it correct that GMF provides a superset of GEF features? That is,
> if you can do something with pure GEF, that will be possible with GMF
> as well.
> If not, what sort of things you think are going to be
> difficult/unavailable to implement with GMF?
>
> Thanks,
> Pavel
>
> "Ed Merks" <merks@ca.ibm.com <mailto:merks@ca.ibm.com>> wrote in
> message news:fb9rq3$hsj$1@build.eclipse.org...
> Pavel,
>
> Comments below.
>
> Pavel wrote:
>> Greetings,
>>
>> Is there a good criteria to choose GEF over GMF or vice versa?
>>
>> In my application I'd like to expose graphical editor, which is not objects
>> and connections, but mostly diagrams with range selection tool. For a couple
>> of reasons the model needs to be persisted with JDO/JPOX.
>>
> Did you know that EMFT's Teneo project supports persisting models
> using JDO/JPOX:
>
> http://www.eclipse.org/modeling/emft/?project=teneo#teneo
>
>> So at first glance it seems that GEF is sufficient and less complicated. On
>> the other hand I've got the feeling that GMF is more actively developed
>> framework (just a feeling, no real facts =)).
>>
> GMF is definitely a more complex framework but also a richer one.
> Since you can quickly generate a fully functional editor from a
> model description, it seems a good way to get started quickly
> without having to understand all the details of the whole framework.
>> Can you please suggest the way to make a good choice?
>>
>> There are two distinct questions actually:
>> 1. General criteria for GEF vs GMF.
>>
> If you have a model, you'll have a working prototype generated by
> GMF. This might well address your needs. If it doesn't you'll
> still have a functional example based on your domain that might
> prove useful. GEF from scratch will likely involve significant up
> front work before you have something cool working.
>> 2. Suitable choice for my case.
>> I'd be happy to know your opinion on both.
>>
> I think GEF is excellent. It's just that in most cases there is
> also an underlying model being edited and for that EMF provides
> much value. And when you want to combine the two GMF provides the
> glue and a great deal of additional value.
>> Thanks,
>> Pavel
>>
>>
>>
>
--------------000006000801000907010607
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Pavel,<br>
<br>
I'm not absolutely sure, but I believe anything you can do with GEF
you'll be able to exploit in GMF.<br>
<br>
<br>
Pavel wrote:
<blockquote cite="mid:fbcb0l$bdu$1@build.eclipse.org" type="cite">
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<meta content="MSHTML 6.00.2900.2180" name="GENERATOR">
<style></style>
<div><font face="Arial" size="2">Ed,</font></div>
<div> </div>
<div><font face="Arial" size="2">Thanks for your comments. If I
understand correctly, for cases with model involved (and this is, well,
close to 100%) GMF would be a proper choice.</font></div>
<div> </div>
<div><font face="Arial" size="2">Is it correct that GMF provides a
superset of GEF features? That is, if you can do something with pure
GEF, that will be possible with GMF as well.</font></div>
<div><font face="Arial" size="2">If not, what sort of things you
think are going to be difficult/unavailable to implement with GMF?</font></div>
<div> </div>
<div><font face="Arial" size="2">Thanks,</font></div>
<div><font face="Arial" size="2">Pavel</font></div>
<blockquote
style="border-left: 2px solid rgb(0, 0, 0); padding-right: 0px; padding-left: 5px; margin-left: 5px; margin-right: 0px;">
<div>"Ed Merks" <<a moz-do-not-send="true"
href="mailto:merks@ca.ibm.com">merks@ca.ibm.com</a>> wrote in
message <a moz-do-not-send="true"
href="news:fb9rq3$hsj$1@build.eclipse.org">news:fb9rq3$hsj$1@build.eclipse.org</a>...</div>
Pavel,<br>
<br>
Comments below.<br>
<br>
Pavel wrote:
<blockquote cite="mid:fb9oc7$q3e$1@build.eclipse.org" type="cite">
<pre wrap="">Greetings,
Is there a good criteria to choose GEF over GMF or vice versa?
In my application I'd like to expose graphical editor, which is not objects
and connections, but mostly diagrams with range selection tool. For a couple
of reasons the model needs to be persisted with JDO/JPOX.
</pre>
</blockquote>
Did you know that EMFT's Teneo project supports persisting models using
JDO/JPOX:<br>
<blockquote><a moz-do-not-send="true"
href="http://www.eclipse.org/modeling/emft/?project=teneo#teneo">http://www.eclipse.org/modeling/emft/?project=teneo#teneo</a><br>
</blockquote>
<blockquote cite="mid:fb9oc7$q3e$1@build.eclipse.org" type="cite">
<pre wrap="">So at first glance it seems that GEF is sufficient and less complicated. On
the other hand I've got the feeling that GMF is more actively developed
framework (just a feeling, no real facts =)).
</pre>
</blockquote>
GMF is definitely a more complex framework but also a richer one.
Since you can quickly generate a fully functional editor from a model
description, it seems a good way to get started quickly without having
to understand all the details of the whole framework.<br>
<blockquote cite="mid:fb9oc7$q3e$1@build.eclipse.org" type="cite">
<pre wrap="">Can you please suggest the way to make a good choice?
There are two distinct questions actually:
1. General criteria for GEF vs GMF.
</pre>
</blockquote>
If you have a model, you'll have a working prototype generated by GMF.
This might well address your needs. If it doesn't you'll still have a
functional example based on your domain that might prove useful. GEF
from scratch will likely involve significant up front work before you
have something cool working.<br>
<blockquote cite="mid:fb9oc7$q3e$1@build.eclipse.org" type="cite">
<pre wrap="">2. Suitable choice for my case.
I'd be happy to know your opinion on both.
</pre>
</blockquote>
I think GEF is excellent. It's just that in most cases there is also
an underlying model being edited and for that EMF provides much value.
And when you want to combine the two GMF provides the glue and a great
deal of additional value.<br>
<blockquote cite="mid:fb9oc7$q3e$1@build.eclipse.org" type="cite">
<pre wrap="">Thanks,
Pavel
</pre>
</blockquote>
<br>
</blockquote>
</blockquote>
<br>
</body>
</html>
--------------000006000801000907010607--
|
|
|
| Re: GEF/GMF: choice criteria [message #238241 is a reply to message #238236] |
Sat, 01 September 2007 19:00 |
| Eclipse User |
|
|
|
Originally posted by: pagrus+eclipse.gmail.com
This is a multi-part message in MIME format.
------=_NextPart_000_0008_01C7ECE3.8F3DECC0
Content-Type: text/plain;
charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Thanks again for your comments. I think I see the direction to go =
further.
"Ed Merks" <merks@ca.ibm.com> wrote in message =
news:fbcbjc$c8m$1@build.eclipse.org...
Pavel,
I'm not absolutely sure, but I believe anything you can do with GEF =
you'll be able to exploit in GMF.
Pavel wrote:=20
Ed,
Thanks for your comments. If I understand correctly, for cases with =
model involved (and this is, well, close to 100%) GMF would be a proper =
choice.
Is it correct that GMF provides a superset of GEF features? That is, =
if you can do something with pure GEF, that will be possible with GMF as =
well.
If not, what sort of things you think are going to be =
difficult/unavailable to implement with GMF?
Thanks,
Pavel
"Ed Merks" <merks@ca.ibm.com> wrote in message =
news:fb9rq3$hsj$1@build.eclipse.org...
Pavel,
Comments below.
Pavel wrote:=20
Greetings,
Is there a good criteria to choose GEF over GMF or vice versa?
In my application I'd like to expose graphical editor, which is not =
objects=20
and connections, but mostly diagrams with range selection tool. For a =
couple=20
of reasons the model needs to be persisted with JDO/JPOX.
Did you know that EMFT's Teneo project supports persisting models =
using JDO/JPOX:
http://www.eclipse.org/modeling/emft/?project=3Dteneo#teneo
So at first glance it seems that GEF is sufficient and less complicated. =
On=20
the other hand I've got the feeling that GMF is more actively developed=20
framework (just a feeling, no real facts =3D)).
GMF is definitely a more complex framework but also a richer one. =
Since you can quickly generate a fully functional editor from a model =
description, it seems a good way to get started quickly without having =
to understand all the details of the whole framework.
Can you please suggest the way to make a good choice?
There are two distinct questions actually:
1. General criteria for GEF vs GMF.
If you have a model, you'll have a working prototype generated by GMF. =
This might well address your needs. If it doesn't you'll still have a =
functional example based on your domain that might prove useful. GEF =
from scratch will likely involve significant up front work before you =
have something cool working.
2. Suitable choice for my case.
I'd be happy to know your opinion on both.
I think GEF is excellent. It's just that in most cases there is also =
an underlying model being edited and for that EMF provides much value. =
And when you want to combine the two GMF provides the glue and a great =
deal of additional value.
Thanks,
Pavel=20
=20
------=_NextPart_000_0008_01C7ECE3.8F3DECC0
Content-Type: text/html;
charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type =
content=3Dtext/html;charset=3DISO-8859-1>
<META content=3D"MSHTML 6.00.2900.2180" name=3DGENERATOR></HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Thanks again for your comments. I think =
I see the=20
direction to go further.</FONT></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Ed Merks" <<A =
href=3D"mailto:merks@ca.ibm.com">merks@ca.ibm.com</A>>=20
wrote in message <A=20
=
href=3D"news:fbcbjc$c8m$1@build.eclipse.org">news:fbcbjc$c8m$1@build.ecli=
pse.org</A>...</DIV>Pavel,<BR><BR>I'm=20
not absolutely sure, but I believe anything you can do with GEF you'll =
be able=20
to exploit in GMF.<BR><BR><BR>Pavel wrote:=20
<BLOCKQUOTE cite=3Dmid:fbcb0l$bdu$1@build.eclipse.org type=3D"cite">
<META content=3D"MSHTML 6.00.2900.2180" name=3DGENERATOR>
<STYLE></STYLE>
<DIV><FONT face=3DArial size=3D2>Ed,</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>Thanks for your comments. If I =
understand=20
correctly, for cases with model involved (and this is, well, close =
to=20
100%) GMF would be a proper choice.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>Is it correct that GMF provides a =
superset of=20
GEF features? That is, if you can do something with pure GEF, that =
will be=20
possible with GMF as well.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>If not, what sort of =
things you think are=20
going to be difficult/unavailable to implement with =
GMF?</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>Thanks,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Pavel</FONT></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: rgb(0,0,0) 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Ed Merks" <<A href=3D"mailto:merks@ca.ibm.com"=20
moz-do-not-send=3D"true">merks@ca.ibm.com</A>> wrote in message =
<A=20
href=3D"news:fb9rq3$hsj$1@build.eclipse.org"=20
=
moz-do-not-send=3D"true">news:fb9rq3$hsj$1@build.eclipse.org</A>...</DIV>=
Pavel,<BR><BR>Comments=20
below.<BR><BR>Pavel wrote:=20
<BLOCKQUOTE cite=3Dmid:fb9oc7$q3e$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D"">Greetings,
Is there a good criteria to choose GEF over GMF or vice versa?
In my application I'd like to expose graphical editor, which is not =
objects=20
and connections, but mostly diagrams with range selection tool. For a =
couple=20
of reasons the model needs to be persisted with JDO/JPOX.
</PRE></BLOCKQUOTE>Did you know that EMFT's Teneo project supports=20
persisting models using JDO/JPOX:<BR>
<BLOCKQUOTE><A=20
=
href=3D"http://www.eclipse.org/modeling/emft/?project=3Dteneo#teneo"=20
=
moz-do-not-send=3D"true">http://www.eclipse.org/modeling/emft/?project=3D=
teneo#teneo</A><BR></BLOCKQUOTE>
<BLOCKQUOTE cite=3Dmid:fb9oc7$q3e$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D"">So at first glance it seems that GEF is =
sufficient and less complicated. On=20
the other hand I've got the feeling that GMF is more actively developed=20
framework (just a feeling, no real facts =3D)).
</PRE></BLOCKQUOTE>GMF is definitely a more complex framework but also =
a=20
richer one. Since you can quickly generate a fully =
functional editor=20
from a model description, it seems a good way to get started =
quickly=20
without having to understand all the details of the whole =
framework.<BR>
<BLOCKQUOTE cite=3Dmid:fb9oc7$q3e$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D"">Can you please suggest the way to make a =
good choice?
There are two distinct questions actually:
1. General criteria for GEF vs GMF.
</PRE></BLOCKQUOTE>If you have a model, you'll have a working =
prototype=20
generated by GMF. This might well address your needs. =
If it=20
doesn't you'll still have a functional example based on your =
domain that=20
might prove useful. GEF from scratch will likely involve =
significant=20
up front work before you have something cool working.<BR>
<BLOCKQUOTE cite=3Dmid:fb9oc7$q3e$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D"">2. Suitable choice for my case.
I'd be happy to know your opinion on both.
</PRE></BLOCKQUOTE>I think GEF is excellent. It's just that in=20
most cases there is also an underlying model being edited and for =
that EMF=20
provides much value. And when you want to combine the two =
GMF=20
provides the glue and a great deal of additional value.<BR>
<BLOCKQUOTE cite=3Dmid:fb9oc7$q3e$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D"">Thanks,
Pavel=20
=
</PRE></BLOCKQUOTE><BR></BLOCKQUOTE></BLOCKQUOTE><BR></BLOCKQUOTE ></BODY>=
</HTML>
------=_NextPart_000_0008_01C7ECE3.8F3DECC0--
|
|
|
| Re: GEF/GMF: choice criteria [message #238294 is a reply to message #238241] |
Tue, 04 September 2007 17:03 |
 Adam Cabler
Messages: 113
Registered: July 2009 |
Senior Member |
|
|
Pavel,
One other thing about GMF. I have heard that there have been many
improvements to the GEF framework that only live in GMF - so you may get
a better GEF by going with GMF.
Pavel wrote:
> Thanks again for your comments. I think I see the direction to go further.
>
> "Ed Merks" <merks@ca.ibm.com <mailto:merks@ca.ibm.com>> wrote in
> message news:fbcbjc$c8m$1@build.eclipse.org...
> Pavel,
>
> I'm not absolutely sure, but I believe anything you can do with
> GEF you'll be able to exploit in GMF.
>
>
> Pavel wrote:
>> Ed,
>>
>> Thanks for your comments. If I understand correctly, for cases
>> with model involved (and this is, well, close to 100%) GMF would
>> be a proper choice.
>>
>> Is it correct that GMF provides a superset of GEF features? That
>> is, if you can do something with pure GEF, that will be possible
>> with GMF as well.
>> If not, what sort of things you think are going to be
>> difficult/unavailable to implement with GMF?
>>
>> Thanks,
>> Pavel
>>
>> "Ed Merks" <merks@ca.ibm.com <mailto:merks@ca.ibm.com>> wrote
>> in message news:fb9rq3$hsj$1@build.eclipse.org...
>> Pavel,
>>
>> Comments below.
>>
>> Pavel wrote:
>>> Greetings,
>>>
>>> Is there a good criteria to choose GEF over GMF or vice versa?
>>>
>>> In my application I'd like to expose graphical editor, which is not objects
>>> and connections, but mostly diagrams with range selection tool. For a couple
>>> of reasons the model needs to be persisted with JDO/JPOX.
>>>
>> Did you know that EMFT's Teneo project supports persisting
>> models using JDO/JPOX:
>>
>> http://www.eclipse.org/modeling/emft/?project=teneo#teneo
>>
>>> So at first glance it seems that GEF is sufficient and less complicated. On
>>> the other hand I've got the feeling that GMF is more actively developed
>>> framework (just a feeling, no real facts =)).
>>>
>> GMF is definitely a more complex framework but also a richer
>> one. Since you can quickly generate a fully functional
>> editor from a model description, it seems a good way to get
>> started quickly without having to understand all the details
>> of the whole framework.
>>> Can you please suggest the way to make a good choice?
>>>
>>> There are two distinct questions actually:
>>> 1. General criteria for GEF vs GMF.
>>>
>> If you have a model, you'll have a working prototype
>> generated by GMF. This might well address your needs. If it
>> doesn't you'll still have a functional example based on your
>> domain that might prove useful. GEF from scratch will likely
>> involve significant up front work before you have something
>> cool working.
>>> 2. Suitable choice for my case.
>>> I'd be happy to know your opinion on both.
>>>
>> I think GEF is excellent. It's just that in most cases there
>> is also an underlying model being edited and for that EMF
>> provides much value. And when you want to combine the two
>> GMF provides the glue and a great deal of additional value.
>>> Thanks,
>>> Pavel
>>>
>>>
>>>
>>
>
|
|
|
| Re: GEF/GMF: choice criteria [message #238379 is a reply to message #238236] |
Sat, 08 September 2007 01:28 |
| Eclipse User |
|
|
|
Originally posted by: none.ibm.com
This is a multi-part message in MIME format.
------=_NextPart_000_005A_01C7F196.032FEF50
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Ed, GMF imposes additional restrictions besides the obvious (that your =
EMF model based on GMF's EMF model). For example, if you try to modify =
your model and you're not executing a command, GMF throws exceptions. =
This makes it hard to do simple things like "soft" changes to your =
model, such as modifying the zoom level, ruler visibility, etc.
------=_NextPart_000_005A_01C7F196.032FEF50
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type =
content=3Dtext/html;charset=3DISO-8859-1>
<META content=3D"MSHTML 6.00.2900.3157" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Ed, GMF imposes additional restrictions =
besides the=20
obvious (that your EMF model based on GMF's EMF model). For =
example, if you=20
try to modify your model and you're not executing a command, GMF throws=20
exceptions. This makes it hard to do simple things like "soft" changes =
to your=20
model, such as modifying the zoom level, ruler visibility,=20
etc.</FONT></DIV></BODY></HTML>
------=_NextPart_000_005A_01C7F196.032FEF50--
|
|
|
| Re: GEF/GMF: choice criteria [message #238771 is a reply to message #238379] |
Tue, 02 October 2007 07:53 |
Stefan Holzknecht
Messages: 31
Registered: July 2009 |
Member |
|
|
Randy Hudson wrote:
> Ed, GMF imposes additional restrictions besides the obvious (that your
> EMF model based on GMF's EMF model). For example, if you try to modify
> your model and you're not executing a command, GMF throws exceptions.
> This makes it hard to do simple things like "soft" changes to your
> model, such as modifying the zoom level, ruler visibility, etc.
I fully agree with you Randy. And nevertheless that nobody mention the
emf model things as a restriction I truly feel so. Using emf you don't
get neither simple Java Beans (in my poor opinion an emf model is
actually not much more than a masqueraded bean) nor real eclipse objects
(besides other things the emf classes reinvent the IAdaptable mechanism
and does not really fit into eclipse). Of course emf-models have their
use, but not everone really needs them.
And to be honest, I could not see a real proof that GMF really makes it
easier to develop a good graphical editor. Of course you can create a
prototype in a short time. But only If you really know thats going on
behind. And if you need a non-default solution (I'm not sure how many
editors fit into this default category, 10percent?) you also need to
dive deep into all affected frame works, tools and so on. You not only
have to become a GEF expert but you need deep knowledge about the glue
(gmf), emf and all the little things that might distract you.
I'm a bit sad that GEF tooling does not really improve anymore.
Stefan
|
|
|
| Re: GEF/GMF: choice criteria [message #238781 is a reply to message #238771] |
Tue, 02 October 2007 12:40 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Stefan,
Comments below.
Stefan Holzknecht wrote:
> Randy Hudson wrote:
>> Ed, GMF imposes additional restrictions besides the obvious (that
>> your EMF model based on GMF's EMF model). For example, if you try to
>> modify your model and you're not executing a command, GMF throws
>> exceptions. This makes it hard to do simple things like "soft"
>> changes to your model, such as modifying the zoom level, ruler
>> visibility, etc.
>
> I fully agree with you Randy. And nevertheless that nobody mention the
> emf model things as a restriction I truly feel so.
Obviously I'm going to disagree strongly. I don't believe you'll be
able to argue convincingly that you can do better writing by hand what
EMF generates for you at the push of a button...
> Using emf you don't get neither simple Java Beans (in my poor opinion
> an emf model is actually not much more than a masqueraded bean) nor
> real eclipse objects (besides other things the emf classes reinvent
> the IAdaptable mechanism and does not really fit into eclipse). Of
> course emf-models have their use, but not everone really needs them.
What exactly makes Java Beans simple? And if EMF is basically just a
Bean, which you seem to think would be a good thing, why isn't that
good? It would be trivial to make EMF objects implement IAdaptable if
you so desire. Extend EObjectImpl to mix in that interface and then use
that base class as the base class for all your generated class. Your
imagination is likely the only limiting factor. It seems to me that
anyone needing to persist whatever it is they are graphically editing
will likely be able to benefit from EMF's support for that (as is
currently the case for Randy). Similarly, the need for undo and redo
support is not trivial to achieve using Beans. So your view seems to be
restricted to an extremely narrow range of use cases.
> And to be honest, I could not see a real proof that GMF really makes
> it easier to develop a good graphical editor. Of course you can create
> a prototype in a short time.
Having a prototype is one heck of a lot better than staring at a blank
screen and hoping to have at least some working code.
> But only If you really know thats going on behind.
You're going to have to learn a lot of GEF to get only as far as the
functional prototype.
> And if you need a non-default solution (I'm not sure how many editors
> fit into this default category, 10percent?) you also need to dive deep
> into all affected frame works, tools and so on.
Certainly by the time you've learned to use GEF to create an editor the
serializes your graphical view along with the "model" it edits and
supports undo and redo fully, you'll have dived very deeply indeed.
> You not only have to become a GEF expert but you need deep knowledge
> about the glue (gmf), emf and all the little things that might
> distract you.
I would argue that they will eliminate the monkey work while letting you
focus on your value add.
> I'm a bit sad that GEF tooling does not really improve anymore.
Are you doing anything to help? Open source might be free, but it does
actually cost realy money to develop, document, support, and enhance it.
> Stefan
|
|
|
| Re: GEF/GMF: choice criteria [message #238801 is a reply to message #238781] |
Tue, 02 October 2007 19:02 |
Stefan Holzknecht
Messages: 31
Registered: July 2009 |
Member |
|
|
Hello Ed,
I did'nt say that emf beans are good or bad. But I don't see a real
reason to develop features in GMF that might better belong to GEF and
that do not depend on a particular (or advanced) model concept (e.g.
additional layouters, curved lines etc). I also see other examples (e.g.
xsd, wsdl editors) that do not use EMF model elements. In these cases
you don't need to solve a problem about saving any graphical view data
either. For undo/redo I would prefer a non emf-only version. Now we have
GEF commands and command stacks, commands in eclipse and another ones in
emf. It is probably difficult to merge that, but it would be great.
I'm pretty sure that developing software costs money. I'm a bit puzzled
about your hint. Do you mean that only persons that provide code or help
are allowed to interfere?
Stefan
Ed Merks wrote:
> Stefan,
>
> Comments below.
>
> Stefan Holzknecht wrote:
>
>> Randy Hudson wrote:
>>
>>> Ed, GMF imposes additional restrictions besides the obvious (that
>>> your EMF model based on GMF's EMF model). For example, if you try to
>>> modify your model and you're not executing a command, GMF throws
>>> exceptions. This makes it hard to do simple things like "soft"
>>> changes to your model, such as modifying the zoom level, ruler
>>> visibility, etc.
>>
>>
>> I fully agree with you Randy. And nevertheless that nobody mention the
>> emf model things as a restriction I truly feel so.
>
> Obviously I'm going to disagree strongly. I don't believe you'll be
> able to argue convincingly that you can do better writing by hand what
> EMF generates for you at the push of a button...
>
>> Using emf you don't get neither simple Java Beans (in my poor opinion
>> an emf model is actually not much more than a masqueraded bean) nor
>> real eclipse objects (besides other things the emf classes reinvent
>> the IAdaptable mechanism and does not really fit into eclipse). Of
>> course emf-models have their use, but not everone really needs them.
>
> What exactly makes Java Beans simple? And if EMF is basically just a
> Bean, which you seem to think would be a good thing, why isn't that
> good? It would be trivial to make EMF objects implement IAdaptable if
> you so desire. Extend EObjectImpl to mix in that interface and then use
> that base class as the base class for all your generated class. Your
> imagination is likely the only limiting factor. It seems to me that
> anyone needing to persist whatever it is they are graphically editing
> will likely be able to benefit from EMF's support for that (as is
> currently the case for Randy). Similarly, the need for undo and redo
> support is not trivial to achieve using Beans. So your view seems to be
> restricted to an extremely narrow range of use cases.
>
>> And to be honest, I could not see a real proof that GMF really makes
>> it easier to develop a good graphical editor. Of course you can create
>> a prototype in a short time.
>
> Having a prototype is one heck of a lot better than staring at a blank
> screen and hoping to have at least some working code.
>
>> But only If you really know thats going on behind.
>
> You're going to have to learn a lot of GEF to get only as far as the
> functional prototype.
>
>> And if you need a non-default solution (I'm not sure how many editors
>> fit into this default category, 10percent?) you also need to dive deep
>> into all affected frame works, tools and so on.
>
> Certainly by the time you've learned to use GEF to create an editor the
> serializes your graphical view along with the "model" it edits and
> supports undo and redo fully, you'll have dived very deeply indeed.
>
>> You not only have to become a GEF expert but you need deep knowledge
>> about the glue (gmf), emf and all the little things that might
>> distract you.
>
> I would argue that they will eliminate the monkey work while letting you
> focus on your value add.
>
>> I'm a bit sad that GEF tooling does not really improve anymore.
>
> Are you doing anything to help? Open source might be free, but it does
> actually cost realy money to develop, document, support, and enhance it.
>
>> Stefan
|
|
|
| Re: GEF/GMF: choice criteria [message #238807 is a reply to message #238801] |
Tue, 02 October 2007 19:44 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Stefan,
Comments below.
Stefan Holzknecht wrote:
> Hello Ed,
> I did'nt say that emf beans are good or bad.
I must be feeling defensive. :-P
> But I don't see a real reason to develop features in GMF that might
> better belong to GEF and that do not depend on a particular (or
> advanced) model concept (e.g. additional layouters, curved lines etc).
> I also see other examples (e.g. xsd, wsdl editors) that do not use EMF
> model elements.
That's certainly a truism, but I doubt there are many applications like
that. I suspect most applications are about graphically rendering some
underlying "model" and then needing to persist both that graphical
rendering as well as the underlying model, often as two different
things, with the graphical rendering being more like a persistent view
of the model.
> In these cases you don't need to solve a problem about saving any
> graphical view data either. For undo/redo I would prefer a non
> emf-only version. Now we have GEF commands and command stacks,
> commands in eclipse and another ones in emf. It is probably difficult
> to merge that, but it would be great.
Yes, I find this incredibly frustrating, especially given that GEF's
version originated as a modified copy of the ones that were developed
and shared with EMF. But GEF was open sourced first. The the platform
stuff came along as if neither GEF nor EMF already exists (but at least
the platform stuff is mostly just scaffolding).
> I'm pretty sure that developing software costs money. I'm a bit
> puzzled about your hint. Do you mean that only persons that provide
> code or help are allowed to interfere?
My point is that the world is full of critics. I.e., many people can go
and look at a painting or a movie and critique it. But how many people
can make a better painting or a movie themselves? So while constructive
criticism is of course valuable in and of itself, if the world consisted
of only of those providing constructive feedback without a good share of
people to respond to that feedback in order to convert it into goodness,
we'd just have lots of hot air and not much else. It's like the old
saying "Ask not what your country can do for you, ask what you can do
for your country". I don't mean to imply you have no right to express
your opinions---it's an open source community and everyone is entitled
to their opinion--- I'm just reminding you and others that if you get
nothing, you're getting exactly what you paid for.
>
> Stefan
>
> Ed Merks wrote:
>> Stefan,
>>
>> Comments below.
>>
>> Stefan Holzknecht wrote:
>>
>>> Randy Hudson wrote:
>>>
>>>> Ed, GMF imposes additional restrictions besides the obvious (that
>>>> your EMF model based on GMF's EMF model). For example, if you try
>>>> to modify your model and you're not executing a command, GMF throws
>>>> exceptions. This makes it hard to do simple things like "soft"
>>>> changes to your model, such as modifying the zoom level, ruler
>>>> visibility, etc.
>>>
>>>
>>> I fully agree with you Randy. And nevertheless that nobody mention
>>> the emf model things as a restriction I truly feel so.
>>
>> Obviously I'm going to disagree strongly. I don't believe you'll be
>> able to argue convincingly that you can do better writing by hand
>> what EMF generates for you at the push of a button...
>>
>>> Using emf you don't get neither simple Java Beans (in my poor
>>> opinion an emf model is actually not much more than a masqueraded
>>> bean) nor real eclipse objects (besides other things the emf classes
>>> reinvent the IAdaptable mechanism and does not really fit into
>>> eclipse). Of course emf-models have their use, but not everone
>>> really needs them.
>>
>> What exactly makes Java Beans simple? And if EMF is basically just a
>> Bean, which you seem to think would be a good thing, why isn't that
>> good? It would be trivial to make EMF objects implement IAdaptable if
>> you so desire. Extend EObjectImpl to mix in that interface and then
>> use that base class as the base class for all your generated class.
>> Your imagination is likely the only limiting factor. It seems to me
>> that anyone needing to persist whatever it is they are graphically
>> editing will likely be able to benefit from EMF's support for that
>> (as is currently the case for Randy). Similarly, the need for undo
>> and redo support is not trivial to achieve using Beans. So your view
>> seems to be restricted to an extremely narrow range of use cases.
>>
>>> And to be honest, I could not see a real proof that GMF really makes
>>> it easier to develop a good graphical editor. Of course you can
>>> create a prototype in a short time.
>>
>> Having a prototype is one heck of a lot better than staring at a
>> blank screen and hoping to have at least some working code.
>>
>>> But only If you really know thats going on behind.
>>
>> You're going to have to learn a lot of GEF to get only as far as the
>> functional prototype.
>>
>>> And if you need a non-default solution (I'm not sure how many
>>> editors fit into this default category, 10percent?) you also need to
>>> dive deep into all affected frame works, tools and so on.
>>
>> Certainly by the time you've learned to use GEF to create an editor
>> the serializes your graphical view along with the "model" it edits
>> and supports undo and redo fully, you'll have dived very deeply indeed.
>>
>>> You not only have to become a GEF expert but you need deep knowledge
>>> about the glue (gmf), emf and all the little things that might
>>> distract you.
>>
>> I would argue that they will eliminate the monkey work while letting
>> you focus on your value add.
>>
>>> I'm a bit sad that GEF tooling does not really improve anymore.
>>
>> Are you doing anything to help? Open source might be free, but it
>> does actually cost realy money to develop, document, support, and
>> enhance it.
>>
>>> Stefan
|
|
|
| Re: GEF/GMF: choice criteria [message #239243 is a reply to message #238781] |
Sun, 14 October 2007 18:26 |
| Eclipse User |
|
|
|
Originally posted by: none.ibm.com
>> I fully agree with you Randy. And nevertheless that nobody mention the
>> emf model things as a restriction I truly feel so.
> Obviously I'm going to disagree strongly. I don't believe you'll be able
> to argue convincingly that you can do better writing by hand what EMF
> generates for you at the push of a button...
It wasn't clear to me if Stefan was criticizing EMF itself, or the fact that
GMF based application but use a specific EMF model. I'm guessing the
latter. EMF does a great job of generating a consistent, PoJo-like (meaning
in complexity, code-size, performance, etc.) model, but with lots of subtle
and useful hooks, improvements, and abstraction of detail (like maintaining
bidirectional, contained "linkageness")
>> Using emf you don't get neither simple Java Beans (in my poor opinion an
>> emf model is actually not much more than a masqueraded bean) nor real
>> eclipse objects (besides other things the emf classes reinvent
>> the IAdaptable mechanism and does not really fit into eclipse). Of
These are strengths, right ;-) ;-) ?!?
>> course emf-models have their use, but not everone really needs them.
I think we all know this, and your point here is probably that if you don't
need EMF, then non-EMF-specific features in GMF are difficult to reuse.
Probably a valid conclusion, but EMF is perhaps useful more often than you
expect. Even the XSD or WSDL editors you refered to later I believe use an
in-memory EMF model.
> What exactly makes Java Beans simple? And if EMF is basically just a
> Bean, which you seem to think would be a good thing, why isn't that good?
> It would be trivial to make EMF objects implement IAdaptable if you so
> desire. Extend EObjectImpl to mix in that interface and then use that
> base class as the base class for all your generated class. Your
> imagination is likely the only limiting factor. It seems to me that
> anyone needing to persist whatever it is they are graphically editing will
> likely be able to benefit from EMF's support for that (as is
EMF's adaptable and platform's adaptable aren't really the same, except in
name. EMF's adapting can be context-specific (resource-set scoped) and
supports adapters with a "lifecycle" for notification support, etc. EMF
also uses more flexible keys (Object instead of Class). I agree with Ed,
it's trivial to mixin IAdaptable and call out to the platform's adapter
menager.
> currently the case for Randy). Similarly, the need for undo and redo
> support is not trivial to achieve using Beans. So your view seems to be
> restricted to an extremely narrow range of use cases.
I don't see a big undo/redo difference. I prefer to implement command
myself coding directly to the EMF interfaces.
>> And to be honest, I could not see a real proof that GMF really makes it
>> easier to develop a good graphical editor. Of course you can create a
>> prototype in a short time.
> Having a prototype is one heck of a lot better than staring at a blank
> screen and hoping to have at least some working code.
This is a valid debate, but one in which I don't think either side will ever
be declared the winner. It depends on what your goals are, what can be
generated/provided, and what you are capable of developing "in-house". In
general, each dependency gives you some initial productivity gain, hopefully
long-term productivity gains, but also adds "weight" or "baggage". I think
it's up to the consumer to make the right call. If Framework X gets you 75%
to where you want to be, you need to *re-size* that remaining 25%
considering the presence of framework X. There will be times when that
remaining 25% grows to 100% or more. **If** that's true for you, then maybe
staring at a blank screen is the best place to be.
>> But only If you really know thats going on behind.
> You're going to have to learn a lot of GEF to get only as far as the
> functional prototype.
>> And if you need a non-default solution (I'm not sure how many editors fit
>> into this default category, 10percent?) you also need to dive deep into
>> all affected frame works, tools and so on.
> Certainly by the time you've learned to use GEF to create an editor the
> serializes your graphical view along with the "model" it edits and
> supports undo and redo fully, you'll have dived very deeply indeed.
Ed, it's similar to learning EMF, vs. EMF Edit. To learn EMF Edit, the
total learning curve is most likely bigger than learning only EMF and JFace.
But maybe the EMF+JFace portion of that curve is smaller in the former.
>> You not only have to become a GEF expert but you need deep knowledge
>> about the glue (gmf), emf and all the little things that might distract
>> you.
> I would argue that they will eliminate the monkey work while letting you
> focus on your value add.
Ed, if you _had_ decided to argue that :-) :-), I would have argued that the
cost of "adding your value" increases in some cases.
>> I'm a bit sad that GEF tooling does not really improve anymore.
> Are you doing anything to help? Open source might be free, but it does
> actually cost realy money to develop, document, support, and enhance it.
I think maybe Stefan is trying to help, although maybe not in the most
constructive or obvious way. Given that companies are already contributing
limited resources to develop open source components, it makes some sense to
talk about resource allocation. Think of it as performing a "my return on
your investment" analysis.
Stefan, it would be great if you could (also) contribute code, etc. to
Eclipse, or suggest some concrete enhancements (with use cases) which you'd
like to see added to GEF.
|
|
|
Goto Forum:
Current Time: Fri Apr 19 10:18:55 GMT 2024
Powered by FUDForum. Page generated in 0.03121 seconds |
] 
Search
Help
Register
Login
Home
