Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » GEF » is JFace TreeViewer is identical to GEF one?
is JFace TreeViewer is identical to GEF one? [message #134868] Sat, 29 May 2004 17:47 Go to next message
Eclipse UserFriend
Originally posted by: absolutntn.netscape.com

In all GEF examples i've seen they use a GraphicalEditor, saying
TreeViewer is similar to JFace's one. can i "safely" use JFace examples?

thanks in advance
Re: is JFace TreeViewer is identical to GEF one? [message #134897 is a reply to message #134868] Sat, 29 May 2004 18:12 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: rlemaigr.ulb.ac.be

Hello,

I'm not sure I have properly understood your question (perhaps my quite =
=

bad english is the culprit here) but I will say here to you what I know =
=

about tree viewers and their usage in gef.

JFace tree viewers are general purpose viewers to display a tree =

structure, whatever the type of the objects to dispay is. You have to =

write a ContentProvider and a LabelProvider to tell the viewer about wha=
t =

it has to display (what are the children of a given object), and how (wh=
at =

are the icon and label to use for displaying an object). I think you can=
=

find examples of that on the net. It is quite simple to do, but as far a=
s =

I know, they are no editing possibilities of your model through the tree=
=

with that method (perhaps it is possible to add editing possibilities, b=
ut =

I don't know how to do it and by default it is just a viewer I think).

Gef tree viewers are EditPartViewers and thus they are built like the =

GraphicalViewer where your diagram is displayed. So, to display a tree o=
f =

your model by using such a tree viewer, you have to rewrite all your =

EditParts by extending the class AbstractTreeEditPart (I think) rather =

than AbstractGraphicalEditPart. That needs more work than the first =

method. But the benefit is that you can use the tree viewer for editing =
=

the model the same way you use your graphical viewer for it (drag & drop=
=

children between parent containers...). And maybe you can re-use there a=
ll =

your Command classes, and EditPolicies classes. And the changes you do t=
o =

your model through the tree viewer are in the command stack too.


You want probably to build an outline page ?

I think the easiest way for doing this is the first method, with a JFace=
=

viewer. The easiest way for building an outline page with a JFace tree =

viewer is by extending =

org.eclipse.ui.views.contentoutline.ContentOutlinePage. The default =

implementation of this type of outline page uses a TreeViewer.

So you extend this class and you overrides the createControl methode lik=
e =

that

public MyOutlinePage extends ContentOutlinePage
{
...
public void createControl(Composite parent)
{
super.createControl(parent);
=

TreeViewer treeViewer =3D getTreeViewer();
treeViewer.setContentProvider(new YourTreeContentProvider());
treeViewer.setLabelProvider(new YourLabelProvider());
treeViewer.setInput(input);//input is the root of the tree structure yo=
u =

want to display
}
...
}

and in your Editor class, you overrides getAdapter like that:

public Object getAdapter(Class aClass)
{
if (aClass =3D=3D IContentOutlinePage.class)
return new MyOutlinePage();
return super.getAdapter(aClass);
}

You can still wonder about the "input" of the tree. I think the best is =
to =

use the content EditPart of the Graphical Viewer as the input of the tre=
e =

viewer, and to use the method EditPart.getChildren() in the =

TreeContentProvider. That way, the EditParts are displayed in the tree, =
=

not the model objects, and that is useful because when you select =

something in the tree, it will be an EditPart, just like when you select=
=

something in the diagram. If your plugin makes use of SelectionActions, =
=

PropertySheets and thing that depends on the current selection in the =

workbench, this will help.

I hope I have helped you and keep in mind that all I say can contain =

mistakes as I am not a very experimented eclipse developper,

r=E9gis

On Sat, 29 May 2004 19:47:44 +0200, absolut666 <absolutntn@netscape.com>=
=

wrote:

> In all GEF examples i've seen they use a GraphicalEditor, saying =

> TreeViewer is similar to JFace's one. can i "safely" use JFace example=
s?
>
> thanks in advance
Re: is JFace TreeViewer is identical to GEF one? [message #134910 is a reply to message #134897] Sat, 29 May 2004 19:40 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: absolutntn.netscape.com

thanks a bunch!!!

it was great and VERY useful answer. people like you make the opensource
community as useful as it is))))

i'll go and try all this stuff out now
natan

