Home » Eclipse Projects » GEF » GEF as GUI engine ?
| GEF as GUI engine ? [message #241277] |
Wed, 06 February 2008 10:14  |
Eclipse User |
|
|
|
Originally posted by: omoises.nospam-nordnet.fr
Hi all,
The last weeks I created a POC using EMF as a GUI model and GEF as
rendering engine.
The main purpose is to be able to build a GUI using GEF (as a GUI
engine, not GUI builder).
As a (very simple) model, for example, I could have :
Composite
+ Button
+ FlowLayout
At the moment, everything works well, including layout adapters and/or
button listeners.
I developed a specific GEF Viewer, implemented ControlEditPart &
ContainerEditPart abstract classes and tested the model with different
layouts/layoutDatas.
I also implemented TextEditPart to be able to fill a really simple form.
Comparing to usual GEF purposes, building a GUI does not use a lot of
EditPolicies or other specific GEF features.
As a leasyweight rendering engine, GEF could be compared to AWT/Swing
and brings some concerns about performances, but from my experience, the
most part of existing applications forms contains less than one or two
dozens of controls (and GEF is able to draw diagrams containing more
than that).
GEF provides also lot of features which could be used to buid really
nice zoomable user interfaces.
The real problems come now :
In order to use more complicated forms, I need to provide Tables & Trees
(inside the GEF viewer).
I can bypass a large part of them using (non GEF) usual eclipse views
(like package explorer which is a Tree), but in some cases, users should
find a tree or a table into a form !
I think there is two ways of providing tables or trees in a GEF viewer :
1°) drawing them (and providing a viewer like StructuredViewer ) for
small number of items only (probably less than 100)
2°) embeding SWT Table or Tree into GEF Figures (since I don't need the
same interaction level than in Diagrams, I could drop paint methods for
example).
I started also as a new POC a SWTViewer (not ended yet, then not
working :-( ) using GEF without draw2d (like in TreeEditPart) as a new
SWT based rendering engine using the same type of model.
I would like to open a thread about this, because several metaphysic
questions occur now :
Shall I continue to use GEF for this ?
Shall I prefer to use SWT instead ???
(Non exhaustive list)
My preference at the moment is for GEF, but I am not sure !
What do you think about it ?????
Regards,
Olivier Moïses
|
|
|
| Re: GEF as GUI engine ? [message #241288 is a reply to message #241277] |
Wed, 06 February 2008 11:49  |
 Xiang Qinxian
Messages: 119
Registered: July 2009 |
Senior Member |
|
|
Hi,
A great and hard work:)
GEF palette is very good sample.
IMO, Draw2D fill some white of SWT.
I wonder that No one work a SVG engine based GEF and Draw2d.
Cheers,
Xiangya
Olivier Moïses 写道:
> Hi all,
>
> The last weeks I created a POC using EMF as a GUI model and GEF as
> rendering engine.
> The main purpose is to be able to build a GUI using GEF (as a GUI
> engine, not GUI builder).
>
> As a (very simple) model, for example, I could have :
>
> Composite
> + Button
> + FlowLayout
>
> At the moment, everything works well, including layout adapters and/or
> button listeners.
> I developed a specific GEF Viewer, implemented ControlEditPart &
> ContainerEditPart abstract classes and tested the model with different
> layouts/layoutDatas.
> I also implemented TextEditPart to be able to fill a really simple form.
> Comparing to usual GEF purposes, building a GUI does not use a lot of
> EditPolicies or other specific GEF features.
> As a leasyweight rendering engine, GEF could be compared to AWT/Swing
> and brings some concerns about performances, but from my experience, the
> most part of existing applications forms contains less than one or two
> dozens of controls (and GEF is able to draw diagrams containing more
> than that).
> GEF provides also lot of features which could be used to buid really
> nice zoomable user interfaces.
>
> The real problems come now :
>
> In order to use more complicated forms, I need to provide Tables & Trees
> (inside the GEF viewer).
> I can bypass a large part of them using (non GEF) usual eclipse views
> (like package explorer which is a Tree), but in some cases, users should
> find a tree or a table into a form !
> I think there is two ways of providing tables or trees in a GEF viewer :
>
> 1°) drawing them (and providing a viewer like StructuredViewer ) for
> small number of items only (probably less than 100)
> 2°) embeding SWT Table or Tree into GEF Figures (since I don't need the
> same interaction level than in Diagrams, I could drop paint methods for
> example).
>
> I started also as a new POC a SWTViewer (not ended yet, then not
> working :-( ) using GEF without draw2d (like in TreeEditPart) as a new
> SWT based rendering engine using the same type of model.
>
> I would like to open a thread about this, because several metaphysic
> questions occur now :
> Shall I continue to use GEF for this ?
> Shall I prefer to use SWT instead ???
> (Non exhaustive list)
>
> My preference at the moment is for GEF, but I am not sure !
>
> What do you think about it ?????
>
> Regards,
>
> Olivier Moïses
|
|
|
| Re: GEF as GUI engine ? [message #242056 is a reply to message #241288] |
Mon, 31 March 2008 06:58 |
Yves YANG
Messages: 688
Registered: July 2009 |
Senior Member |
|
|
We have plan a subproject under VE to deal with this issue.
Best regards
Yves YANG
----
http://www.soyatec.com
"Qinxian" <fyaoxy@gmail.com> wrote in message
news:foc6sn$lgs$1@build.eclipse.org...
> Hi,
> A great and hard work:)
> GEF palette is very good sample.
> IMO, Draw2D fill some white of SWT.
> I wonder that No one work a SVG engine based GEF and Draw2d.
>
> Cheers,
> Xiangya
>
>
> Olivier Moïses 写道:
>> Hi all,
>>
>> The last weeks I created a POC using EMF as a GUI model and GEF as
>> rendering engine.
>> The main purpose is to be able to build a GUI using GEF (as a GUI engine,
>> not GUI builder).
>>
>> As a (very simple) model, for example, I could have :
>> Composite
>> + Button
>> + FlowLayout
>>
>> At the moment, everything works well, including layout adapters and/or
>> button listeners.
>> I developed a specific GEF Viewer, implemented ControlEditPart &
>> ContainerEditPart abstract classes and tested the model with different
>> layouts/layoutDatas.
>> I also implemented TextEditPart to be able to fill a really simple form.
>> Comparing to usual GEF purposes, building a GUI does not use a lot of
>> EditPolicies or other specific GEF features.
>> As a leasyweight rendering engine, GEF could be compared to AWT/Swing and
>> brings some concerns about performances, but from my experience, the most
>> part of existing applications forms contains less than one or two dozens
>> of controls (and GEF is able to draw diagrams containing more than that).
>> GEF provides also lot of features which could be used to buid really nice
>> zoomable user interfaces.
>>
>> The real problems come now :
>>
>> In order to use more complicated forms, I need to provide Tables & Trees
>> (inside the GEF viewer).
>> I can bypass a large part of them using (non GEF) usual eclipse views
>> (like package explorer which is a Tree), but in some cases, users should
>> find a tree or a table into a form !
>> I think there is two ways of providing tables or trees in a GEF viewer :
>>
>> 1°) drawing them (and providing a viewer like StructuredViewer ) for
>> small number of items only (probably less than 100)
>> 2°) embeding SWT Table or Tree into GEF Figures (since I don't need the
>> same interaction level than in Diagrams, I could drop paint methods for
>> example).
>>
>> I started also as a new POC a SWTViewer (not ended yet, then not working
>> :-( ) using GEF without draw2d (like in TreeEditPart) as a new SWT based
>> rendering engine using the same type of model.
>>
>> I would like to open a thread about this, because several metaphysic
>> questions occur now :
>> Shall I continue to use GEF for this ?
>> Shall I prefer to use SWT instead ???
>> (Non exhaustive list)
>>
>> My preference at the moment is for GEF, but I am not sure !
>> What do you think about it ?????
>> Regards,
>>
>> Olivier Moïses
|
|
|
| Re: GEF as GUI engine ? [message #242365 is a reply to message #242056] |
Mon, 14 April 2008 01:50 |
Xiang Qinxian
Messages: 119
Registered: July 2009 |
Senior Member |
|
|
Hi YANG,
I would get time to check out it.
The world and the time always make it happend at when it happen:)
Best regards,
Qinxian
Yves YANG 写道:
> We have plan a subproject under VE to deal with this issue.
>
> Best regards
> Yves YANG
> ----
> http://www.soyatec.com
>
> "Qinxian" <fyaoxy@gmail.com> wrote in message
> news:foc6sn$lgs$1@build.eclipse.org...
>> Hi,
>> A great and hard work:)
>> GEF palette is very good sample.
>> IMO, Draw2D fill some white of SWT.
>> I wonder that No one work a SVG engine based GEF and Draw2d.
>>
>> Cheers,
>> Xiangya
>>
>>
>> Olivier Moïses 写道:
>>> Hi all,
>>>
>>> The last weeks I created a POC using EMF as a GUI model and GEF as
>>> rendering engine.
>>> The main purpose is to be able to build a GUI using GEF (as a GUI
>>> engine, not GUI builder).
>>>
>>> As a (very simple) model, for example, I could have :
>>> Composite
>>> + Button
>>> + FlowLayout
>>>
>>> At the moment, everything works well, including layout adapters
>>> and/or button listeners.
>>> I developed a specific GEF Viewer, implemented ControlEditPart &
>>> ContainerEditPart abstract classes and tested the model with
>>> different layouts/layoutDatas.
>>> I also implemented TextEditPart to be able to fill a really simple form.
>>> Comparing to usual GEF purposes, building a GUI does not use a lot of
>>> EditPolicies or other specific GEF features.
>>> As a leasyweight rendering engine, GEF could be compared to AWT/Swing
>>> and brings some concerns about performances, but from my experience,
>>> the most part of existing applications forms contains less than one
>>> or two dozens of controls (and GEF is able to draw diagrams
>>> containing more than that).
>>> GEF provides also lot of features which could be used to buid really
>>> nice zoomable user interfaces.
>>>
>>> The real problems come now :
>>>
>>> In order to use more complicated forms, I need to provide Tables &
>>> Trees (inside the GEF viewer).
>>> I can bypass a large part of them using (non GEF) usual eclipse views
>>> (like package explorer which is a Tree), but in some cases, users
>>> should find a tree or a table into a form !
>>> I think there is two ways of providing tables or trees in a GEF viewer :
>>>
>>> 1°) drawing them (and providing a viewer like StructuredViewer ) for
>>> small number of items only (probably less than 100)
>>> 2°) embeding SWT Table or Tree into GEF Figures (since I don't need
>>> the same interaction level than in Diagrams, I could drop paint
>>> methods for example).
>>>
>>> I started also as a new POC a SWTViewer (not ended yet, then not
>>> working :-( ) using GEF without draw2d (like in TreeEditPart) as a
>>> new SWT based rendering engine using the same type of model.
>>>
>>> I would like to open a thread about this, because several metaphysic
>>> questions occur now :
>>> Shall I continue to use GEF for this ?
>>> Shall I prefer to use SWT instead ???
>>> (Non exhaustive list)
>>>
>>> My preference at the moment is for GEF, but I am not sure !
>>> What do you think about it ?????
>>> Regards,
>>>
>>> Olivier Moïses
>
|
|
|
Goto Forum:
Current Time: Thu Apr 25 15:22:18 GMT 2024
Powered by FUDForum. Page generated in 0.03165 seconds |
] 
Search
Help
Register
Login
Home
