Home » Eclipse Projects » GEF » Forwarding drag requests to parent
| Forwarding drag requests to parent [message #133418] |
Fri, 21 May 2004 09:50  |
 Thomas Maier
Messages: 117
Registered: July 2009 |
Senior Member |
|
|
Hi all, seems my questions never end. How does an EditPolicy have to
look like that forwards "drag requests" to its parent EditPart? I
have spent some hours trying to figure out what requests get sent
where and which methods are called, but actually my confusion grew.
I have that scenario with a container containing several compartments.
I want to be able to drag the container around, so in
ContainerEditPart I say
installEditPolicy(EditPolicy.PRIMARY_DRAG_ROLE, new
ResizableEditPolicy());
Works fine. Now the container contains compartments (each with an
editpart and a figure). Those compartments may have a lot of
whitespace so I would like to be able to drag the container also when
click-holding compartment's whitespace, not only when click-holding
container space (space not occupied by any compartment). The
compartments have to respond to selection requests.
I thought I could simply write an EditPolicy that understands move
requests and says that its parent is responsible for it, like this:
public boolean understandsRequest(Request request)
{
return request.getType().equals(RequestConstants.REQ_MOVE)
|| super.understandsRequest(request);
}
public EditPart getTargetEditPart(Request request)
{
if (request.getType().equals(REQ_MOVE))
{ return getHost().getParent(); }
else
{ return null; }
}
But dragging seems a bit more complex. I saw add, orphan, delete,
selection and move requests. Might somebody please shed light on
this? Thanks, Thomas.
--
Thomas Maier <Thomas.Maier@uni-kassel.de>
|
|
|
| Re: Forwarding drag requests to parent [message #133512 is a reply to message #133418] |
Fri, 21 May 2004 14:59  |
Eclipse User |
|
|
|
Originally posted by: rlemaigr.ulb.ac.be
hello thomas,
I don't know the exact answer to your question but I hope my answer will=
=
help you a bit.
I've had a similar problem, but in my case the compartment EditParts =
didn't have to respond to selection requests, so my problem was simpler =
to =
solve than yours.
Looking in the code of DragEditPartTracker, I've found that the EditPart=
s =
that was actually moved was the selected EditParts. So I think the only =
=
solution to move the container EditPart when dragging on a compartement =
=
EditPart is to make the container EditPart become selected when the =
compartement EditPart is.
Maybe you could redifine the setSelected method of the compartment =
EditPart in a way that it makes his parent selected too ? Doing that =
(instead of forwarding selection requests to the parent EditPart), the =
compartment EditPart will still be able to respond to selection requests=
=
and showing the selection feedback you were talking about in your other =
=
question.
Let me know if it has helped you,
r=E9gis
On Fri, 21 May 2004 11:50:27 +0200, Thomas Maier =
<Thomas.Maier@uni-kassel.de> wrote:
> Hi all, seems my questions never end. How does an EditPolicy have to =
=
> look like that forwards "drag requests" to its parent EditPart? I hav=
e =
> spent some hours trying to figure out what requests get sent where and=
=
> which methods are called, but actually my confusion grew.
>
> I have that scenario with a container containing several compartments.=
=
> I want to be able to drag the container around, so in =
> ContainerEditPart I say
>
> installEditPolicy(EditPolicy.PRIMARY_DRAG_ROLE, new =
> ResizableEditPolicy());
>
> Works fine. Now the container contains compartments (each with an =
> editpart and a figure). Those compartments may have a lot of whitespa=
ce =
> so I would like to be able to drag the container also when click-holdi=
ng =
> compartment's whitespace, not only when click-holding container space =
=
> (space not occupied by any compartment). The compartments have to =
> respond to selection requests.
>
> I thought I could simply write an EditPolicy that understands move =
> requests and says that its parent is responsible for it, like this:
>
> public boolean understandsRequest(Request request)
> {
> return request.getType().equals(RequestConstants.REQ_MOVE)
> || super.understandsRequest(request);
> }
>
> public EditPart getTargetEditPart(Request request)
> {
> if (request.getType().equals(REQ_MOVE))
> { return getHost().getParent(); }
> else
> { return null; }
> }
>
> But dragging seems a bit more complex. I saw add, orphan, delete, =
> selection and move requests. Might somebody please shed light on this=
? =
> Thanks, Thomas.
>
-- =
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
|
|
|
| Re: Forwarding drag requests to parent [message #133538 is a reply to message #133512] |
Fri, 21 May 2004 16:34 |
Thomas Maier
Messages: 117
Registered: July 2009 |
Senior Member |
|
|
Hi Régis,
thanks a lot for your follow up. I am trying your tip since you
posted it and unfortunately it does not work. Maybe I should say I
cannot get it work. Overriding setSelected like
public void setSelected(int value)
{
super.setSelected(value);
getParent().setSelected(value);
}
or like
public void setSelected(int value)
{
getParent().setSelected(value);
}
does not do what I want. It has the nice effect that the container is
selected when I click into a compartment but that's it. Dragging the
compartment does not drag the container.
I can forward *all* requests to the parent (container) editpart, that
works. Well, the dragging works. But then my compartments can not
respond to selection requests. So, any other hint?
Thanks anyway, at least I learnt about setSelected :).
rlemaigr@ulb.ac.be wrote:
> hello thomas,
>
> I don't know the exact answer to your question but I hope my answer
> will help you a bit.
>
> I've had a similar problem, but in my case the compartment EditParts
> didn't have to respond to selection requests, so my problem was simpler
> to solve than yours.
>
> Looking in the code of DragEditPartTracker, I've found that the
> EditParts that was actually moved was the selected EditParts. So I
> think the only solution to move the container EditPart when dragging on
> a compartement EditPart is to make the container EditPart become
> selected when the compartement EditPart is.
> Maybe you could redifine the setSelected method of the compartment
> EditPart in a way that it makes his parent selected too ? Doing that
> (instead of forwarding selection requests to the parent EditPart), the
> compartment EditPart will still be able to respond to selection
> requests and showing the selection feedback you were talking about in
> your other question.
>
> Let me know if it has helped you,
>
> régis
>
> On Fri, 21 May 2004 11:50:27 +0200, Thomas Maier
> <Thomas.Maier@uni-kassel.de> wrote:
>
>> Hi all, seems my questions never end. How does an EditPolicy have to
>> look like that forwards "drag requests" to its parent EditPart? I
>> have spent some hours trying to figure out what requests get sent
>> where and which methods are called, but actually my confusion grew.
>>
>> I have that scenario with a container containing several
>> compartments. I want to be able to drag the container around, so
>> in ContainerEditPart I say
>>
>> installEditPolicy(EditPolicy.PRIMARY_DRAG_ROLE, new
>> ResizableEditPolicy());
>>
>> Works fine. Now the container contains compartments (each with an
>> editpart and a figure). Those compartments may have a lot of
>> whitespace so I would like to be able to drag the container also when
>> click-holding compartment's whitespace, not only when click-holding
>> container space (space not occupied by any compartment). The
>> compartments have to respond to selection requests.
>>
>> I thought I could simply write an EditPolicy that understands move
>> requests and says that its parent is responsible for it, like this:
>>
>> public boolean understandsRequest(Request request)
>> {
>> return request.getType().equals(RequestConstants.REQ_MOVE)
>> || super.understandsRequest(request);
>> }
>>
>> public EditPart getTargetEditPart(Request request)
>> {
>> if (request.getType().equals(REQ_MOVE))
>> { return getHost().getParent(); }
>> else
>> { return null; }
>> }
>>
>> But dragging seems a bit more complex. I saw add, orphan, delete,
>> selection and move requests. Might somebody please shed light on
>> this? Thanks, Thomas.
>>
>
>
>
--
Thomas Maier <Thomas.Maier@uni-kassel.de>
|
|
|
| Re: Forwarding drag requests to parent [message #133577 is a reply to message #133538] |
Fri, 21 May 2004 17:40 |
| Eclipse User |
|
|
|
Originally posted by: rlemaigr.ulb.ac.be
Ok I don't know why it doesn't work but I was not sure at all about it, =
=
that was just something to try, so if it doesn't work it probably just =
means that I was wrong, not that you did't do the right things to get it=
=
work.
I'm trying to find why my idea didn't worked. If I find what was wrong, =
=
I'll let you know.
I believe you will have to wait for a much better quality answer for one=
=
of the gods of gef like randy hundson or another one...
bye,
r=E9gis
On Fri, 21 May 2004 18:34:41 +0200, Thomas Maier =
<Thomas.Maier@uni-kassel.de> wrote:
> Hi R=E9gis,
>
> thanks a lot for your follow up. I am trying your tip since you poste=
d =
> it and unfortunately it does not work. Maybe I should say I cannot ge=
t =
> it work. Overriding setSelected like
>
> public void setSelected(int value)
> {
> super.setSelected(value);
> getParent().setSelected(value);
> }
>
> or like
>
> public void setSelected(int value)
> {
> getParent().setSelected(value);
> }
>
> does not do what I want. It has the nice effect that the container is=
=
> selected when I click into a compartment but that's it. Dragging the =
=
> compartment does not drag the container.
>
> I can forward *all* requests to the parent (container) editpart, that =
=
> works. Well, the dragging works. But then my compartments can not =
> respond to selection requests. So, any other hint?
>
> Thanks anyway, at least I learnt about setSelected :).
>
> rlemaigr@ulb.ac.be wrote:
>> hello thomas,
>> I don't know the exact answer to your question but I hope my answer =
=
>> will help you a bit.
>> I've had a similar problem, but in my case the compartment EditParts=
=
>> didn't have to respond to selection requests, so my problem was simpl=
er =
>> to solve than yours.
>> Looking in the code of DragEditPartTracker, I've found that the =
>> EditParts that was actually moved was the selected EditParts. So I =
>> think the only solution to move the container EditPart when dragging=
=
>> on a compartement EditPart is to make the container EditPart become =
=
>> selected when the compartement EditPart is.
>> Maybe you could redifine the setSelected method of the compartment =
>> EditPart in a way that it makes his parent selected too ? Doing that =
=
>> (instead of forwarding selection requests to the parent EditPart), th=
e =
>> compartment EditPart will still be able to respond to selection =
>> requests and showing the selection feedback you were talking about i=
n =
>> your other question.
>> Let me know if it has helped you,
>> r=E9gis
>> On Fri, 21 May 2004 11:50:27 +0200, Thomas Maier =
>> <Thomas.Maier@uni-kassel.de> wrote:
>>
>>> Hi all, seems my questions never end. How does an EditPolicy have t=
o =
>>> look like that forwards "drag requests" to its parent EditPart? I =
>>> have spent some hours trying to figure out what requests get sent =
>>> where and which methods are called, but actually my confusion grew.=
>>>
>>> I have that scenario with a container containing several =
>>> compartments. I want to be able to drag the container around, so =
=
>>> in ContainerEditPart I say
>>>
>>> installEditPolicy(EditPolicy.PRIMARY_DRAG_ROLE, new =
>>> ResizableEditPolicy());
>>>
>>> Works fine. Now the container contains compartments (each with an =
=
>>> editpart and a figure). Those compartments may have a lot of =
>>> whitespace so I would like to be able to drag the container also wh=
en =
>>> click-holding compartment's whitespace, not only when click-holding=
=
>>> container space (space not occupied by any compartment). The =
>>> compartments have to respond to selection requests.
>>>
>>> I thought I could simply write an EditPolicy that understands move =
=
>>> requests and says that its parent is responsible for it, like this:
>>>
>>> public boolean understandsRequest(Request request)
>>> {
>>> return request.getType().equals(RequestConstants.REQ_MOVE)
>>> || super.understandsRequest(request);
>>> }
>>>
>>> public EditPart getTargetEditPart(Request request)
>>> {
>>> if (request.getType().equals(REQ_MOVE))
>>> { return getHost().getParent(); }
>>> else
>>> { return null; }
>>> }
>>>
>>> But dragging seems a bit more complex. I saw add, orphan, delete, =
=
>>> selection and move requests. Might somebody please shed light on =
>>> this? Thanks, Thomas.
>>>
>>
>
>
-- =
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
|
|
|
| Re: Forwarding drag requests to parent [message #133590 is a reply to message #133538] |
Fri, 21 May 2004 17:51 |
| Eclipse User |
|
|
|
Originally posted by: rlemaigr.ulb.ac.be
I found something that seems to work !
In the compartment EditPart, redifine the getDragTracker method to:
public DragTracker getDragTracker(Request request) {
return new org.eclipse.gef.tools.DragEditPartsTracker( getParent() );
}
instead of
public DragTracker getDragTracker(Request request) {
return new org.eclipse.gef.tools.DragEditPartsTracker( this );
}
does it work ?
r=E9gis
On Fri, 21 May 2004 18:34:41 +0200, Thomas Maier =
<Thomas.Maier@uni-kassel.de> wrote:
> Hi R=E9gis,
>
> thanks a lot for your follow up. I am trying your tip since you poste=
d =
> it and unfortunately it does not work. Maybe I should say I cannot ge=
t =
> it work. Overriding setSelected like
>
> public void setSelected(int value)
> {
> super.setSelected(value);
> getParent().setSelected(value);
> }
>
> or like
>
> public void setSelected(int value)
> {
> getParent().setSelected(value);
> }
>
> does not do what I want. It has the nice effect that the container is=
=
> selected when I click into a compartment but that's it. Dragging the =
=
> compartment does not drag the container.
>
> I can forward *all* requests to the parent (container) editpart, that =
=
> works. Well, the dragging works. But then my compartments can not =
> respond to selection requests. So, any other hint?
>
> Thanks anyway, at least I learnt about setSelected :).
>
> rlemaigr@ulb.ac.be wrote:
>> hello thomas,
>> I don't know the exact answer to your question but I hope my answer =
=
>> will help you a bit.
>> I've had a similar problem, but in my case the compartment EditParts=
=
>> didn't have to respond to selection requests, so my problem was simpl=
er =
>> to solve than yours.
>> Looking in the code of DragEditPartTracker, I've found that the =
>> EditParts that was actually moved was the selected EditParts. So I =
>> think the only solution to move the container EditPart when dragging=
=
>> on a compartement EditPart is to make the container EditPart become =
=
>> selected when the compartement EditPart is.
>> Maybe you could redifine the setSelected method of the compartment =
>> EditPart in a way that it makes his parent selected too ? Doing that =
=
>> (instead of forwarding selection requests to the parent EditPart), th=
e =
>> compartment EditPart will still be able to respond to selection =
>> requests and showing the selection feedback you were talking about i=
n =
>> your other question.
>> Let me know if it has helped you,
>> r=E9gis
>> On Fri, 21 May 2004 11:50:27 +0200, Thomas Maier =
>> <Thomas.Maier@uni-kassel.de> wrote:
>>
>>> Hi all, seems my questions never end. How does an EditPolicy have t=
o =
>>> look like that forwards "drag requests" to its parent EditPart? I =
>>> have spent some hours trying to figure out what requests get sent =
>>> where and which methods are called, but actually my confusion grew.=
>>>
>>> I have that scenario with a container containing several =
>>> compartments. I want to be able to drag the container around, so =
=
>>> in ContainerEditPart I say
>>>
>>> installEditPolicy(EditPolicy.PRIMARY_DRAG_ROLE, new =
>>> ResizableEditPolicy());
>>>
>>> Works fine. Now the container contains compartments (each with an =
=
>>> editpart and a figure). Those compartments may have a lot of =
>>> whitespace so I would like to be able to drag the container also wh=
en =
>>> click-holding compartment's whitespace, not only when click-holding=
=
>>> container space (space not occupied by any compartment). The =
>>> compartments have to respond to selection requests.
>>>
>>> I thought I could simply write an EditPolicy that understands move =
=
>>> requests and says that its parent is responsible for it, like this:
>>>
>>> public boolean understandsRequest(Request request)
>>> {
>>> return request.getType().equals(RequestConstants.REQ_MOVE)
>>> || super.understandsRequest(request);
>>> }
>>>
>>> public EditPart getTargetEditPart(Request request)
>>> {
>>> if (request.getType().equals(REQ_MOVE))
>>> { return getHost().getParent(); }
>>> else
>>> { return null; }
>>> }
>>>
>>> But dragging seems a bit more complex. I saw add, orphan, delete, =
=
>>> selection and move requests. Might somebody please shed light on =
>>> this? Thanks, Thomas.
>>>
>>
>
>
-- =
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
|
|
|
| Re: Forwarding drag requests to parent [message #133603 is a reply to message #133590] |
Fri, 21 May 2004 18:14 |
Thomas Maier
Messages: 117
Registered: July 2009 |
Senior Member |
|
|
Régis, now I can finally leave university and enjoy my weekend :).
Thanks a lot for your hint, it works. I still wonder whether this is
the right thing to do (hoping for one of the gurus to say yes or
explain what really needs to be done). Anyway, cheers to you and a
nice weekend, Thomas.
rlemaigr@ulb.ac.be wrote:
> I found something that seems to work !
>
> In the compartment EditPart, redifine the getDragTracker method to:
>
> public DragTracker getDragTracker(Request request) {
> return new org.eclipse.gef.tools.DragEditPartsTracker( getParent() );
> }
>
> instead of
>
> public DragTracker getDragTracker(Request request) {
> return new org.eclipse.gef.tools.DragEditPartsTracker( this );
> }
>
> does it work ?
>
> régis
>
> On Fri, 21 May 2004 18:34:41 +0200, Thomas Maier
> <Thomas.Maier@uni-kassel.de> wrote:
>
>> Hi Régis,
>>
>> thanks a lot for your follow up. I am trying your tip since you
>> posted it and unfortunately it does not work. Maybe I should say I
>> cannot get it work. Overriding setSelected like
>>
>> public void setSelected(int value)
>> {
>> super.setSelected(value);
>> getParent().setSelected(value);
>> }
>>
>> or like
>>
>> public void setSelected(int value)
>> {
>> getParent().setSelected(value);
>> }
>>
>> does not do what I want. It has the nice effect that the container
>> is selected when I click into a compartment but that's it. Dragging
>> the compartment does not drag the container.
>>
>> I can forward *all* requests to the parent (container) editpart, that
>> works. Well, the dragging works. But then my compartments can not
>> respond to selection requests. So, any other hint?
>>
>> Thanks anyway, at least I learnt about setSelected :).
>>
>> rlemaigr@ulb.ac.be wrote:
>>
>>> hello thomas,
>>> I don't know the exact answer to your question but I hope my answer
>>> will help you a bit.
>>> I've had a similar problem, but in my case the compartment
>>> EditParts didn't have to respond to selection requests, so my
>>> problem was simpler to solve than yours.
>>> Looking in the code of DragEditPartTracker, I've found that the
>>> EditParts that was actually moved was the selected EditParts. So I
>>> think the only solution to move the container EditPart when
>>> dragging on a compartement EditPart is to make the container
>>> EditPart become selected when the compartement EditPart is.
>>> Maybe you could redifine the setSelected method of the compartment
>>> EditPart in a way that it makes his parent selected too ? Doing
>>> that (instead of forwarding selection requests to the parent
>>> EditPart), the compartment EditPart will still be able to respond
>>> to selection requests and showing the selection feedback you were
>>> talking about in your other question.
>>> Let me know if it has helped you,
>>> régis
>>> On Fri, 21 May 2004 11:50:27 +0200, Thomas Maier
>>> <Thomas.Maier@uni-kassel.de> wrote:
>>>
>>>> Hi all, seems my questions never end. How does an EditPolicy have
>>>> to look like that forwards "drag requests" to its parent
>>>> EditPart? I have spent some hours trying to figure out what
>>>> requests get sent where and which methods are called, but actually
>>>> my confusion grew.
>>>>
>>>> I have that scenario with a container containing several
>>>> compartments. I want to be able to drag the container around, so
>>>> in ContainerEditPart I say
>>>>
>>>> installEditPolicy(EditPolicy.PRIMARY_DRAG_ROLE, new
>>>> ResizableEditPolicy());
>>>>
>>>> Works fine. Now the container contains compartments (each with an
>>>> editpart and a figure). Those compartments may have a lot of
>>>> whitespace so I would like to be able to drag the container also
>>>> when click-holding compartment's whitespace, not only when
>>>> click-holding container space (space not occupied by any
>>>> compartment). The compartments have to respond to selection
>>>> requests.
>>>>
>>>> I thought I could simply write an EditPolicy that understands move
>>>> requests and says that its parent is responsible for it, like this:
>>>>
>>>> public boolean understandsRequest(Request request)
>>>> {
>>>> return request.getType().equals(RequestConstants.REQ_MOVE)
>>>> || super.understandsRequest(request);
>>>> }
>>>>
>>>> public EditPart getTargetEditPart(Request request)
>>>> {
>>>> if (request.getType().equals(REQ_MOVE))
>>>> { return getHost().getParent(); }
>>>> else
>>>> { return null; }
>>>> }
>>>>
>>>> But dragging seems a bit more complex. I saw add, orphan, delete,
>>>> selection and move requests. Might somebody please shed light on
>>>> this? Thanks, Thomas.
>>>>
>>>
>>
>>
>
>
>
--
Thomas Maier <Thomas.Maier@uni-kassel.de>
|
|
|
| Re: Forwarding drag requests to parent [message #133849 is a reply to message #133418] |
Mon, 24 May 2004 12:55 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
Why don't you do this:
CompartmentEditPart {
.....
public boolean isSelectable() { return false; }
.....
}
Compartments are useful for grouping children, but I don't see any reason
why they should be selectable.
"Thomas Maier" <Thomas.Maier@uni-kassel.de> wrote in message
news:40ADD0E3.1020103@uni-kassel.de...
> Hi all, seems my questions never end. How does an EditPolicy have to
> look like that forwards "drag requests" to its parent EditPart? I
> have spent some hours trying to figure out what requests get sent
> where and which methods are called, but actually my confusion grew.
>
> I have that scenario with a container containing several compartments.
> I want to be able to drag the container around, so in
> ContainerEditPart I say
>
> installEditPolicy(EditPolicy.PRIMARY_DRAG_ROLE, new
> ResizableEditPolicy());
>
> Works fine. Now the container contains compartments (each with an
> editpart and a figure). Those compartments may have a lot of
> whitespace so I would like to be able to drag the container also when
> click-holding compartment's whitespace, not only when click-holding
> container space (space not occupied by any compartment). The
> compartments have to respond to selection requests.
>
> I thought I could simply write an EditPolicy that understands move
> requests and says that its parent is responsible for it, like this:
>
> public boolean understandsRequest(Request request)
> {
> return request.getType().equals(RequestConstants.REQ_MOVE)
> || super.understandsRequest(request);
> }
>
> public EditPart getTargetEditPart(Request request)
> {
> if (request.getType().equals(REQ_MOVE))
> { return getHost().getParent(); }
> else
> { return null; }
> }
>
> But dragging seems a bit more complex. I saw add, orphan, delete,
> selection and move requests. Might somebody please shed light on
> this? Thanks, Thomas.
>
> --
> Thomas Maier <Thomas.Maier@uni-kassel.de>
|
|
|
| Re: Forwarding drag requests to parent [message #133874 is a reply to message #133849] |
Mon, 24 May 2004 17:50 |
Thomas Maier
Messages: 117
Registered: July 2009 |
Senior Member |
|
|
Nice pointer, thanks :). Unfortunately GEF seems to mix up, well,
"click-selection" and "point-the-mouse-at-and-dont't-click-selection".
The point is that I want to display feedback when the mouse hovers
above a compartment. I do not want them to be selectable and
draggable. But I do not get any selection requests when I do what you
say. I wonder anyway why it seems to be the same to click on
something and to just point at something. What is the rationale of
that? And how can I get what I want? Shouldn't GEF send different
requests?
Randy Hudson wrote:
> Why don't you do this:
>
> CompartmentEditPart {
> ....
>
> public boolean isSelectable() { return false; }
>
> ....
> }
>
> Compartments are useful for grouping children, but I don't see any reason
> why they should be selectable.
>
> "Thomas Maier" <Thomas.Maier@uni-kassel.de> wrote in message
> news:40ADD0E3.1020103@uni-kassel.de...
>
>>Hi all, seems my questions never end. How does an EditPolicy have to
>>look like that forwards "drag requests" to its parent EditPart? I
>>have spent some hours trying to figure out what requests get sent
>>where and which methods are called, but actually my confusion grew.
>>
>>I have that scenario with a container containing several compartments.
>> I want to be able to drag the container around, so in
>>ContainerEditPart I say
>>
>>installEditPolicy(EditPolicy.PRIMARY_DRAG_ROLE, new
>>ResizableEditPolicy());
>>
>>Works fine. Now the container contains compartments (each with an
>>editpart and a figure). Those compartments may have a lot of
>>whitespace so I would like to be able to drag the container also when
>>click-holding compartment's whitespace, not only when click-holding
>>container space (space not occupied by any compartment). The
>>compartments have to respond to selection requests.
>>
>>I thought I could simply write an EditPolicy that understands move
>>requests and says that its parent is responsible for it, like this:
>>
>>public boolean understandsRequest(Request request)
>>{
>> return request.getType().equals(RequestConstants.REQ_MOVE)
>> || super.understandsRequest(request);
>>}
>>
>>public EditPart getTargetEditPart(Request request)
>>{
>> if (request.getType().equals(REQ_MOVE))
>> { return getHost().getParent(); }
>> else
>> { return null; }
>>}
>>
>>But dragging seems a bit more complex. I saw add, orphan, delete,
>>selection and move requests. Might somebody please shed light on
>>this? Thanks, Thomas.
>>
>>--
>>Thomas Maier <Thomas.Maier@uni-kassel.de>
>
>
>
--
Thomas Maier <Thomas.Maier@uni-kassel.de>
|
|
|
| Re: Forwarding drag requests to parent [message #133924 is a reply to message #133874] |
Mon, 24 May 2004 22:17 |
| Eclipse User |
|
|
|
Originally posted by: rlemaigr.ulb.ac.be
Hello again !
First, I maybe wrong (as always :D) but I think the selection of an =
EditPart is not made by gef as a result of a request, but as a result of=
=
calling setSelected(true) on an EditPart. The SelectionTool do not use i=
n =
this case the usual "I send you a request, you give me the command, I ma=
ke =
the CommandStack execute your command" process. That is logical because =
=
the selection is something concerning only the editor, not modifying the=
=
model and thus have not to be undoable and the use of a command is =
unneccessary. So I wouldn't expect recieving a request when the user cli=
ck =
on an EditPart to select it.
Second, I think the SelectionRequests are just sent by the SelectionTool=
=
to find wich EditPart under the mouse pointer should be selected if the =
=
mouse is clicked, each time the mouse move over the diagram. Such an =
EditPart will then be asked for showing selection feedback by passing to=
=
its showSourceFeedback(Request) method a SelectionRequest. So the =
selection feedback is used by GEF to show to the user that he can select=
=
this EditPart. When GEF find a valid target for selection, it shows =
selection feedback to indicate it to the user.
Keeping that in mind, you should understand why GEF is not made to allow=
=
what you want to do to be easily done. It is because showing to the user=
=
by a selection feedback that he can select an EditPart that can not be =
selected don't make any sense.
Maybe you should find another way to highlight the comparments when the =
=
mouse is over them...maybe not using gef but draw2d...maybe by adding a =
=
mouse listener to the draw2d figures of the compartments and reacting to=
=
the mouse entered/exited events in someway (a nice way would be for =
example switching the background color and the foreground color of the =
compartment, showing sort of a "negative image" of the compartment, and =
=
its content because foregroundcolor and backgroundcolor are inherited by=
=
the children figures). I think it would be better to do this in draw2d =
because it has nothing to do with GEF when you think about it. It's only=
=
some kind of decoration wich has no meaning for GEF...
r=E9gis
On Mon, 24 May 2004 19:50:06 +0200, Thomas Maier =
<Thomas.Maier@uni-kassel.de> wrote:
> Nice pointer, thanks :). Unfortunately GEF seems to mix up, well, =
> "click-selection" and "point-the-mouse-at-and-dont't-click-selection".=
=
> The point is that I want to display feedback when the mouse hovers =
> above a compartment. I do not want them to be selectable and =
> draggable. But I do not get any selection requests when I do what you=
=
> say. I wonder anyway why it seems to be the same to click on somethin=
g =
> and to just point at something. What is the rationale of that? And h=
ow =
> can I get what I want? Shouldn't GEF send different requests?
>
> Randy Hudson wrote:
>> Why don't you do this:
>> CompartmentEditPart {
>> ....
>> public boolean isSelectable() { return false; }
>> ....
>> }
>> Compartments are useful for grouping children, but I don't see any =
>> reason
>> why they should be selectable.
>> "Thomas Maier" <Thomas.Maier@uni-kassel.de> wrote in message
>> news:40ADD0E3.1020103@uni-kassel.de...
>>
>>> Hi all, seems my questions never end. How does an EditPolicy have t=
o
>>> look like that forwards "drag requests" to its parent EditPart? I
>>> have spent some hours trying to figure out what requests get sent
>>> where and which methods are called, but actually my confusion grew.
>>>
>>> I have that scenario with a container containing several compartment=
s.
>>> I want to be able to drag the container around, so in
>>> ContainerEditPart I say
>>>
>>> installEditPolicy(EditPolicy.PRIMARY_DRAG_ROLE, new
>>> ResizableEditPolicy());
>>>
>>> Works fine. Now the container contains compartments (each with an
>>> editpart and a figure). Those compartments may have a lot of
>>> whitespace so I would like to be able to drag the container also whe=
n
>>> click-holding compartment's whitespace, not only when click-holding
>>> container space (space not occupied by any compartment). The
>>> compartments have to respond to selection requests.
>>>
>>> I thought I could simply write an EditPolicy that understands move
>>> requests and says that its parent is responsible for it, like this:
>>>
>>> public boolean understandsRequest(Request request)
>>> {
>>> return request.getType().equals(RequestConstants.REQ_MOVE)
>>> || super.understandsRequest(request);
>>> }
>>>
>>> public EditPart getTargetEditPart(Request request)
>>> {
>>> if (request.getType().equals(REQ_MOVE))
>>> { return getHost().getParent(); }
>>> else
>>> { return null; }
>>> }
>>>
>>> But dragging seems a bit more complex. I saw add, orphan, delete,
>>> selection and move requests. Might somebody please shed light on
>>> this? Thanks, Thomas.
>>>
>>> -- Thomas Maier <Thomas.Maier@uni-kassel.de>
>>
>
>
-- =
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
|
|
|
| Feature Request: new request type (was: Re: Forwarding drag requests to parent) [message #134037 is a reply to message #133924] |
Tue, 25 May 2004 06:39 |
Thomas Maier
Messages: 117
Registered: July 2009 |
Senior Member |
|
|
I do not expect to get a request that wants a command. I do expect
that GEF tells me to show selection feedback. It does. But I also
expect that GEF tells me "hey, the user is pointing the mouse at your
thing, maybe you want to give him some feedback?". Some feedback that
does not necessarily mean that the user can click and select it. And
I have thought about it. After all I am using the GEF selection tool
and I am pointing at my GEF objects in my GEF editor. And I want to
be able to react on that. I want my compartments to show a button
(that is hidden otherwise) when the mouse is hovering above them that
collapses/expands them. Or that pops up a menu with even more
commands to manipulate them.
Sure, I examined GEF's behaviour based on the current implementation.
I would also rather like to rely on specified behaviour. But the
documentation is, well, somewhat sparse. So I guess I got confused by
the selection tool, got lost in details and abused the selection
requests (and mixed things up myself). So what I am actually asking
for is a new feature: the selection tool should tell me that the user
is pointing the mouse at my objects? Some kind of
"pointing-at-requests without caring whether that thing is selectable"?
Might somebody pleasy clarify to me what "selection" and "selection
hover" means, what it is intended for, how it is currently implemented
and if this differs from each other? And how I get what I want to?
I think it is like this:
Selection requests are sent to my objects so that my objects can
display feedback telling the user that he can select the object by
clicking the mouse on it. Their way is first getting the target edit
part (getTargetEditPart("REQ_SELECTION")) and then calling
showTargetFeedback("REQ_SELECTION"). When the user pulls the mouse
away from the object, eraseTargetFeedback("REQ_SELECTION") is called.
Selction hover requests are kind of the same but allow taking things
easy. No hectic flickery but only display feedback when the user
settles the mouse on my object.
Then I think the "pointing-at-request" and its hover companion are a
missing feature. With them I could do like randy said (say my objects
aren't selectable) and still react on the user hovering the mouse
above my objects. Proper separation of different things. That feels
right. Thoughts?
rlemaigr@ulb.ac.be wrote:
> Hello again !
>
> First, I maybe wrong (as always :D) but I think the selection of an
> EditPart is not made by gef as a result of a request, but as a result
> of calling setSelected(true) on an EditPart. The SelectionTool do not
> use in this case the usual "I send you a request, you give me the
> command, I make the CommandStack execute your command" process. That is
> logical because the selection is something concerning only the editor,
> not modifying the model and thus have not to be undoable and the use of
> a command is unneccessary. So I wouldn't expect recieving a request
> when the user click on an EditPart to select it.
>
> Second, I think the SelectionRequests are just sent by the
> SelectionTool to find wich EditPart under the mouse pointer should be
> selected if the mouse is clicked, each time the mouse move over the
> diagram. Such an EditPart will then be asked for showing selection
> feedback by passing to its showSourceFeedback(Request) method a
> SelectionRequest. So the selection feedback is used by GEF to show to
> the user that he can select this EditPart. When GEF find a valid target
> for selection, it shows selection feedback to indicate it to the user.
>
> Keeping that in mind, you should understand why GEF is not made to
> allow what you want to do to be easily done. It is because showing to
> the user by a selection feedback that he can select an EditPart that
> can not be selected don't make any sense.
>
> Maybe you should find another way to highlight the comparments when the
> mouse is over them...maybe not using gef but draw2d...maybe by adding a
> mouse listener to the draw2d figures of the compartments and reacting
> to the mouse entered/exited events in someway (a nice way would be for
> example switching the background color and the foreground color of the
> compartment, showing sort of a "negative image" of the compartment, and
> its content because foregroundcolor and backgroundcolor are inherited
> by the children figures). I think it would be better to do this in
> draw2d because it has nothing to do with GEF when you think about it.
> It's only some kind of decoration wich has no meaning for GEF...
>
> régis
>
> On Mon, 24 May 2004 19:50:06 +0200, Thomas Maier
> <Thomas.Maier@uni-kassel.de> wrote:
>
>> Nice pointer, thanks :). Unfortunately GEF seems to mix up, well,
>> "click-selection" and
>> "point-the-mouse-at-and-dont't-click-selection". The point is that
>> I want to display feedback when the mouse hovers above a
>> compartment. I do not want them to be selectable and draggable. But
>> I do not get any selection requests when I do what you say. I wonder
>> anyway why it seems to be the same to click on something and to just
>> point at something. What is the rationale of that? And how can I
>> get what I want? Shouldn't GEF send different requests?
>>
>> Randy Hudson wrote:
>>
>>> Why don't you do this:
>>> CompartmentEditPart {
>>> ....
>>> public boolean isSelectable() { return false; }
>>> ....
>>> }
>>> Compartments are useful for grouping children, but I don't see any
>>> reason
>>> why they should be selectable.
|
|
|
| Re: Feature Request: new request type (was: Re: Forwarding drag requests to parent) [message #134049 is a reply to message #134037] |
Tue, 25 May 2004 11:24 |
| Eclipse User |
|
|
|
Originally posted by: rlemaigr.ulb.ac.be
Yes maybe you're right and it is a missing feature I don't know...
Me too got very confused about the selection tool (and more generally by=
=
all the tools) because the code is quite hard the understand (I always g=
et =
completely lost in the TargetingTool class and almost all the tools are =
=
derived from that)...
Anyway the feature seems to be missing in GEF so we have to do something=
=
else :D
Have you considered what I said at the end of my previous message about =
=
doing what you want in Draw2d instead of GEF ?
I meant, adding some mouse listener to the figure of a compartement to =
react on mouse hover event. I think it is possible because before being =
=
sent to the tool currently active in gef, events get a chance of being =
treated by the draw2d figures themselves. For example I think tooltips a=
re =
display that way (or if it is not, it could be).
That could solve the graphical feedback problem and also the button thin=
g =
(you can call setVisible or setEnable on the button from the mouse =
listener).
For the menu thing, if your menu is built with a ContextMenuProvider and=
=
Actions (like in the logic example) wich are present in the menu iff the=
y =
are enabled, you could also do this from the mouse listener by =
enableing/disableing some actions and that way modify the content of a =
menu.
I don't like very much this solution for the menu because it makes the =
figures "intelligent" and this is not their purpose but if it works...
(maybe if we continue to search in circles like this for a long time, it=
=
will get here the gef gurus and you will got your answer I don't know :D=
)
r=E9gis
On Tue, 25 May 2004 08:39:57 +0200, Thomas Maier =
<Thomas.Maier@uni-kassel.de> wrote:
> I do not expect to get a request that wants a command. I do expect th=
at =
> GEF tells me to show selection feedback. It does. But I also expect =
=
> that GEF tells me "hey, the user is pointing the mouse at your thing, =
=
> maybe you want to give him some feedback?". Some feedback that does n=
ot =
> necessarily mean that the user can click and select it. And I have =
> thought about it. After all I am using the GEF selection tool and I a=
m =
> pointing at my GEF objects in my GEF editor. And I want to be able to=
=
> react on that. I want my compartments to show a button (that is hidde=
n =
> otherwise) when the mouse is hovering above them that collapses/expand=
s =
> them. Or that pops up a menu with even more commands to manipulate th=
em.
>
> Sure, I examined GEF's behaviour based on the current implementation. =
=
> I would also rather like to rely on specified behaviour. But the =
> documentation is, well, somewhat sparse. So I guess I got confused by=
=
> the selection tool, got lost in details and abused the selection =
> requests (and mixed things up myself). So what I am actually asking f=
or =
> is a new feature: the selection tool should tell me that the user is =
> pointing the mouse at my objects? Some kind of "pointing-at-requests =
=
> without caring whether that thing is selectable"?
>
> Might somebody pleasy clarify to me what "selection" and "selection =
> hover" means, what it is intended for, how it is currently implemented=
=
> and if this differs from each other? And how I get what I want to?
>
> I think it is like this:
>
> Selection requests are sent to my objects so that my objects can displ=
ay =
> feedback telling the user that he can select the object by clicking th=
e =
> mouse on it. Their way is first getting the target edit part =
> (getTargetEditPart("REQ_SELECTION")) and then calling =
> showTargetFeedback("REQ_SELECTION"). When the user pulls the mouse aw=
ay =
> from the object, eraseTargetFeedback("REQ_SELECTION") is called.
>
> Selction hover requests are kind of the same but allow taking things =
> easy. No hectic flickery but only display feedback when the user =
> settles the mouse on my object.
>
> Then I think the "pointing-at-request" and its hover companion are a =
> missing feature. With them I could do like randy said (say my objects=
=
> aren't selectable) and still react on the user hovering the mouse abov=
e =
> my objects. Proper separation of different things. That feels right.=
=
> Thoughts?
>
> rlemaigr@ulb.ac.be wrote:
>> Hello again !
>> First, I maybe wrong (as always :D) but I think the selection of an =
=
>> EditPart is not made by gef as a result of a request, but as a result=
=
>> of calling setSelected(true) on an EditPart. The SelectionTool do no=
t =
>> use in this case the usual "I send you a request, you give me the =
>> command, I make the CommandStack execute your command" process. That=
=
>> is logical because the selection is something concerning only the =
>> editor, not modifying the model and thus have not to be undoable and=
=
>> the use of a command is unneccessary. So I wouldn't expect recieving=
a =
>> request when the user click on an EditPart to select it.
> >
>> Second, I think the SelectionRequests are just sent by the =
>> SelectionTool to find wich EditPart under the mouse pointer should b=
e =
>> selected if the mouse is clicked, each time the mouse move over the =
=
>> diagram. Such an EditPart will then be asked for showing selection =
>> feedback by passing to its showSourceFeedback(Request) method a =
>> SelectionRequest. So the selection feedback is used by GEF to show t=
o =
>> the user that he can select this EditPart. When GEF find a valid =
>> target for selection, it shows selection feedback to indicate it to =
=
>> the user.
>> Keeping that in mind, you should understand why GEF is not made to =
>> allow what you want to do to be easily done. It is because showing t=
o =
>> the user by a selection feedback that he can select an EditPart that=
=
>> can not be selected don't make any sense.
>> Maybe you should find another way to highlight the comparments when =
=
>> the mouse is over them...maybe not using gef but draw2d...maybe by =
>> adding a mouse listener to the draw2d figures of the compartments an=
d =
>> reacting to the mouse entered/exited events in someway (a nice way =
>> would be for example switching the background color and the foregrou=
nd =
>> color of the compartment, showing sort of a "negative image" of the =
=
>> compartment, and its content because foregroundcolor and =
>> backgroundcolor are inherited by the children figures). I think it =
>> would be better to do this in draw2d because it has nothing to do wi=
th =
>> GEF when you think about it. It's only some kind of decoration wich =
=
>> has no meaning for GEF...
>> r=E9gis
>> On Mon, 24 May 2004 19:50:06 +0200, Thomas Maier =
>> <Thomas.Maier@uni-kassel.de> wrote:
>>
>>> Nice pointer, thanks :). Unfortunately GEF seems to mix up, well, =
=
>>> "click-selection" and =
>>> "point-the-mouse-at-and-dont't-click-selection". The point is tha=
t =
>>> I want to display feedback when the mouse hovers above a =
>>> compartment. I do not want them to be selectable and draggable. B=
ut =
>>> I do not get any selection requests when I do what you say. I wond=
er =
>>> anyway why it seems to be the same to click on something and to jus=
t =
>>> point at something. What is the rationale of that? And how can I =
=
>>> get what I want? Shouldn't GEF send different requests?
>>>
>>> Randy Hudson wrote:
>>>
>>>> Why don't you do this:
>>>> CompartmentEditPart {
>>>> ....
>>>> public boolean isSelectable() { return false; }
>>>> ....
>>>> }
>>>> Compartments are useful for grouping children, but I don't see any=
=
>>>> reason
>>>> why they should be selectable.
-- =
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
|
|
|
| Re: Forwarding drag requests to parent [message #134220 is a reply to message #133874] |
Tue, 25 May 2004 20:57 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
"Thomas Maier" <Thomas.Maier@uni-kassel.de> wrote in message
news:40B235CE.1050205@uni-kassel.de...
> Nice pointer, thanks :). Unfortunately GEF seems to mix up, well,
> "click-selection" and "point-the-mouse-at-and-dont't-click-selection".
> The point is that I want to display feedback when the mouse hovers
> above a compartment. I do not want them to be selectable and
> draggable. But I do not get any selection requests when I do what you
> say. I wonder anyway why it seems to be the same to click on
> something and to just point at something. What is the rationale of
> that? And how can I get what I want? Shouldn't GEF send different
> requests?
"selection hover" requests are only sent to selectable editparts. This is
true. But, creation hover, reparent or "add" hover, etc, should work on a
separate targeting request type. So your compartment could be targetable to
these other requests, but not seleciton hover.
If you want selection hover to do something special, have the selectable
editpart receive the "show selection hover" request, but then have it
determine which compartment is under the mouse, and place some convenient
API on the compartment editpart to show the desired feedback. At some point
you have to diverge from base GEF API and just do what is easiest to get the
job done :-)
|
|
|
| Re: Feature Request: new request type [message #134339 is a reply to message #134049] |
Wed, 26 May 2004 06:25 |
Thomas Maier
Messages: 117
Registered: July 2009 |
Senior Member |
|
|
Yes, I still think it could be a useful feature and that it is
missing. I have considered your suggestion to handle it on the Draw2D
side but I have the same bad feeling about it. Maybe this will be my
last resort. But I still hope that one of the GEF gurus reads these
lines and also thinks this feature is missing (flying a big red flag
here :->).
rlemaigr@ulb.ac.be wrote:
> Yes maybe you're right and it is a missing feature I don't know...
> Me too got very confused about the selection tool (and more generally
> by all the tools) because the code is quite hard the understand (I
> always get completely lost in the TargetingTool class and almost all
> the tools are derived from that)...
>
> Anyway the feature seems to be missing in GEF so we have to do
> something else :D
>
> Have you considered what I said at the end of my previous message about
> doing what you want in Draw2d instead of GEF ?
> I meant, adding some mouse listener to the figure of a compartement to
> react on mouse hover event. I think it is possible because before being
> sent to the tool currently active in gef, events get a chance of being
> treated by the draw2d figures themselves. For example I think tooltips
> are display that way (or if it is not, it could be).
>
> That could solve the graphical feedback problem and also the button
> thing (you can call setVisible or setEnable on the button from the
> mouse listener).
>
> For the menu thing, if your menu is built with a ContextMenuProvider
> and Actions (like in the logic example) wich are present in the menu
> iff they are enabled, you could also do this from the mouse listener
> by enableing/disableing some actions and that way modify the content of
> a menu.
> I don't like very much this solution for the menu because it makes the
> figures "intelligent" and this is not their purpose but if it works...
>
> (maybe if we continue to search in circles like this for a long time,
> it will get here the gef gurus and you will got your answer I don't
> know :D)
>
> régis
>
> On Tue, 25 May 2004 08:39:57 +0200, Thomas Maier
> <Thomas.Maier@uni-kassel.de> wrote:
>
>> I do not expect to get a request that wants a command. I do expect
>> that GEF tells me to show selection feedback. It does. But I also
>> expect that GEF tells me "hey, the user is pointing the mouse at your
>> thing, maybe you want to give him some feedback?". Some feedback
>> that does not necessarily mean that the user can click and select
>> it. And I have thought about it. After all I am using the GEF
>> selection tool and I am pointing at my GEF objects in my GEF editor.
>> And I want to be able to react on that. I want my compartments to
>> show a button (that is hidden otherwise) when the mouse is hovering
>> above them that collapses/expands them. Or that pops up a menu with
>> even more commands to manipulate them.
>>
>> Sure, I examined GEF's behaviour based on the current implementation.
>> I would also rather like to rely on specified behaviour. But the
>> documentation is, well, somewhat sparse. So I guess I got confused
>> by the selection tool, got lost in details and abused the selection
>> requests (and mixed things up myself). So what I am actually asking
>> for is a new feature: the selection tool should tell me that the user
>> is pointing the mouse at my objects? Some kind of
>> "pointing-at-requests without caring whether that thing is selectable"?
>>
>> Might somebody pleasy clarify to me what "selection" and "selection
>> hover" means, what it is intended for, how it is currently
>> implemented and if this differs from each other? And how I get what
>> I want to?
>>
>> I think it is like this:
>>
>> Selection requests are sent to my objects so that my objects can
>> display feedback telling the user that he can select the object by
>> clicking the mouse on it. Their way is first getting the target edit
>> part (getTargetEditPart("REQ_SELECTION")) and then calling
>> showTargetFeedback("REQ_SELECTION"). When the user pulls the mouse
>> away from the object, eraseTargetFeedback("REQ_SELECTION") is called.
>>
>> Selction hover requests are kind of the same but allow taking things
>> easy. No hectic flickery but only display feedback when the user
>> settles the mouse on my object.
>>
>> Then I think the "pointing-at-request" and its hover companion are a
>> missing feature. With them I could do like randy said (say my
>> objects aren't selectable) and still react on the user hovering the
>> mouse above my objects. Proper separation of different things. That
>> feels right. Thoughts?
>>
--
Thomas Maier <Thomas.Maier@uni-kassel.de>
|
|
| |
| Re: Feature Request: new request type [message #134635 is a reply to message #134339] |
Thu, 27 May 2004 14:21 |
| Eclipse User |
|
|
|
Originally posted by: rlemaigr.ulb.ac.be
Forget my draw2d idea, it won't work well.
It seems that before giving a mouse event to the active tool, gef looks =
if =
there is a draw2d Figure that could consume it. If there is one, GEF giv=
es =
the mouse event to this Figure, and that's all, the active tool doesn't =
=
get this event. So putting listeners on draw2d figures (in particular if=
=
they are containers) will prevent GEF for getting some interresting even=
ts =
and that will cause problems for sure...
It seems that you're right and this is a missing feature in gef you will=
=
have to implement by yourself...
r=E9gis
On Wed, 26 May 2004 08:25:49 +0200, Thomas Maier =
<Thomas.Maier@uni-kassel.de> wrote:
> Yes, I still think it could be a useful feature and that it is missing=
.. =
> I have considered your suggestion to handle it on the Draw2D side but =
I =
> have the same bad feeling about it. Maybe this will be my last resort=
.. =
> But I still hope that one of the GEF gurus reads these lines and also =
=
> thinks this feature is missing (flying a big red flag here :->).
>
> rlemaigr@ulb.ac.be wrote:
>> Yes maybe you're right and it is a missing feature I don't know...
>> Me too got very confused about the selection tool (and more generally=
=
>> by all the tools) because the code is quite hard the understand (I =
>> always get completely lost in the TargetingTool class and almost all=
=
>> the tools are derived from that)...
>> Anyway the feature seems to be missing in GEF so we have to do =
>> something else :D
>> Have you considered what I said at the end of my previous message =
>> about doing what you want in Draw2d instead of GEF ?
>> I meant, adding some mouse listener to the figure of a compartement t=
o =
>> react on mouse hover event. I think it is possible because before =
>> being sent to the tool currently active in gef, events get a chance =
of =
>> being treated by the draw2d figures themselves. For example I think =
=
>> tooltips are display that way (or if it is not, it could be).
>> That could solve the graphical feedback problem and also the button =
=
>> thing (you can call setVisible or setEnable on the button from the =
>> mouse listener).
>> For the menu thing, if your menu is built with a ContextMenuProvider=
=
>> and Actions (like in the logic example) wich are present in the menu=
=
>> iff they are enabled, you could also do this from the mouse listener=
=
>> by enableing/disableing some actions and that way modify the content=
=
>> of a menu.
>> I don't like very much this solution for the menu because it makes th=
e =
>> figures "intelligent" and this is not their purpose but if it works..=
..
>> (maybe if we continue to search in circles like this for a long time=
, =
>> it will get here the gef gurus and you will got your answer I don't =
=
>> know :D)
>> r=E9gis
>> On Tue, 25 May 2004 08:39:57 +0200, Thomas Maier =
>> <Thomas.Maier@uni-kassel.de> wrote:
>>
>>> I do not expect to get a request that wants a command. I do expect =
=
>>> that GEF tells me to show selection feedback. It does. But I also=
=
>>> expect that GEF tells me "hey, the user is pointing the mouse at yo=
ur =
>>> thing, maybe you want to give him some feedback?". Some feedback =
>>> that does not necessarily mean that the user can click and select =
>>> it. And I have thought about it. After all I am using the GEF =
>>> selection tool and I am pointing at my GEF objects in my GEF editor=
.. =
>>> And I want to be able to react on that. I want my compartments to =
=
>>> show a button (that is hidden otherwise) when the mouse is hovering=
=
>>> above them that collapses/expands them. Or that pops up a menu wit=
h =
>>> even more commands to manipulate them.
>>>
>>> Sure, I examined GEF's behaviour based on the current implementation=
.. =
>>> I would also rather like to rely on specified behaviour. But the =
=
>>> documentation is, well, somewhat sparse. So I guess I got confused =
=
>>> by the selection tool, got lost in details and abused the selection=
=
>>> requests (and mixed things up myself). So what I am actually asking=
=
>>> for is a new feature: the selection tool should tell me that the us=
er =
>>> is pointing the mouse at my objects? Some kind of =
>>> "pointing-at-requests without caring whether that thing is =
>>> selectable"?
>>>
>>> Might somebody pleasy clarify to me what "selection" and "selection =
=
>>> hover" means, what it is intended for, how it is currently =
>>> implemented and if this differs from each other? And how I get wha=
t =
>>> I want to?
>>>
>>> I think it is like this:
>>>
>>> Selection requests are sent to my objects so that my objects can =
>>> display feedback telling the user that he can select the object by =
=
>>> clicking the mouse on it. Their way is first getting the target ed=
it =
>>> part (getTargetEditPart("REQ_SELECTION")) and then calling =
>>> showTargetFeedback("REQ_SELECTION"). When the user pulls the mouse =
=
>>> away from the object, eraseTargetFeedback("REQ_SELECTION") is calle=
d.
>>>
>>> Selction hover requests are kind of the same but allow taking things=
=
>>> easy. No hectic flickery but only display feedback when the user =
>>> settles the mouse on my object.
>>>
>>> Then I think the "pointing-at-request" and its hover companion are a=
=
>>> missing feature. With them I could do like randy said (say my =
>>> objects aren't selectable) and still react on the user hovering the=
=
>>> mouse above my objects. Proper separation of different things. Th=
at =
>>> feels right. Thoughts?
>>>
>
>
-- =
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
|
|
|
| Re: Forwarding drag requests to parent [message #135257 is a reply to message #134351] |
Tue, 01 June 2004 01:12 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
"Thomas Maier" <Thomas.Maier@uni-kassel.de> wrote in message
news:40B43A5F.6060300@uni-kassel.de...
> :-). And that is a pity. Wouldn't you consider those
> "pointing-at-requests" a useful and general feature for GEF to have?
> I think they are missing. Sometimes you just want to display feedback
> that has nothing to do with being selectable or not.
Well, even if something is not selectable, it probably has a parent
somewhere that is. That parent should get selection requests on every mouse
hover, and it could do child routing like this.
The other possibility is the use of draw2d tooltip figures. The down side
is that draw2d tooltips are always active, and don't know about which tool
it active.
> <advertising>Plus it should be very very easy to implement
> them.</advertising> :).
<hint>Then submit the patch in a bugzilla</hint>
>
> Randy Hudson wrote:
> > "selection hover" requests are only sent to selectable editparts. This
is
> > true. But, creation hover, reparent or "add" hover, etc, should work on
a
> > separate targeting request type. So your compartment could be
targetable to
> > these other requests, but not seleciton hover.
> >
> > If you want selection hover to do something special, have the selectable
> > editpart receive the "show selection hover" request, but then have it
> > determine which compartment is under the mouse, and place some
convenient
> > API on the compartment editpart to show the desired feedback. At some
point
> > you have to diverge from base GEF API and just do what is easiest to get
the
> > job done :-)
> >
> >
>
>
> --
> Thomas Maier <Thomas.Maier@uni-kassel.de>
|
|
| |
Goto Forum:
Current Time: Sat Apr 27 05:18:46 GMT 2024
Powered by FUDForum. Page generated in 0.04890 seconds |
] 
Search
Help
Register
Login
Home