rlemaigr@ulb.ac.be wrote:
> Hello,
>
> I'm not sure I have properly understood your question (perhaps my quite
> bad english is the culprit here) but I will say here to you what I know
> about tree viewers and their usage in gef.
>
> JFace tree viewers are general purpose viewers to display a tree
> structure, whatever the type of the objects to dispay is. You have to
> write a ContentProvider and a LabelProvider to tell the viewer about
> what it has to display (what are the children of a given object), and
> how (what are the icon and label to use for displaying an object). I
> think you can find examples of that on the net. It is quite simple to
> do, but as far as I know, they are no editing possibilities of your
> model through the tree with that method (perhaps it is possible to add
> editing possibilities, but I don't know how to do it and by default it
> is just a viewer I think).
>
> Gef tree viewers are EditPartViewers and thus they are built like the
> GraphicalViewer where your diagram is displayed. So, to display a tree
> of your model by using such a tree viewer, you have to rewrite all
> your EditParts by extending the class AbstractTreeEditPart (I think)
> rather than AbstractGraphicalEditPart. That needs more work than the
> first method. But the benefit is that you can use the tree viewer for
> editing the model the same way you use your graphical viewer for it
> (drag & drop children between parent containers...). And maybe you can
> re-use there all your Command classes, and EditPolicies classes. And
> the changes you do to your model through the tree viewer are in the
> command stack too.
>
>
> You want probably to build an outline page ?
>
> I think the easiest way for doing this is the first method, with a
> JFace viewer. The easiest way for building an outline page with a JFace
> tree viewer is by extending
> org.eclipse.ui.views.contentoutline.ContentOutlinePage. The default
> implementation of this type of outline page uses a TreeViewer.
>
> So you extend this class and you overrides the createControl methode
> like that
>
> public MyOutlinePage extends ContentOutlinePage
> {
> ..
> public void createControl(Composite parent)
> {
> super.createControl(parent);
>
> TreeViewer treeViewer = getTreeViewer();
> treeViewer.setContentProvider(new YourTreeContentProvider());
> treeViewer.setLabelProvider(new YourLabelProvider());
> treeViewer.setInput(input);//input is the root of the tree structure
> you want to display
> }
> ..
> }
>
> and in your Editor class, you overrides getAdapter like that:
>
> public Object getAdapter(Class aClass)
> {
> if (aClass == IContentOutlinePage.class)
> return new MyOutlinePage();
> return super.getAdapter(aClass);
> }
>
> You can still wonder about the "input" of the tree. I think the best is
> to use the content EditPart of the Graphical Viewer as the input of the
> tree viewer, and to use the method EditPart.getChildren() in the
> TreeContentProvider. That way, the EditParts are displayed in the tree,
> not the model objects, and that is useful because when you select
> something in the tree, it will be an EditPart, just like when you
> select something in the diagram. If your plugin makes use of
> SelectionActions, PropertySheets and thing that depends on the current
> selection in the workbench, this will help.
>
> I hope I have helped you and keep in mind that all I say can contain
> mistakes as I am not a very experimented eclipse developper,
>
> régis
>
> On Sat, 29 May 2004 19:47:44 +0200, absolut666
> <absolutntn@netscape.com> wrote:
>
>> In all GEF examples i've seen they use a GraphicalEditor, saying
>> TreeViewer is similar to JFace's one. can i "safely" use JFace examples?
>>
>> thanks in advance
>
>
Re: is JFace TreeViewer is identical to GEF one? [message #134923 is a reply to message #134910] Sat, 29 May 2004 20:14 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: rlemaigr.ulb.ac.be

ok !

By reading my previous message I've realize that I kept some things =

unsaid, like how to make your tree reflect the changes is your model.

With a GEF tree viewer, if your TreeEditParts listen to your model and i=
f =

you call properly the refreshChildren and refreshVisuals methods when th=
e =

model changes, the changes in your model should be automaticaly reflecte=
d =

on the tree.

But with a JFace viewer, you have to implement this by yourself. I usual=
ly =

add a CommandStackListener to the CommandStack, and when the command sta=
ck =

fires an event, I refresh the tree by calling TreeViewer.refresh(). But =
=

the tree is completely refreshed each time a command is executed so this=
=

is not a efficient way to do this.

I'm still searching for a better way to do this so if somebody knows, =

please tell me...

If you have problems implementing this post them here.

r=E9gis

On Sat, 29 May 2004 21:40:18 +0200, absolut666 <absolutntn@netscape.com>=
=

wrote:

> thanks a bunch!!!
>
> it was great and VERY useful answer. people like you make the opensour=
ce =

> community as useful as it is))))
>
> i'll go and try all this stuff out now
> natan
>
> rlemaigr@ulb.ac.be wrote:
>> Hello,
>> I'm not sure I have properly understood your question (perhaps my =

>> quite bad english is the culprit here) but I will say here to you wh=
at =

>> I know about tree viewers and their usage in gef.
>> JFace tree viewers are general purpose viewers to display a tree =

>> structure, whatever the type of the objects to dispay is. You have to=
=

>> write a ContentProvider and a LabelProvider to tell the viewer about =
=

>> what it has to display (what are the children of a given object), an=
d =

>> how (what are the icon and label to use for displaying an object). I=
=

>> think you can find examples of that on the net. It is quite simple t=
o =

>> do, but as far as I know, they are no editing possibilities of your =
=

>> model through the tree with that method (perhaps it is possible to a=
dd =

>> editing possibilities, but I don't know how to do it and by default =
it =

>> is just a viewer I think).
>> Gef tree viewers are EditPartViewers and thus they are built like th=
e =

>> GraphicalViewer where your diagram is displayed. So, to display a tre=
e =

>> of your model by using such a tree viewer, you have to rewrite all =

>> your EditParts by extending the class AbstractTreeEditPart (I think)=
=

>> rather than AbstractGraphicalEditPart. That needs more work than the=
=

>> first method. But the benefit is that you can use the tree viewer fo=
r =

>> editing the model the same way you use your graphical viewer for it =
=

>> (drag & drop children between parent containers...). And maybe you c=
an =

>> re-use there all your Command classes, and EditPolicies classes. And=
=

>> the changes you do to your model through the tree viewer are in the =
=

>> command stack too.
>> You want probably to build an outline page ?
>> I think the easiest way for doing this is the first method, with a =

>> JFace viewer. The easiest way for building an outline page with a =

>> JFace tree viewer is by extending =

>> org.eclipse.ui.views.contentoutline.ContentOutlinePage. The default =
=

>> implementation of this type of outline page uses a TreeViewer.
>> So you extend this class and you overrides the createControl methode=
=

