Home » Eclipse Projects » GEF » DND insight
| DND insight [message #105043] |
Thu, 13 November 2003 11:59  |
Eclipse User |
|
|
|
Hello,
I need some insight into this:
If I installed DropTarget and DragSource listeners in the
GraphicalEditPartViewer, and then I dragged one editpart (with a
DragEditPartsTracker installed):
What object is doing the dragging now, the DragSourceListener, the
DragEditPartsTracker or both?
What object is doing the dropping (sending the requests), the
DragTargetListener, the DragEditPartsTracker or both?
So I guess the question becomes if GEF allowed for native SWT DND, why do we
need DragEditPartsTrackers?
Thanks very much...
Maged
|
|
| |
| Re: DND insight [message #105074 is a reply to message #105059] |
Thu, 13 November 2003 14:23  |
| Eclipse User |
|
|
|
1- Does this mean that TransferDragSourceListener was not designed for
GraphicalViewers? The use case I am trying to support is DND of editparts in
different graphical viewers.
2- When you said you recommend native DND to drop into diagram, you meant
the dragging started outside the diagram (not totally within diagram), is
that right?
3- Cannot we simulate SWT DND "detail" (mouse cursor) inside the
DragEditPartsTracker? i.e allow copy, move, link, none?
"Randy Hudson" <none@us.ibm.com> wrote in message
news:bp0jg1$ork$1@eclipse.org...
> I would recommend that you use native DND for dropping stuff into your
> diagram, but not for dragging from your diagram. Do you have a case where
> you need to drag from your graphical viewer to some other viewer?
>
> One reasons is the limitation of not being able to set the mouse cursor.
>
> "Maged Elaasar" <melaasar@ca.ibm.com> wrote in message
> news:bp0d6b$gm8$1@eclipse.org...
> > Hello,
> >
> > I need some insight into this:
> >
> > If I installed DropTarget and DragSource listeners in the
> > GraphicalEditPartViewer, and then I dragged one editpart (with a
> > DragEditPartsTracker installed):
> >
> > What object is doing the dragging now, the DragSourceListener, the
> > DragEditPartsTracker or both?
> >
> > What object is doing the dropping (sending the requests), the
> > DragTargetListener, the DragEditPartsTracker or both?
> >
> > So I guess the question becomes if GEF allowed for native SWT DND, why
do
> we
> > need DragEditPartsTrackers?
> >
> > Thanks very much...
> >
> > Maged
> >
> >
> >
>
>
|
|
|
| Re: DND insight [message #105082 is a reply to message #105074] |
Thu, 13 November 2003 14:28 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
"Maged Elaasar" <melaasar@ca.ibm.com> wrote in message
news:bp0lkt$rcb$1@eclipse.org...
> 1- Does this mean that TransferDragSourceListener was not designed for
> GraphicalViewers? The use case I am trying to support is DND of editparts
in
> different graphical viewers.
No, in fact the palette is a graphical viewer and can be a drag source.
>
> 2- When you said you recommend native DND to drop into diagram, you meant
> the dragging started outside the diagram (not totally within diagram), is
> that right?
yes
>
> 3- Cannot we simulate SWT DND "detail" (mouse cursor) inside the
> DragEditPartsTracker? i.e allow copy, move, link, none?
This is on the 3.0 plan. Things like pressing CTRL during a normal drag
will change the cursor to have a + sign, and will cause a copy instead of
move/reparent.
>
> "Randy Hudson" <none@us.ibm.com> wrote in message
> news:bp0jg1$ork$1@eclipse.org...
> > I would recommend that you use native DND for dropping stuff into your
> > diagram, but not for dragging from your diagram. Do you have a case
where
> > you need to drag from your graphical viewer to some other viewer?
> >
> > One reasons is the limitation of not being able to set the mouse cursor.
> >
> > "Maged Elaasar" <melaasar@ca.ibm.com> wrote in message
> > news:bp0d6b$gm8$1@eclipse.org...
> > > Hello,
> > >
> > > I need some insight into this:
> > >
> > > If I installed DropTarget and DragSource listeners in the
> > > GraphicalEditPartViewer, and then I dragged one editpart (with a
> > > DragEditPartsTracker installed):
> > >
> > > What object is doing the dragging now, the DragSourceListener, the
> > > DragEditPartsTracker or both?
> > >
> > > What object is doing the dropping (sending the requests), the
> > > DragTargetListener, the DragEditPartsTracker or both?
> > >
> > > So I guess the question becomes if GEF allowed for native SWT DND, why
> do
> > we
> > > need DragEditPartsTrackers?
> > >
> > > Thanks very much...
> > >
> > > Maged
> > >
> > >
> > >
> >
> >
>
>
|
|
|
| Re: DND insight [message #105094 is a reply to message #105082] |
Thu, 13 November 2003 16:45 |
| Eclipse User |
|
|
|
1- I still cannot see how the Drag operation is carried on an editpart in a
graphical viewer, when there are both a drag source and a
DragEditPartsTracker. Can you elaborate? (I have a ScrollingGraphicalViewer
with a FreeForm layout and I want to be able to both drag shapes within the
viewer and also to other viewers in different editors)
2- In the implementation of the TransferDropTargetListener, the definition
of the Request is left to the sub-classes. Then, if there are two editparts
on the diagram that need to interpret a drop of a file (for example)
differently, i.e: one wants to create a Label shape for the name of the file
(CreateRequest) where the other wants to just link to the file
(LinkRequest), then you have to install two listeners, each one with the
required request and then put the logic of choosing between them in each
listener. This separates the logic of what the "drop" means from the target
editpart and make it within this listener.
The way I see it more reasonable is that the listener creates a DropRequest
and stuff within it the objects being dropped, and when that request is
directed at the target editpart, it will have an DragDropEditPolicy in a
drag_drop_role where it will handle that request by maybe interpreting it as
another request (CreateRequest or LinkRequest). This essentially moves the
decision of what to do with the drop to the target editpart instead of with
the viewer (and its drop listeners) now. What do you think?
3- The same previous point applies to the DragEditPartsTracker where it now
assumes a Move or reparent request, when the gesture could only mean a link.
So, istead of making the tracking tool decide on the request, we make it
send a drag request and let the target interpret it as it wants (maybe the
default policy will interpret it as move/reparent). Again, you opinion in
appreciated...
Maged
"Randy Hudson" <none@us.ibm.com> wrote in message
news:bp0lsr$rls$1@eclipse.org...
> "Maged Elaasar" <melaasar@ca.ibm.com> wrote in message
> news:bp0lkt$rcb$1@eclipse.org...
> > 1- Does this mean that TransferDragSourceListener was not designed for
> > GraphicalViewers? The use case I am trying to support is DND of
editparts
> in
> > different graphical viewers.
>
> No, in fact the palette is a graphical viewer and can be a drag source.
>
> >
> > 2- When you said you recommend native DND to drop into diagram, you
meant
> > the dragging started outside the diagram (not totally within diagram),
is
> > that right?
> yes
>
> >
> > 3- Cannot we simulate SWT DND "detail" (mouse cursor) inside the
> > DragEditPartsTracker? i.e allow copy, move, link, none?
>
> This is on the 3.0 plan. Things like pressing CTRL during a normal drag
> will change the cursor to have a + sign, and will cause a copy instead of
> move/reparent.
>
> >
> > "Randy Hudson" <none@us.ibm.com> wrote in message
> > news:bp0jg1$ork$1@eclipse.org...
> > > I would recommend that you use native DND for dropping stuff into your
> > > diagram, but not for dragging from your diagram. Do you have a case
> where
> > > you need to drag from your graphical viewer to some other viewer?
> > >
> > > One reasons is the limitation of not being able to set the mouse
cursor.
> > >
> > > "Maged Elaasar" <melaasar@ca.ibm.com> wrote in message
> > > news:bp0d6b$gm8$1@eclipse.org...
> > > > Hello,
> > > >
> > > > I need some insight into this:
> > > >
> > > > If I installed DropTarget and DragSource listeners in the
> > > > GraphicalEditPartViewer, and then I dragged one editpart (with a
> > > > DragEditPartsTracker installed):
> > > >
> > > > What object is doing the dragging now, the DragSourceListener, the
> > > > DragEditPartsTracker or both?
> > > >
> > > > What object is doing the dropping (sending the requests), the
> > > > DragTargetListener, the DragEditPartsTracker or both?
> > > >
> > > > So I guess the question becomes if GEF allowed for native SWT DND,
why
> > do
> > > we
> > > > need DragEditPartsTrackers?
> > > >
> > > > Thanks very much...
> > > >
> > > > Maged
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
|
|
|
| Re: DND insight [message #105107 is a reply to message #105094] |
Thu, 13 November 2003 17:36 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
"Maged Elaasar" <melaasar@ca.ibm.com> wrote in message
news:bp0tuv$52o$1@eclipse.org...
> 1- I still cannot see how the Drag operation is carried on an editpart in
a
> graphical viewer, when there are both a drag source and a
> DragEditPartsTracker. Can you elaborate? (I have a
ScrollingGraphicalViewer
> with a FreeForm layout and I want to be able to both drag shapes within
the
> viewer and also to other viewers in different editors)
It is not possible. The drag tracker gets a mouseDown, followed by a
nativeDragStarted() event. It is NOT active during the native drag.
> 2- In the implementation of the TransferDropTargetListener, the definition
> of the Request is left to the sub-classes. Then, if there are two
editparts
> on the diagram that need to interpret a drop of a file (for example)
> differently, i.e: one wants to create a Label shape for the name of the
file
> (CreateRequest) where the other wants to just link to the file
> (LinkRequest), then you have to install two listeners, each one with the
> required request and then put the logic of choosing between them in each
> listener. This separates the logic of what the "drop" means from the
target
> editpart and make it within this listener.
Nothing is preventing you from using a single TransferDTL, which uses a
single request type, and allows the target editpart to decide. The
"typical" use for multiple listeners is for when different data types are
being dragged. Of course, it is possible to use a different listener for
each combination of (transfer, target editpart).
>
> The way I see it more reasonable is that the listener creates a
DropRequest
> and stuff within it the objects being dropped, and when that request is
> directed at the target editpart, it will have an DragDropEditPolicy in a
> drag_drop_role where it will handle that request by maybe interpreting it
as
> another request (CreateRequest or LinkRequest). This essentially moves the
> decision of what to do with the drop to the target editpart instead of
with
> the viewer (and its drop listeners) now. What do you think?
>
> 3- The same previous point applies to the DragEditPartsTracker where it
now
> assumes a Move or reparent request, when the gesture could only mean a
link.
> So, istead of making the tracking tool decide on the request, we make it
> send a drag request and let the target interpret it as it wants (maybe the
> default policy will interpret it as move/reparent). Again, you opinion in
> appreciated...
This is an interesting idea. But, are there really that many kinds of
dragging within a diagram? Would the target change the cursor as well? You
could experiment with such behavior in your own custom DragEditPartsTracker.
> Maged
>
>
> "Randy Hudson" <none@us.ibm.com> wrote in message
> news:bp0lsr$rls$1@eclipse.org...
> > "Maged Elaasar" <melaasar@ca.ibm.com> wrote in message
> > news:bp0lkt$rcb$1@eclipse.org...
> > > 1- Does this mean that TransferDragSourceListener was not designed for
> > > GraphicalViewers? The use case I am trying to support is DND of
> editparts
> > in
> > > different graphical viewers.
> >
> > No, in fact the palette is a graphical viewer and can be a drag source.
> >
> > >
> > > 2- When you said you recommend native DND to drop into diagram, you
> meant
> > > the dragging started outside the diagram (not totally within diagram),
> is
> > > that right?
> > yes
> >
> > >
> > > 3- Cannot we simulate SWT DND "detail" (mouse cursor) inside the
> > > DragEditPartsTracker? i.e allow copy, move, link, none?
> >
> > This is on the 3.0 plan. Things like pressing CTRL during a normal drag
> > will change the cursor to have a + sign, and will cause a copy instead
of
> > move/reparent.
> >
> > >
> > > "Randy Hudson" <none@us.ibm.com> wrote in message
> > > news:bp0jg1$ork$1@eclipse.org...
> > > > I would recommend that you use native DND for dropping stuff into
your
> > > > diagram, but not for dragging from your diagram. Do you have a case
> > where
> > > > you need to drag from your graphical viewer to some other viewer?
> > > >
> > > > One reasons is the limitation of not being able to set the mouse
> cursor.
> > > >
> > > > "Maged Elaasar" <melaasar@ca.ibm.com> wrote in message
> > > > news:bp0d6b$gm8$1@eclipse.org...
> > > > > Hello,
> > > > >
> > > > > I need some insight into this:
> > > > >
> > > > > If I installed DropTarget and DragSource listeners in the
> > > > > GraphicalEditPartViewer, and then I dragged one editpart (with a
> > > > > DragEditPartsTracker installed):
> > > > >
> > > > > What object is doing the dragging now, the DragSourceListener, the
> > > > > DragEditPartsTracker or both?
> > > > >
> > > > > What object is doing the dropping (sending the requests), the
> > > > > DragTargetListener, the DragEditPartsTracker or both?
> > > > >
> > > > > So I guess the question becomes if GEF allowed for native SWT DND,
> why
> > > do
> > > > we
> > > > > need DragEditPartsTrackers?
> > > > >
> > > > > Thanks very much...
> > > > >
> > > > > Maged
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
|
|
|
Goto Forum:
Current Time: Thu Jul 10 01:13:30 EDT 2025
Powered by FUDForum. Page generated in 0.06312 seconds |
Home