Home » Eclipse Projects » GEF » Complex SnapTo problem
| Complex SnapTo problem [message #165928] |
Thu, 27 January 2005 10:39  |
Eclipse User |
|
|
|
Originally posted by: brett.bock.embarcadero.com
Hello,
I really am amazed at the GEF framework. Every time I need a new capability
it seems to be there. However, there is always the learning curve.
Question 1:
I would like to be able use a SnapToHelper to provide feedback for snapping
certain types of edit parts to certain other types of edit parts, and in
different ways. For example, I have several box like edit part types we'll
call them types A, B and C. When the user moves boxes of type A around on
the diagram I would like the SnapToHelper to snap them to boxes of type B.
However, they should not snap to any other types of boxes, i.e. neither A,
or C. How would I implement this?
Question 2:
Now lets say that when I move type A around I want the center of A to
snap-to the edge of B. How should this be implemented?
Question 3:
Now that the objects have been snapped together, how do I make it so when B
is moved by the user, A also moves?
Thank you,
Brett
|
|
|
| Re: Complex SnapTo problem [message #166011 is a reply to message #165928] |
Thu, 27 January 2005 14:08  |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
"Brett Bock" <brett.bock@embarcadero.com> wrote in message
news:ctb1v8$4a3$1@www.eclipse.org...
> Hello,
>
> I really am amazed at the GEF framework. Every time I need a new
> capability it seems to be there. However, there is always the learning
> curve.
>
> Question 1:
> I would like to be able use a SnapToHelper to provide feedback for
> snapping certain types of edit parts to certain other types of edit parts,
> and in different ways. For example, I have several box like edit part
> types we'll call them types A, B and C. When the user moves boxes of type
> A around on the diagram I would like the SnapToHelper to snap them to
> boxes of type B. However, they should not snap to any other types of
> boxes, i.e. neither A, or C. How would I implement this?
Haven't had this request before. It looks like you could override
generateSnapPartsList to add the types A&C to the list of excluded parts.
Or similarly override populateRowsAndCols to ignore the types. How would you
handle the case when the user has selected two parts, one A and one B?
> Question 2:
> Now lets say that when I move type A around I want the center of A to
> snap-to the edge of B. How should this be implemented?
We don't do this. Centers snap with centers, and edges snap with edges.
You'll get too many matches if you allow everything. But, it looks like you
could override getCorrectionFor(Entry, Map, boolean, double, double), and
call the other getCorrectionFor method where you pass in the middle "edge",
but you lie and say that it is either the LEFT (-1) or RIGHT (1) side.
>
> Question 3:
> Now that the objects have been snapped together, how do I make it so when
> B is moved by the user, A also moves?
The attachment should be represented in your model. Otherwise, you might
get accidental/coincidental attachment. If you have it in the model, the
your editpolicies can do the right thing, such as forwarding source feedback
requests, and smarter commands which move the attached object if it isn't
part of the selection.
> Thank you,
> Brett
>
|
|
|
| Re: Complex SnapTo problem [message #166086 is a reply to message #166011] |
Fri, 28 January 2005 10:09 |
| Eclipse User |
|
|
|
Originally posted by: brett.bock.embarcadero.com
Thank you for your prompt reply. We were already implementing your
suggestions for 1 & 3, so it is good to see we are on the right track. I do
have an additional question WRT to the previous question.
Question 1a:
We are overriding generateSnapPartsList to support this capability. However
in the logic example, different snap helpers are determined by a property on
the diagram edit part in a call to getAdapter(). The difficulty here is that
when the helper is selected there is no information about which edit parts
are selected. How can we ensure that the helper is only used if edit parts
of type A are being moved?
Also, I will be trying your suggestion for 2, and will post the results
here.
Thank you again,
Brett
"Randy Hudson" <none@us.ibm.com> wrote in message
news:ctbe6f$hrg$1@www.eclipse.org...
>
> "Brett Bock" <brett.bock@embarcadero.com> wrote in message
> news:ctb1v8$4a3$1@www.eclipse.org...
>> Hello,
>>
>> I really am amazed at the GEF framework. Every time I need a new
>> capability it seems to be there. However, there is always the learning
>> curve.
>>
>> Question 1:
>> I would like to be able use a SnapToHelper to provide feedback for
>> snapping certain types of edit parts to certain other types of edit
>> parts, and in different ways. For example, I have several box like edit
>> part types we'll call them types A, B and C. When the user moves boxes
>> of type A around on the diagram I would like the SnapToHelper to snap
>> them to boxes of type B. However, they should not snap to any other types
>> of boxes, i.e. neither A, or C. How would I implement this?
>
> Haven't had this request before. It looks like you could override
> generateSnapPartsList to add the types A&C to the list of excluded parts.
> Or similarly override populateRowsAndCols to ignore the types. How would
> you handle the case when the user has selected two parts, one A and one B?
>
>> Question 2:
>> Now lets say that when I move type A around I want the center of A to
>> snap-to the edge of B. How should this be implemented?
>
> We don't do this. Centers snap with centers, and edges snap with edges.
> You'll get too many matches if you allow everything. But, it looks like
> you could override getCorrectionFor(Entry, Map, boolean, double, double),
> and call the other getCorrectionFor method where you pass in the middle
> "edge", but you lie and say that it is either the LEFT (-1) or RIGHT (1)
> side.
>
>>
>> Question 3:
>> Now that the objects have been snapped together, how do I make it so when
>> B is moved by the user, A also moves?
>
> The attachment should be represented in your model. Otherwise, you might
> get accidental/coincidental attachment. If you have it in the model, the
> your editpolicies can do the right thing, such as forwarding source
> feedback requests, and smarter commands which move the attached object if
> it isn't part of the selection.
>
>> Thank you,
>> Brett
>>
>
>
|
|
|
| Re: Complex SnapTo problem [message #166109 is a reply to message #166086] |
Fri, 28 January 2005 11:33 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
> We are overriding generateSnapPartsList to support this capability.
> However in the logic example, different snap helpers are determined by a
> property on the diagram edit part in a call to getAdapter(). The
> difficulty here is that when the helper is selected there is no
> information about which edit parts are selected. How can we ensure that
> the helper is only used if edit parts of type A are being moved?
Perhaps the receiver has access to the viewer and can just look at the
viewer's selection.
>
> Also, I will be trying your suggestion for 2, and will post the results
> here.
>
> Thank you again,
>
> Brett
>
> "Randy Hudson" <none@us.ibm.com> wrote in message
> news:ctbe6f$hrg$1@www.eclipse.org...
>>
>> "Brett Bock" <brett.bock@embarcadero.com> wrote in message
>> news:ctb1v8$4a3$1@www.eclipse.org...
>>> Hello,
>>>
>>> I really am amazed at the GEF framework. Every time I need a new
>>> capability it seems to be there. However, there is always the learning
>>> curve.
>>>
>>> Question 1:
>>> I would like to be able use a SnapToHelper to provide feedback for
>>> snapping certain types of edit parts to certain other types of edit
>>> parts, and in different ways. For example, I have several box like edit
>>> part types we'll call them types A, B and C. When the user moves boxes
>>> of type A around on the diagram I would like the SnapToHelper to snap
>>> them to boxes of type B. However, they should not snap to any other
>>> types of boxes, i.e. neither A, or C. How would I implement this?
>>
>> Haven't had this request before. It looks like you could override
>> generateSnapPartsList to add the types A&C to the list of excluded parts.
>> Or similarly override populateRowsAndCols to ignore the types. How would
>> you handle the case when the user has selected two parts, one A and one
>> B?
>>
>>> Question 2:
>>> Now lets say that when I move type A around I want the center of A to
>>> snap-to the edge of B. How should this be implemented?
>>
>> We don't do this. Centers snap with centers, and edges snap with edges.
>> You'll get too many matches if you allow everything. But, it looks like
>> you could override getCorrectionFor(Entry, Map, boolean, double, double),
>> and call the other getCorrectionFor method where you pass in the middle
>> "edge", but you lie and say that it is either the LEFT (-1) or RIGHT (1)
>> side.
>>
>>>
>>> Question 3:
>>> Now that the objects have been snapped together, how do I make it so
>>> when B is moved by the user, A also moves?
>>
>> The attachment should be represented in your model. Otherwise, you might
>> get accidental/coincidental attachment. If you have it in the model, the
>> your editpolicies can do the right thing, such as forwarding source
>> feedback requests, and smarter commands which move the attached object if
>> it isn't part of the selection.
>>
>>> Thank you,
>>> Brett
>>>
>>
>>
>
>
|
|
|
Goto Forum:
Current Time: Thu May 08 01:14:53 EDT 2025
Powered by FUDForum. Page generated in 0.02997 seconds |
Home