>> like that
>> public MyOutlinePage extends ContentOutlinePage
>> {
>> ..
>> public void createControl(Composite parent)
>> {
>> super.createControl(parent);
>> TreeViewer treeViewer =3D getTreeViewer();
>> treeViewer.setContentProvider(new YourTreeContentProvider());
>> treeViewer.setLabelProvider(new YourLabelProvider());
>> treeViewer.setInput(input);//input is the root of the tree =

>> structure you want to display
>> }
>> ..
>> }
>> and in your Editor class, you overrides getAdapter like that:
>> public Object getAdapter(Class aClass)
>> {
>> if (aClass =3D=3D IContentOutlinePage.class)
>> return new MyOutlinePage();
>> return super.getAdapter(aClass);
>> }
>> You can still wonder about the "input" of the tree. I think the best=
=

>> is to use the content EditPart of the Graphical Viewer as the input =
of =

>> the tree viewer, and to use the method EditPart.getChildren() in the=
=

>> TreeContentProvider. That way, the EditParts are displayed in the =

>> tree, not the model objects, and that is useful because when you =

>> select something in the tree, it will be an EditPart, just like when=
=

>> you select something in the diagram. If your plugin makes use of =

>> SelectionActions, PropertySheets and thing that depends on the curre=
nt =

>> selection in the workbench, this will help.
>> I hope I have helped you and keep in mind that all I say can contain=
=

>> mistakes as I am not a very experimented eclipse developper,
>> r=E9gis
>> On Sat, 29 May 2004 19:47:44 +0200, absolut666 =

>> <absolutntn@netscape.com> wrote:
>>
>>> In all GEF examples i've seen they use a GraphicalEditor, saying =

>>> TreeViewer is similar to JFace's one. can i "safely" use JFace =

>>> examples?
>>>
>>> thanks in advance
>>
>



-- =

Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
Re: is JFace TreeViewer is identical to GEF one? [message #135003 is a reply to message #134923] Sun, 30 May 2004 15:45 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: none.us.ibm.com

This is one of the hidden aspects of JFace. Your contentprovider is given
the tree, and it is also disposed(). Why would dispose() be necessary?
Because this is how you do efficient updates. So, your provider must hold
onto the treeviewer, and when the model changes, there is public API on
treeviewer which can do more granular updates. JFace are a little
fragmented, and also not fragmented. For example, your label provider must
also listen to the exact same model events and ask for updates too, and
maybe the same for any filters you may be using. At the same time, each
provider has to know about every type of model element.

EditParts on the otherhand are a mini content+label provider for a single
item in the tree. With the added benefit of supporting editing.

<rlemaigr@ulb.ac.be> wrote in message
news:opr8r2i4fxxn9g2u@xn--pcrgis-dva.mshome.net...
ok !

By reading my previous message I've realize that I kept some things
unsaid, like how to make your tree reflect the changes is your model.

With a GEF tree viewer, if your TreeEditParts listen to your model and if
you call properly the refreshChildren and refreshVisuals methods when the
model changes, the changes in your model should be automaticaly reflected
on the tree.

But with a JFace viewer, you have to implement this by yourself. I usually
add a CommandStackListener to the CommandStack, and when the command stack
fires an event, I refresh the tree by calling TreeViewer.refresh(). But
the tree is completely refreshed each time a command is executed so this
is not a efficient way to do this.

I'm still searching for a better way to do this so if somebody knows,
please tell me...

If you have problems implementing this post them here.

r
Re: is JFace TreeViewer is identical to GEF one? [message #135029 is a reply to message #135003] Sun, 30 May 2004 17:46 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: rlemaigr.ulb.ac.be

Ok I think I understand better now.

The model must not know anything about the treeviewer so he can't trigge=
rs =

updates of the tree itself, and the treeviewer must not know nothing abo=
ut =

the model so he can't query the model for updates. So just like EditPart=
s =

make a link between a model object and its Figure, the providers make a =
=

link between the all model and the all tree. They listen to the model an=
d =

when the model changes, they call the public API on the treeviewer to =

trigger updates and query the model to give the treeviewers informations=
=

about updates. Ok.

But what I still don't understand is that:

Suppose I have a model with each object firing its own events about its =
=

changes.
The problem is:
My content provider (and the other providers too if I follow you well) h=
as =

to listen to ALL the object of the model, registering himself as a listn=
er =

when a new object appear in the model, unregistering itself when an obje=
ct =

is removed from the model, etc...This seems very very complicated to do.=
=

Suppose an object is removed from the model, how can I unregister the =

provider from the list of listeners of that object ?
That's why I usually put a listener on the command stack which triggers =
=

updates of the tree. Maybe very inefficient, but very simple...

Could you please explain a better way to solve this problem ?

Thank you for your answer,

r=E9gis

On Sun, 30 May 2004 11:45:06 -0400, Randy Hudson <none@us.ibm.com> wrote=
:

> This is one of the hidden aspects of JFace. Your contentprovider is =

> given
> the tree, and it is also disposed(). Why would dispose() be necessary=
?
> Because this is how you do efficient updates. So, your provider must =
=

> hold
> onto the treeviewer, and when the model changes, there is public API o=
n
> treeviewer which can do more granular updates. JFace are a little
> fragmented, and also not fragmented. For example, your label provider=
=

> must
> also listen to the exact same model events and ask for updates too, an=
d
> maybe the same for any filters you may be using. At the same time, ea=
ch
> provider has to know about every type of model element.
>
> EditParts on the otherhand are a mini content+label provider for a sin=
gle
> item in the tree. With the added benefit of supporting editing.
>
> <rlemaigr@ulb.ac.be> wrote in message
> news:opr8r2i4fxxn9g2u@xn--pcrgis-dva.mshome.net...
> ok !
>
> By reading my previous message I've realize that I kept some things
> unsaid, like how to make your tree reflect the changes is your model.
>
> With a GEF tree viewer, if your TreeEditParts listen to your model and=
if
> you call properly the refreshChildren and refreshVisuals methods when =
the
> model changes, the changes in your model should be automaticaly reflec=
ted
> on the tree.
>
> But with a JFace viewer, you have to implement this by yourself. I =

> usually
> add a CommandStackListener to the CommandStack, and when the command =

> stack
> fires an event, I refresh the tree by calling TreeViewer.refresh(). Bu=
t
> the tree is completely refreshed each time a command is executed so th=
is
> is not a efficient way to do this.
>
> I'm still searching for a better way to do this so if somebody knows,
> please tell me...
>
> If you have problems implementing this post them here.
>
> r=E9gis
>
> On Sat, 29 May 2004 21:40:18 +0200, absolut666 <absolutntn@netscape.co=
m>
> wrote:
>
>> thanks a bunch!!!
>>
>> it was great and VERY useful answer. people like you make the opensou=
rce
>> community as useful as it is))))
>>
>> i'll go and try all this stuff out now
>> natan
>>
>> rlemaigr@ulb.ac.be wrote:
>>> Hello,
>>> I'm not sure I have properly understood your question (perhaps my
>>> quite bad english is the culprit here) but I will say here to you w=
hat
>>> I know about tree viewers and their usage in gef.
>>> JFace tree viewers are general purpose viewers to display a tree
>>> structure, whatever the type of the objects to dispay is. You have t=
o
>>> write a ContentProvider and a LabelProvider to tell the viewer about=

>>> what it has to display (what are the children of a given object), a=
nd
>>> how (what are the icon and label to use for displaying an object). =
I
>>> think you can find examples of that on the net. It is quite simple =
to
>>> do, but as far as I know, they are no editing possibilities of your=

>>> model through the tree with that method (perhaps it is possible to =
add
>>> editing possibilities, but I don't know how to do it and by default=
it
>>> is just a viewer I think).
>>> Gef tree viewers are EditPartViewers and thus they are built like t=
he
>>> GraphicalViewer where your diagram is displayed. So, to display a tr=
ee
>>> of your model by using such a tree viewer, you have to rewrite all
>>> your EditParts by extending the class AbstractTreeEditPart (I think=
)
>>> rather than AbstractGraphicalEditPart. That needs more work than th=
e
>>> first method. But the benefit is that you can use the tree viewer f=
or
>>> editing the model the same way you use your graphical viewer for it=

>>> (drag & drop children between parent containers...). And maybe you =
can
>>> re-use there all your Command classes, and EditPolicies classes. An=
d
>>> the changes you do to your model through the tree viewer are in the=

>>> command stack too.
>>> You want probably to build an outline page ?
>>> I think the easiest way for doing this is the first method, with a
>>> JFace viewer. The easiest way for building an outline page with a
>>> JFace tree viewer is by extending
>>> org.eclipse.ui.views.contentoutline.ContentOutlinePage. The default
>>> implementation of this type of outline page uses a TreeViewer.
>>> So you extend this class and you overrides the createControl method=
e
>>> like that
>>> public MyOutlinePage extends ContentOutlinePage
>>> {
>>> ..
>>> public void createControl(Composite parent)
>>> {
>>> super.createControl(parent);
>>> TreeViewer treeViewer =3D getTreeViewer();
>>> treeViewer.setContentProvider(new YourTreeContentProvider());
>>> treeViewer.setLabelProvider(new YourLabelProvider());
>>> treeViewer.setInput(input);//input is the root of the tree
>>> structure you want to display
>>> }
>>> ..
>>> }
>>> and in your Editor class, you overrides getAdapter like that:
>>> public Object getAdapter(Class aClass)
>>> {
>>> if (aClass =3D=3D IContentOutlinePage.class)
>>> return new MyOutlinePage();
>>> return super.getAdapter(aClass);
>>> }
>>> You can still wonder about the "input" of the tree. I think the bes=
t
>>> is to use the content EditPart of the Graphical Viewer as the input=
of
>>> the tree viewer, and to use the method EditPart.getChildren() in th=
e
>>> TreeContentProvider. That way, the EditParts are displayed in the
>>> tree, not the model objects, and that is useful because when you
>>> select something in the tree, it will be an EditPart, just like whe=
n
>>> you select something in the diagram. If your plugin makes use of
>>> SelectionActions, PropertySheets and thing that depends on the curr=
ent
>>> selection in the workbench, this will help.
>>> I hope I have helped you and keep in mind that all I say can contai=
n
>>> mistakes as I am not a very experimented eclipse developper,
>>> r=E9gis
>>> On Sat, 29 May 2004 19:47:44 +0200, absolut666
>>> <absolutntn@netscape.com> wrote:
>>>
>>>> In all GEF examples i've seen they use a GraphicalEditor, saying
>>>> TreeViewer is similar to JFace's one. can i "safely" use JFace
>>>> examples?
>>>>
>>>> thanks in advance
>>>
>>
>
>
>



-- =

Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
Re: is JFace TreeViewer is identical to GEF one? [message #135042 is a reply to message #135029] Sun, 30 May 2004 18:16 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: rlemaigr.ulb.ac.be

Ok maybe I've found the answer to my own question.

When an object is removed/added from the model, the "parent" object in t=
he =

model will fire an event indicating which object has been removed/added.=
=

So the provider which recieves that event can unregister/register itself=
=

as a listener for that object.

But if a parent object in the model fires events like =

"PROPERTY_LIST_CHILDREN_CHANGED", without describing in the Event what =

exactely has been changed in the list of children , the provider can't =

know what has been changed ! So, it can't register/unregister itself as =
a =

listners for the objects added/removed in the model. This is a realistic=
=

situation because for efficiency purposes, it could be better to fire =

"global events" like that instead of individual event for each child =

added/removed.

That's the problem I crossed the other time and it made me choose the =

command stack listener solution. For the EditParts, this is not a proble=
m =

because they can compare the return of getModelChildren() with the model=
s =

of their children, and thus EditParts can know what has been changed and=
=

deactivate the EditParts (and unregister them as listeners of their mode=
l) =

that are no longer needed. But the provider can't do that because unlike=
=

the EditParts, it doesn't keep for each parent object a list of its =

"previously known" children for which it is registered as a listener !

Do you understand what I mean ?

I think solving this problem could become very complicated...

r=E9gis

On Sun, 30 May 2004 19:46:09 +0200, <rlemaigr@ulb.ac.be> wrote:

> Ok I think I understand better now.
>
> The model must not know anything about the treeviewer so he can't =

> triggers updates of the tree itself, and the treeviewer must not know =
=

> nothing about the model so he can't query the model for updates. So ju=
st =

> like EditParts make a link between a model object and its Figure, the =
=

> providers make a link between the all model and the all tree. They =

> listen to the model and when the model changes, they call the public A=
PI =

> on the treeviewer to trigger updates and query the model to give the =

> treeviewers informations about updates. Ok.
>
> But what I still don't understand is that:
>
> Suppose I have a model with each object firing its own events about it=
s =

> changes.
> The problem is:
> My content provider (and the other providers too if I follow you well)=
=

> has to listen to ALL the object of the model, registering himself as a=
=

> listner when a new object appear in the model, unregistering itself wh=
en =

> an object is removed from the model, etc...This seems very very =

> complicated to do. Suppose an object is removed from the model, how ca=
n =

> I unregister the provider from the list of listeners of that object ?
> That's why I usually put a listener on the command stack which trigger=
s =

> updates of the tree. Maybe very inefficient, but very simple...
>
> Could you please explain a better way to solve this problem ?
>
> Thank you for your answer,
>
> r=E9gis
>
> On Sun, 30 May 2004 11:45:06 -0400, Randy Hudson <none@us.ibm.com> wro=
te:
>
>> This is one of the hidden aspects of JFace. Your contentprovider is =
=

>> given
>> the tree, and it is also disposed(). Why would dispose() be necessar=
y?
>> Because this is how you do efficient updates. So, your provider must=
=

>> hold
>> onto the treeviewer, and when the model changes, there is public API =
on
>> treeviewer which can do more granular updates. JFace are a little
>> fragmented, and also not fragmented. For example, your label provide=
r =

>> must
>> also listen to the exact same model events and ask for updates too, a=
nd
>> maybe the same for any filters you may be using. At the same time, e=
ach
>> provider has to know about every type of model element.
>>
>> EditParts on the otherhand are a mini content+label provider for a =

>> single
>> item in the tree. With the added benefit of supporting editing.
>>
>> <rlemaigr@ulb.ac.be> wrote in message
>> news:opr8r2i4fxxn9g2u@xn--pcrgis-dva.mshome.net...
>> ok !
>>
>> By reading my previous message I've realize that I kept some things
>> unsaid, like how to make your tree reflect the changes is your model.=

>>
>> With a GEF tree viewer, if your TreeEditParts listen to your model an=
d =

>> if
>> you call properly the refreshChildren and refreshVisuals methods when=
=

>> the
>> model changes, the changes in your model should be automaticaly =

>> reflected
>> on the tree.
>>
>> But with a JFace viewer, you have to implement this by yourself. I =

>> usually
>> add a CommandStackListener to the CommandStack, and when the command =
=

>> stack
>> fires an event, I refresh the tree by calling TreeViewer.refresh(). B=
ut
>> the tree is completely refreshed each time a command is executed so t=
his
>> is not a efficient way to do this.
>>
>> I'm still searching for a better way to do this so if somebody knows,=

>> please tell me...
>>
>> If you have problems implementing this post them here.
>>
>> r=E9gis
>>
>> On Sat, 29 May 2004 21:40:18 +0200, absolut666 <absolutntn@netscape.c=
om>
>> wrote:
>>
>>> thanks a bunch!!!
>>>
>>> it was great and VERY useful answer. people like you make the =

>>> opensource
>>> community as useful as it is))))
>>>
>>> i'll go and try all this stuff out now
>>> natan
>>>
>>> rlemaigr@ulb.ac.be wrote:
>>>> Hello,
>>>> I'm not sure I have properly understood your question (perhaps my
>>>> quite bad english is the culprit here) but I will say here to you =
=

>>>> what
>>>> I know about tree viewers and their usage in gef.
>>>> JFace tree viewers are general purpose viewers to display a tree
>>>> structure, whatever the type of the objects to dispay is. You have =
to
>>>> write a ContentProvider and a LabelProvider to tell the viewer abou=
t
>>>> what it has to display (what are the children of a given object), =
and
>>>> how (what are the icon and label to use for displaying an object).=
I
>>>> think you can find examples of that on the net. It is quite simple=
to
>>>> do, but as far as I know, they are no editing possibilities of you=
r
>>>> model through the tree with that method (perhaps it is possible to=
=

>>>> add
>>>> editing possibilities, but I don't know how to do it and by defaul=
t =

>>>> it
>>>> is just a viewer I think).
>>>> Gef tree viewers are EditPartViewers and thus they are built like =
the
>>>> GraphicalViewer where your diagram is displayed. So, to display a t=
ree
>>>> of your model by using such a tree viewer, you have to rewrite all=

>>>> your EditParts by extending the class AbstractTreeEditPart (I thin=
k)
>>>> rather than AbstractGraphicalEditPart. That needs more work than t=
he
>>>> first method. But the benefit is that you can use the tree viewer =
for
>>>> editing the model the same way you use your graphical viewer for i=
t
>>>> (drag & drop children between parent containers...). And maybe you=
=

>>>> can
>>>> re-use there all your Command classes, and EditPolicies classes. A=
nd
>>>> the changes you do to your model through the tree viewer are in th=
e
>>>> command stack too.
>>>> You want probably to build an outline page ?
>>>> I think the easiest way for doing this is the first method, with a=

>>>> JFace viewer. The easiest way for building an outline page with a
>>>> JFace tree viewer is by extending
>>>> org.eclipse.ui.views.contentoutline.ContentOutlinePage. The default=

>>>> implementation of this type of outline page uses a TreeViewer.
>>>> So you extend this class and you overrides the createControl metho=
de
>>>> like that
>>>> public MyOutlinePage extends ContentOutlinePage
>>>> {
>>>> ..
>>>> public void createControl(Composite parent)
>>>> {
>>>> super.createControl(parent);
>>>> TreeViewer treeViewer =3D getTreeViewer();
>>>> treeViewer.setContentProvider(new YourTreeContentProvider());
>>>> treeViewer.setLabelProvider(new YourLabelProvider());
>>>> treeViewer.setInput(input);//input is the root of the tree
>>>> structure you want to display
>>>> }
>>>> ..
>>>> }
>>>> and in your Editor class, you overrides getAdapter like that:
>>>> public Object getAdapter(Class aClass)
>>>> {
>>>> if (aClass =3D=3D IContentOutlinePage.class)
>>>> return new MyOutlinePage();
>>>> return super.getAdapter(aClass);
>>>> }
>>>> You can still wonder about the "input" of the tree. I think the be=
st
>>>> is to use the content EditPart of the Graphical Viewer as the inpu=
t =

>>>> of
>>>> the tree viewer, and to use the method EditPart.getChildren() in t=
he
>>>> TreeContentProvider. That way, the EditParts are displayed in the
>>>> tree, not the model objects, and that is useful because when you
>>>> select something in the tree, it will be an EditPart, just like wh=
en
>>>> you select something in the diagram. If your plugin makes use of
>>>> SelectionActions, PropertySheets and thing that depends on the =

>>>> current
>>>> selection in the workbench, this will help.
>>>> I hope I have helped you and keep in mind that all I say can conta=
in
>>>> mistakes as I am not a very experimented eclipse developper,
>>>> r=E9gis
>>>> On Sat, 29 May 2004 19:47:44 +0200, absolut666
>>>> <absolutntn@netscape.com> wrote:
>>>>
>>>>> In all GEF examples i've seen they use a GraphicalEditor, saying
>>>>> TreeViewer is similar to JFace's one. can i "safely" use JFace
>>>>> examples?
>>>>>
>>>>> thanks in advance
>>>>
>>>
>>
>>
>>
>
>
>



-- =

Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
Re: is JFace TreeViewer is identical to GEF one? [message #135207 is a reply to message #135029] Tue, 01 June 2004 00:51 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: none.us.ibm.com

> Suppose I have a model with each object firing its own events about its
changes.
> The problem is:
My content provider (and the other providers too if I follow you well) has
to listen to ALL the object of the model, registering himself as a listner
when a new object appear in the model, unregistering itself when an object
is removed from the model, etc...This seems very very complicated to do.
Suppose an object is removed from the model, how can I unregister the
provider from the list of listeners of that object ?
That's why I usually put a listener on the command stack which triggers
updates of the tree. Maybe very inefficient, but very simple...

Could you please explain a better way to solve this problem ?

Yes, this is the worst part of content providers, and it's why adapter
layers like EMF Edit exist. The authors of JFace didn't know about models
with multiple notifiers ;-). But seriously, they are more familiar with a
model which has a single "domain" notifier. I'm pretty sure this is what
you find in the Eclipse resource and JDT models. And in their defense, such
models require less hooking and unhooking of listeners, so memory leaks are
less common.

But, for your type of model you end up with a big N->1 mapping of notifiers
to the single contentprovider. Plus, you need to listen to some properties
just for the purpose of adding and removing listeners. I was working with a
model recently where I had to hook 4 different listeners per treeitem. Not
much fun at all.

On Sun, 30 May 2004 11:45:06 -0400, Randy Hudson <none@us.ibm.com> wrote:

> This is one of the hidden aspects of JFace. Your contentprovider is
> given
> the tree, and it is also disposed(). Why would dispose() be necessary?
> Because this is how you do efficient updates. So, your provider must
> hold
> onto the treeviewer, and when the model changes, there is public API on
> treeviewer which can do more granular updates. JFace are a little
> fragmented, and also not fragmented. For example, your label provider
> must
> also listen to the exact same model events and ask for updates too, and
> maybe the same for any filters you may be using. At the same time, each
> provider has to know about every type of model element.
>
> EditParts on the otherhand are a mini content+label provider for a single
> item in the tree. With the added benefit of supporting editing.
>
> <rlemaigr@ulb.ac.be> wrote in message
> news:opr8r2i4fxxn9g2u@xn--pcrgis-dva.mshome.net...
> ok !
>
> By reading my previous message I've realize that I kept some things
> unsaid, like how to make your tree reflect the changes is your model.
>
> With a GEF tree viewer, if your TreeEditParts listen to your model and if
> you call properly the refreshChildren and refreshVisuals methods when the
> model changes, the changes in your model should be automaticaly reflected
> on the tree.
>
> But with a JFace viewer, you have to implement this by yourself. I
> usually
> add a CommandStackListener to the CommandStack, and when the command
> stack
> fires an event, I refresh the tree by calling TreeViewer.refresh(). But
> the tree is completely refreshed each time a command is executed so this
> is not a efficient way to do this.
>
> I'm still searching for a better way to do this so if somebody knows,
> please tell me...
>
> If you have problems implementing this post them here.
>
> r
Re: is JFace TreeViewer is identical to GEF one? [message #135321 is a reply to message #135207] Tue, 01 June 2004 11:20 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: rlemaigr.ulb.ac.be

Thanks a lot for your answers. I understand the all thing much better no=
w.

At the beginning, I was thinking that the JFace solution for building an=
=

outline view was much simpler than the GEF solution and so if no editing=
=

capabilities are needed, it was the one to choose. But with all this =

discussion I think now I will learn how to build such an tree with GEF =

also...it seems that there are only advantages to that...

But I think the problem of hooking/unhooking the provider from the model=
=

objects can be simplified, because I think the provider doesn't have to =
=

unhook itself from the model objects. If a model object is removed from =
=

the model, it will no longer be modified, so it will no longer fire any =
=

events to the provider and so it is useless to unhook the provider in th=
at =

case.
That is a simplification because unhooking the provider from the removed=
=

objects can be hard or impossible to do because maybe we don't know =

exactly which objects has been removed...

Thank you for your help,

r=E9gis


> Yes, this is the worst part of content providers, and it's why adapter=

> layers like EMF Edit exist. The authors of JFace didn't know about =

> models
> with multiple notifiers ;-). But seriously, they are more familiar wi=
th =

> a
> model which has a single "domain" notifier. I'm pretty sure this is w=
hat
> you find in the Eclipse resource and JDT models. And in their defense=
, =

> such
> models require less hooking and unhooking of listeners, so memory leak=
s =

> are
> less common.
>
> But, for your type of model you end up with a big N->1 mapping of =

> notifiers
> to the single contentprovider. Plus, you need to listen to some =

> properties
> just for the purpose of adding and removing listeners. I was working =
=

> with a
> model recently where I had to hook 4 different listeners per treeitem.=
=

> Not
> much fun at all.
Re: is JFace TreeViewer is identical to GEF one? [message #135396 is a reply to message #135321] Tue, 01 June 2004 18:45 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: none.us.ibm.com

What about undo/redo? The old model is being held onto by the command
stack. What about closing and re-opening the outline view?

<rlemaigr@ulb.ac.be> wrote in message
news:opr8wxsuxpxn9g2u@xn--pcrgis-dva.mshome.net...
Thanks a lot for your answers. I understand the all thing much better now.

At the beginning, I was thinking that the JFace solution for building an
outline view was much simpler than the GEF solution and so if no editing
capabilities are needed, it was the one to choose. But with all this
discussion I think now I will learn how to build such an tree with GEF
also...it seems that there are only advantages to that...

But I think the problem of hooking/unhooking the provider from the model
objects can be simplified, because I think the provider doesn't have to
unhook itself from the model objects. If a model object is removed from
the model, it will no longer be modified, so it will no longer fire any
events to the provider and so it is useless to unhook the provider in that
case.
That is a simplification because unhooking the provider from the removed
objects can be hard or impossible to do because maybe we don't know
exactly which objects has been removed...

Thank you for your help,

r
Re: is JFace TreeViewer is identical to GEF one? [message #135495 is a reply to message #135396] Wed, 02 June 2004 00:17 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: rlemaigr.ulb.ac.be

By "What about undo/redo?", do you mean: if I remove an object from the =
=

model without unhooking the provider, and then if the undo occurs and th=
e =

object is back in the model, I will hook the provider a second time on i=
t =

? And if I repeat the process 10 times, the provider will hook itself 10=
=

times to the same model object without never unhooking itself so it will=
=

recieve 10 times the same events from that object?

Maybe it is not really a problem because I think PropertyChangeSupport =

(let's say it is used here) doesn't allow an object to be inculded at th=
e =

same time more than once in a list of listeners, so the provider can hoo=
k =

itself a lot of times, that will not have any bad effect on performance,=
=

am I wrong (again :D ) ? Or you're talking about another problem with =

undo/redo ?


About closing/reopening the outline view...I didn't think about that...i=
n =

fact I just don't know anything about what happen in that case...I am =

still very dumb about all the Eclipse things and swt...but I trust you :=
D !

This discussion is not really gef-related so you don't have to take your=
=

time to answer all this. I will search by myself.

Thank you for your help and your informations,

r=E9gis

On Tue, 1 Jun 2004 14:45:06 -0400, Randy Hudson <none@us.ibm.com> wrote:=


> What about undo/redo? The old model is being held onto by the command=

> stack. What about closing and re-opening the outline view?



> <rlemaigr@ulb.ac.be> wrote in message
> news:opr8wxsuxpxn9g2u@xn--pcrgis-dva.mshome.net...
> Thanks a lot for your answers. I understand the all thing much better =
=

> now.
>
> At the beginning, I was thinking that the JFace solution for building =
an
> outline view was much simpler than the GEF solution and so if no editi=
ng
> capabilities are needed, it was the one to choose. But with all this
> discussion I think now I will learn how to build such an tree with GEF=

> also...it seems that there are only advantages to that...
>
> But I think the problem of hooking/unhooking the provider from the mod=
el
> objects can be simplified, because I think the provider doesn't have t=
o
> unhook itself from the model objects. If a model object is removed fro=
m
> the model, it will no longer be modified, so it will no longer fire an=
y
> events to the provider and so it is useless to unhook the provider in =
=

> that
> case.
> That is a simplification because unhooking the provider from the remov=
ed
> objects can be hard or impossible to do because maybe we don't know
> exactly which objects has been removed...
>
> Thank you for your help,
>
> r=E9gis
>
>
>> Yes, this is the worst part of content providers, and it's why adapte=
r
>> layers like EMF Edit exist. The authors of JFace didn't know about
>> models
>> with multiple notifiers ;-). But seriously, they are more familiar w=
ith
>> a
>> model which has a single "domain" notifier. I'm pretty sure this is =
=

>> what
>> you find in the Eclipse resource and JDT models. And in their defens=
e,
>> such
>> models require less hooking and unhooking of listeners, so memory lea=
ks
>> are
>> less common.
>>
>> But, for your type of model you end up with a big N->1 mapping of
>> notifiers
>> to the single contentprovider. Plus, you need to listen to some
>> properties
>> just for the purpose of adding and removing listeners. I was working=

>> with a
>> model recently where I had to hook 4 different listeners per treeitem=
..
>> Not
>> much fun at all.
>
>



-- =

Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
Re: is JFace TreeViewer is identical to GEF one? [message #135532 is a reply to message #135495] Wed, 02 June 2004 03:09 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: none.us.ibm.com

> Maybe it is not really a problem because I think PropertyChangeSupport
> (let's say it is used here) doesn't allow an object to be inculded at the
> same time more than once in a list of listeners, so the provider can hook

I wouldn't want to rely on this type of behavior. In fact, I think you have
it backwards. JFace ListenerList only allows single entries, but every
other notifying mechanism I've ever seen allows multiple entries. I think
this is more correct. If you call add twice and remove once, you should
still be listening.

> About closing/reopening the outline view...I didn't think about that...in
> fact I just don't know anything about what happen in that case...I am
> still very dumb about all the Eclipse things and swt...but I trust you :D
!

Basically, you'll be asked for a whole new outlinepage. What you do is your
decision. I would recreate everything, but you'll have listener leaks if
you don't cleanup on dispose()
Re: is JFace TreeViewer is identical to GEF one? [message #135660 is a reply to message #135532] Wed, 02 June 2004 14:53 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: rlemaigr.ulb.ac.be

> I wouldn't want to rely on this type of behavior. In fact, I think yo=
u =

> have
> it backwards. JFace ListenerList only allows single entries, but ever=
y
> other notifying mechanism I've ever seen allows multiple entries. I =

> think
> this is more correct. If you call add twice and remove once, you shou=
ld
> still be listening.

You're right, seen like that it is more correct. I never thought to that=
=

this way.

By the way, talking about multiple registering/unregistering of listener=
s:

In the class BendpointHandle the addNotify method does

public void addNotify() {
super.addNotify();
getOwnerFigure().addPropertyChangeListener(Connection.PROPER TY_POINTS, =
=

this);
}

and the super implementation of this method in the class ConnectionHandl=
e =

seems to do exactly the same thing:

public void addNotify() {
super.addNotify();
getConnection().addPropertyChangeListener(Connection.PROPERT Y_POINTS, =

this);
}

so the listener seems to be added twice.

Is this a bug ?

r=E9gis
Re: is JFace TreeViewer is identical to GEF one? [message #135763 is a reply to message #135660] Wed, 02 June 2004 16:01 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: none.us.ibm.com

Yes, it looks like a performance bug of sorts. At least remove is called
twice.

<rlemaigr@ulb.ac.be> wrote in message
news:opr8y2a6bkxn9g2u@xn--pcrgis-dva.mshome.net...
> I wouldn't want to rely on this type of behavior. In fact, I think you
> have
> it backwards. JFace ListenerList only allows single entries, but every
> other notifying mechanism I've ever seen allows multiple entries. I
> think
> this is more correct. If you call add twice and remove once, you should
> still be listening.

You're right, seen like that it is more correct. I never thought to that
this way.

By the way, talking about multiple registering/unregistering of listeners:

In the class BendpointHandle the addNotify method does

public void addNotify() {
super.addNotify();
getOwnerFigure().addPropertyChangeListener(Connection.PROPER TY_POINTS,
this);
}

and the super implementation of this method in the class ConnectionHandle
seems to do exactly the same thing:

public void addNotify() {
super.addNotify();
getConnection().addPropertyChangeListener(Connection.PROPERT Y_POINTS,
this);
}

so the listener seems to be added twice.

Is this a bug ?

r
Re: is JFace TreeViewer is identical to GEF one? [message #242291 is a reply to message #135396] Wed, 09 April 2008 12:19 Go to previous message
Eclipse UserFriend
Originally posted by: shady_86.sify.com

Hi
I read the above posts and it cleared some of my idea about the GEF and JFace tree Viewer.
Actually i have a problem, i have a GEF model that is used to construct different types of Shapes on the editor. Now i also want these shapes to be visible in the Outline View.
I am succedded to show it in the outline view, but, the figures are added under a single root. What i want is to add each type of figure under their respective parent.
Plz clear my doubt is it possible to do with the same model.

Secondly, if i use JFace style for creating treeviewer will it support the model that i have made according to GEF.
Previous Topic:KeyHandler doesn't retrieve an enabled action
Next Topic:start connection on mouse click
Goto Forum:
  


Current Time: Thu Mar 28 20:42:31 GMT 2024

Powered by FUDForum. Page generated in 0.03513 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top