Home » Eclipse Projects » GEF » Polygon has an empty Figure#primTranslate(int dx, int dy)
|
| Re: Polygon has an empty Figure#primTranslate(int dx, int dy) [message #135483 is a reply to message #135469] |
Tue, 01 June 2004 19:34   |
Eclipse User |
|
|
|
Originally posted by: rlemaigr.ulb.ac.be
About the setbounds method of Polyline:
One of the reasons the bounds are always something very fuzzy in my mind=
=
is the difference between the way the bounds are used in, say, a =
RectangleFigure or a Label, and the way they are used in a Polyline:
- in a Label or a RectangleFigure, they seem to be used to give a locati=
on =
and a size to the figure. The paintFigure method is based on the bounds =
to =
fill them with the content to display in the Figure. So: first you set t=
he =
bounds, and then the content to display is painted to fill them at best =
=
automatically.
- in a Polyline this is exactly the inverse situation. You adjust the =
content to display by setting the position of the points (and the =
children?), and the getBounds() method calculate the bounds based on tha=
t =
content to display. So: first you set the content to display, and then t=
he =
bounds are calculated to be the smallest rectangle which contains all th=
e =
points of the polyline (and also the children?).
So now you can understand why the setbounds method does not work properl=
y =
on a polyline: as the bounds of a Polyline are automaticaly calculated =
when they are needed by the painting algorithm (based on the location of=
=
the points (and the children?) of the polyline), you can't set them =
yourself by calling setBounds() ! I don't know the behaviour of the =
polyline if you call this method but I wouldn't try to do it.
Now about the primtranslate method, I asked myself the same question as =
=
you: why doesn't this method do something like that
protected void primtranslate(int x, int y)
{
getPoints().translate(x,y);
for(all the children figures)
child.primTranslate(x,y);
}
in order to translate the polyline and its children when its parent is =
moved ??
I am not sure about that. Here is my own explanation but it is not =
completely satisfying so you will have to wait for a better answer.
I think this was made like that because Polyline is the base for the =
implementation of the Connection interface with the class =
PolylineConnection.
A polyline connection is something that connects two figures and =
automaticaly adjust itself when these two figures are moved (or at least=
=
it is its purpose). To adjust itself, it makes use of a connection route=
r =
(for laying out the intermidiate points) and two connection anchors (for=
=
specifying the location of the endpoints). His default layout is =
DelegatingLayout so its children also adjust their locations and sizes =
themselves when the anchors of the connection are moved and the connecti=
on =
is relayed out.
Keeping that in mind, you will understand why the primTranslate() method=
=
is redifined to do nothing. What triggers a change in the location of th=
e =
points of a polyline connection is a change of the position of its ancho=
rs =
(its endpoints), not a change in the position of its parent. So there is=
=
no reason to translate a polyline connection when its parent moves.
But assuming that, they should have override this method in the =
PolylineConnection class and not in the Polyline class. That I don't =
understand. That's why my explanation is probably wrong :S .
[[ Maybe you will find that funny but I have never properly understood =
what the bounds of a figure exactly are. I wonder if I am alone in this =
=
situation. In my mind it is misty. The javadoc says it has to be the =
smallest rectangle which contains all the graphical elements introduced =
by =
a Figure, but whatever the way I turn this in my mind it always seems =
there is something that I missed and I am not satisfied.
Here is what I understand about the bounds:
The purpose of the bounds are not only positionning a figure, it is also=
=
to limit the space where a figure can introduce its paintings and the =
paintings of its children. Draw2d doesn't allow a figure and its childre=
n =
to paint outside of its bounds. So before draw2d enters the paint method=
=
of a Figure, it reduces the clipping area of the Graphics object to the =
=
intersection of the current clipping area and the bounds of the figure t=
o =
paint (+-). If the clipping area is empty, the Figure is not painted. Th=
at =
will more likely happen if the bounds are small. So for efficiency, you =
=
have to set the bounds to the SMALLEST rectangle that is acceptable.
If there was no such a limitation of the space occupied by a Figure, eac=
h =
time you'd want to repaint a small piece of the ui, you would have to =
repaint the all tree of figures because each of them would be likely to =
=
introduce some painting in the small piece of the ui to repaint ! So I =
think using correctly the bounds to limit the space available for a figu=
re =
to paint allows some VERY BIG improvements of the repainting algorithm. =
]]
r=E9gis
You can't set the bounds of a Polyline as you set the bounds of another =
=
figure.
On Tue, 1 Jun 2004 22:49:16 +0200, Jose M Beleta <beleta@attglobal.net> =
=
wrote:
> What's the reason for Polygon (Polyline) to have an empty =
> primTranslate(int
> dx, int dy) method . Because that setBounds does not work as expected.=
>
> Jose M beleta
>
>
-- =
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
|
|
|
| Re: Polygon has an empty Figure#primTranslate(int dx, int dy) [message #135508 is a reply to message #135483] |
Tue, 01 June 2004 20:43 |
| Eclipse User |
|
|
|
Originally posted by: rlemaigr.ulb.ac.be
Maybe you already knew the 95/100 of what I said...if it is the case and=
=
that made you feel like I took you for an idiot, I'm sorry this was not =
on =
purpose...there is no way to guess the level of knowledge of somebody =
here...
In addition to that maybe some things I said was wrong
r=E9gis
On Wed, 02 Jun 2004 01:34:41 +0200, <rlemaigr@ulb.ac.be> wrote:
> About the setbounds method of Polyline:
>
> One of the reasons the bounds are always something very fuzzy in my mi=
nd =
> is the difference between the way the bounds are used in, say, a =
> RectangleFigure or a Label, and the way they are used in a Polyline:
> - in a Label or a RectangleFigure, they seem to be used to give a =
> location and a size to the figure. The paintFigure method is based on =
=
> the bounds to fill them with the content to display in the Figure. So:=
=
> first you set the bounds, and then the content to display is painted t=
o =
> fill them at best automatically.
> - in a Polyline this is exactly the inverse situation. You adjust the =
=
> content to display by setting the position of the points (and the =
> children?), and the getBounds() method calculate the bounds based on =
> that content to display. So: first you set the content to display, and=
=
> then the bounds are calculated to be the smallest rectangle which =
> contains all the points of the polyline (and also the children?).
>
> So now you can understand why the setbounds method does not work =
> properly on a polyline: as the bounds of a Polyline are automaticaly =
> calculated when they are needed by the painting algorithm (based on th=
e =
> location of the points (and the children?) of the polyline), you can't=
=
> set them yourself by calling setBounds() ! I don't know the behaviour =
of =
> the polyline if you call this method but I wouldn't try to do it.
>
>
> Now about the primtranslate method, I asked myself the same question a=
s =
> you: why doesn't this method do something like that
> protected void primtranslate(int x, int y)
> {
> getPoints().translate(x,y);
> for(all the children figures)
> child.primTranslate(x,y);
> }
> in order to translate the polyline and its children when its parent is=
=
> moved ??
>
> I am not sure about that. Here is my own explanation but it is not =
> completely satisfying so you will have to wait for a better answer.
>
> I think this was made like that because Polyline is the base for the =
> implementation of the Connection interface with the class =
> PolylineConnection.
> A polyline connection is something that connects two figures and =
> automaticaly adjust itself when these two figures are moved (or at lea=
st =
> it is its purpose). To adjust itself, it makes use of a connection =
> router (for laying out the intermidiate points) and two connection =
> anchors (for specifying the location of the endpoints). His default =
> layout is DelegatingLayout so its children also adjust their locations=
=
> and sizes themselves when the anchors of the connection are moved and =
=
> the connection is relayed out.
>
> Keeping that in mind, you will understand why the primTranslate() meth=
od =
> is redifined to do nothing. What triggers a change in the location of =
=
> the points of a polyline connection is a change of the position of its=
=
> anchors (its endpoints), not a change in the position of its parent. S=
o =
> there is no reason to translate a polyline connection when its parent =
=
> moves.
>
> But assuming that, they should have override this method in the =
> PolylineConnection class and not in the Polyline class. That I don't =
> understand. That's why my explanation is probably wrong :S .
>
>
> [[ Maybe you will find that funny but I have never properly understood=
=
> what the bounds of a figure exactly are. I wonder if I am alone in thi=
s =
> situation. In my mind it is misty. The javadoc says it has to be the =
> smallest rectangle which contains all the graphical elements introduce=
d =
> by a Figure, but whatever the way I turn this in my mind it always see=
ms =
> there is something that I missed and I am not satisfied.
>
> Here is what I understand about the bounds:
> The purpose of the bounds are not only positionning a figure, it is al=
so =
> to limit the space where a figure can introduce its paintings and the =
=
> paintings of its children. Draw2d doesn't allow a figure and its =
> children to paint outside of its bounds. So before draw2d enters the =
> paint method of a Figure, it reduces the clipping area of the Graphics=
=
> object to the intersection of the current clipping area and the bounds=
=
> of the figure to paint (+-). If the clipping area is empty, the Figure=
=
> is not painted. That will more likely happen if the bounds are small. =
So =
> for efficiency, you have to set the bounds to the SMALLEST rectangle =
> that is acceptable.
> If there was no such a limitation of the space occupied by a Figure, =
> each time you'd want to repaint a small piece of the ui, you would hav=
e =
> to repaint the all tree of figures because each of them would be likel=
y =
> to introduce some painting in the small piece of the ui to repaint ! S=
o =
> I think using correctly the bounds to limit the space available for a =
=
> figure to paint allows some VERY BIG improvements of the repainting =
> algorithm. ]]
>
> r=E9gis
>
>
>
>
>
> You can't set the bounds of a Polyline as you set the bounds of anothe=
r =
> figure.
>
> On Tue, 1 Jun 2004 22:49:16 +0200, Jose M Beleta <beleta@attglobal.net=
> =
> wrote:
>
>> What's the reason for Polygon (Polyline) to have an empty =
>> primTranslate(int
>> dx, int dy) method . Because that setBounds does not work as expected=
..
>>
>> Jose M beleta
>>
>>
>
>
>
-- =
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
|
|
|
| Re: Polygon has an empty Figure#primTranslate(int dx, int dy) [message #135519 is a reply to message #135483] |
Tue, 01 June 2004 23:04 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
This is a good summary. I am not sure why primtranslate does nothing. I
think there is some history there. It probably goes back to some sort of
optimization of avoiding unnecessary notification (at one point translate
and primTranslate were not split into two method), or maybe it was to
prevent people from thinking they could call setBounds().
It probably doesn't affect most users since the default viewport uses its
own coordinate system to implement scrolling, rather than translating its
contents. It could be changed, but I think it is too risky for 3.0 and it
is simple to workaround if it is needed. Please add the use case to the
bugzilla.
<rlemaigr@ulb.ac.be> wrote in message
news:opr8xvr3sqxn9g2u@xn--pcrgis-dva.mshome.net...
About the setbounds method of Polyline:
One of the reasons the bounds are always something very fuzzy in my mind
is the difference between the way the bounds are used in, say, a
RectangleFigure or a Label, and the way they are used in a Polyline:
- in a Label or a RectangleFigure, they seem to be used to give a location
and a size to the figure. The paintFigure method is based on the bounds to
fill them with the content to display in the Figure. So: first you set the
bounds, and then the content to display is painted to fill them at best
automatically.
- in a Polyline this is exactly the inverse situation. You adjust the
content to display by setting the position of the points (and the
children?), and the getBounds() method calculate the bounds based on that
content to display. So: first you set the content to display, and then the
bounds are calculated to be the smallest rectangle which contains all the
points of the polyline (and also the children?).
So now you can understand why the setbounds method does not work properly
on a polyline: as the bounds of a Polyline are automaticaly calculated
when they are needed by the painting algorithm (based on the location of
the points (and the children?) of the polyline), you can't set them
yourself by calling setBounds() ! I don't know the behaviour of the
polyline if you call this method but I wouldn't try to do it.
Now about the primtranslate method, I asked myself the same question as
you: why doesn't this method do something like that
protected void primtranslate(int x, int y)
{
getPoints().translate(x,y);
for(all the children figures)
child.primTranslate(x,y);
}
in order to translate the polyline and its children when its parent is
moved ??
I am not sure about that. Here is my own explanation but it is not
completely satisfying so you will have to wait for a better answer.
I think this was made like that because Polyline is the base for the
implementation of the Connection interface with the class
PolylineConnection.
A polyline connection is something that connects two figures and
automaticaly adjust itself when these two figures are moved (or at least
it is its purpose). To adjust itself, it makes use of a connection router
(for laying out the intermidiate points) and two connection anchors (for
specifying the location of the endpoints). His default layout is
DelegatingLayout so its children also adjust their locations and sizes
themselves when the anchors of the connection are moved and the connection
is relayed out.
Keeping that in mind, you will understand why the primTranslate() method
is redifined to do nothing. What triggers a change in the location of the
points of a polyline connection is a change of the position of its anchors
(its endpoints), not a change in the position of its parent. So there is
no reason to translate a polyline connection when its parent moves.
But assuming that, they should have override this method in the
PolylineConnection class and not in the Polyline class. That I don't
understand. That's why my explanation is probably wrong :S .
[[ Maybe you will find that funny but I have never properly understood
what the bounds of a figure exactly are. I wonder if I am alone in this
situation. In my mind it is misty. The javadoc says it has to be the
smallest rectangle which contains all the graphical elements introduced by
a Figure, but whatever the way I turn this in my mind it always seems
there is something that I missed and I am not satisfied.
Here is what I understand about the bounds:
The purpose of the bounds are not only positionning a figure, it is also
to limit the space where a figure can introduce its paintings and the
paintings of its children. Draw2d doesn't allow a figure and its children
to paint outside of its bounds. So before draw2d enters the paint method
of a Figure, it reduces the clipping area of the Graphics object to the
intersection of the current clipping area and the bounds of the figure to
paint (+-). If the clipping area is empty, the Figure is not painted. That
will more likely happen if the bounds are small. So for efficiency, you
have to set the bounds to the SMALLEST rectangle that is acceptable.
If there was no such a limitation of the space occupied by a Figure, each
time you'd want to repaint a small piece of the ui, you would have to
repaint the all tree of figures because each of them would be likely to
introduce some painting in the small piece of the ui to repaint ! So I
think using correctly the bounds to limit the space available for a figure
to paint allows some VERY BIG improvements of the repainting algorithm. ]]
r
|
|
| |
| Re: Polygon has an empty Figure#primTranslate(int dx, int dy) [message #135572 is a reply to message #135558] |
Wed, 02 June 2004 09:43 |
| Eclipse User |
|
|
|
Originally posted by: rlemaigr.ulb.ac.be
I agree with you.
I work on a project for the last year of my studies and I have to use ge=
f, =
draw2d and eclipse (I didn't even know that these 3 things existed =
before). So in september, I reserved between two weeks and one month for=
=
learning the very bases of gef, draw2d and eclipse and getting started. =
=
Instead of two weeks, it took me 5 months of code reading ! (but I must =
=
admit I am a perfectionist and very slow to learn)
I was using Swing before. I think I never had to open a single source fi=
le =
of Swing. So the shock was quite hard !
It seems like the developpers of some parts of eclipse are only focused =
on =
their work (and they DO very good work!) and doesn't really care about t=
he =
users of their work. I don't understand why. I think a good documentatio=
n =
(not only javadoc! but tutorials, examples of increasing complexity, =
"howtos", good faqs,..) for an API is the key for baiting people...peopl=
e =
don't want to spend 6 months to read the sources files...What's the =
purpose of a very very good API that nobody uses at 100% of its =
possibilities because nobody except its devellopers can understand it we=
ll =
?
I hope this will get better in the future.
(I know I sound very pessimistic here, I don't want to offend develloper=
s =
or people working on that, this is just how I feel it)
r=E9gis
On Wed, 2 Jun 2004 10:04:42 +0200, Jose M Beleta <beleta@attglobal.net> =
=
wrote:
> R=E9gis:
>
> Thanks a lot for your explanation, it does not matter if I knew 95% or=
=
> 10%
> of what you say, your explanation, as Randy says, is really good and h=
as
> enlightened me a lot.
>
> But the main reason of my question is to complain about the only thing=
=
> that
> I do not like in GEF and Draw2d and the whole Eclipse. All them are =
> really
> great products but they are very difficult to use just reading the doc=
s =
> and
> without looking at the code. Lacks of homogeneity, as in the case we a=
re
> talking about here, are only discovered after digging into the code. I=
t
> seems that all them are made "ad hoc" to resolve particular problems a=
nd =
> are
> not designed to be used for people not in the "business".
>
> I do not need to go the source code for using Sun's Java libraries, wh=
y I
> need to do so whe using all the Eclipse APIs?
>
> But perhaps this is one of the dangers of opensource.
>
> Regards, and thanks again.
>
> Jose M Beleta
>
> <rlemaigr@ulb.ac.be> escribi=F3 en el mensaje
> news:opr8xyyzrfxn9g2u@xn--pcrgis-dva.mshome.net...
> Maybe you already knew the 95/100 of what I said...if it is the case a=
nd
> that made you feel like I took you for an idiot, I'm sorry this was no=
t =
> on
> purpose...there is no way to guess the level of knowledge of somebody
> here...
> In addition to that maybe some things I said was wrong
>
> r=E9gis
>
>
> On Wed, 02 Jun 2004 01:34:41 +0200, <rlemaigr@ulb.ac.be> wrote:
>
>> About the setbounds method of Polyline:
>>
>> One of the reasons the bounds are always something very fuzzy in my m=
ind
>> is the difference between the way the bounds are used in, say, a
>> RectangleFigure or a Label, and the way they are used in a Polyline:
>> - in a Label or a RectangleFigure, they seem to be used to give a
>> location and a size to the figure. The paintFigure method is based on=
>> the bounds to fill them with the content to display in the Figure. So=
:
>> first you set the bounds, and then the content to display is painted =
to
>> fill them at best automatically.
>> - in a Polyline this is exactly the inverse situation. You adjust the=
>> content to display by setting the position of the points (and the
>> children?), and the getBounds() method calculate the bounds based on
>> that content to display. So: first you set the content to display, an=
d
>> then the bounds are calculated to be the smallest rectangle which
>> contains all the points of the polyline (and also the children?).
>>
>> So now you can understand why the setbounds method does not work
>> properly on a polyline: as the bounds of a Polyline are automaticaly
>> calculated when they are needed by the painting algorithm (based on t=
he
>> location of the points (and the children?) of the polyline), you can'=
t
>> set them yourself by calling setBounds() ! I don't know the behaviour=
of
>> the polyline if you call this method but I wouldn't try to do it.
>>
>>
>> Now about the primtranslate method, I asked myself the same question =
as
>> you: why doesn't this method do something like that
>> protected void primtranslate(int x, int y)
>> {
>> getPoints().translate(x,y);
>> for(all the children figures)
>> child.primTranslate(x,y);
>> }
>> in order to translate the polyline and its children when its parent i=
s
>> moved ??
>>
>> I am not sure about that. Here is my own explanation but it is not
>> completely satisfying so you will have to wait for a better answer.
>>
>> I think this was made like that because Polyline is the base for the
>> implementation of the Connection interface with the class
>> PolylineConnection.
>> A polyline connection is something that connects two figures and
>> automaticaly adjust itself when these two figures are moved (or at le=
ast
>> it is its purpose). To adjust itself, it makes use of a connection
>> router (for laying out the intermidiate points) and two connection
>> anchors (for specifying the location of the endpoints). His default
>> layout is DelegatingLayout so its children also adjust their location=
s
>> and sizes themselves when the anchors of the connection are moved and=
>> the connection is relayed out.
>>
>> Keeping that in mind, you will understand why the primTranslate() met=
hod
>> is redifined to do nothing. What triggers a change in the location of=
>> the points of a polyline connection is a change of the position of it=
s
>> anchors (its endpoints), not a change in the position of its parent. =
So
>> there is no reason to translate a polyline connection when its parent=
>> moves.
>>
>> But assuming that, they should have override this method in the
>> PolylineConnection class and not in the Polyline class. That I don't
>> understand. That's why my explanation is probably wrong :S .
>>
>>
>> [[ Maybe you will find that funny but I have never properly understoo=
d
>> what the bounds of a figure exactly are. I wonder if I am alone in th=
is
>> situation. In my mind it is misty. The javadoc says it has to be the
>> smallest rectangle which contains all the graphical elements introduc=
ed
>> by a Figure, but whatever the way I turn this in my mind it always se=
ems
>> there is something that I missed and I am not satisfied.
>>
>> Here is what I understand about the bounds:
>> The purpose of the bounds are not only positionning a figure, it is a=
lso
>> to limit the space where a figure can introduce its paintings and the=
>> paintings of its children. Draw2d doesn't allow a figure and its
>> children to paint outside of its bounds. So before draw2d enters the
>> paint method of a Figure, it reduces the clipping area of the Graphic=
s
>> object to the intersection of the current clipping area and the bound=
s
>> of the figure to paint (+-). If the clipping area is empty, the Figur=
e
>> is not painted. That will more likely happen if the bounds are small.=
So
>> for efficiency, you have to set the bounds to the SMALLEST rectangle
>> that is acceptable.
>> If there was no such a limitation of the space occupied by a Figure,
>> each time you'd want to repaint a small piece of the ui, you would ha=
ve
>> to repaint the all tree of figures because each of them would be like=
ly
>> to introduce some painting in the small piece of the ui to repaint ! =
So
>> I think using correctly the bounds to limit the space available for a=
>> figure to paint allows some VERY BIG improvements of the repainting
>> algorithm. ]]
>>
>> r=E9gis
>>
>>
>>
>>
>>
>> You can't set the bounds of a Polyline as you set the bounds of anoth=
er
>> figure.
>>
>> On Tue, 1 Jun 2004 22:49:16 +0200, Jose M Beleta <beleta@attglobal.ne=
t>
>> wrote:
>>
>>> What's the reason for Polygon (Polyline) to have an empty
>>> primTranslate(int
>>> dx, int dy) method . Because that setBounds does not work as expecte=
d.
>>>
>>> Jose M beleta
>>>
>>>
>>
>>
>>
>
>
>
-- =
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
|
|
|
| Re: Polygon has an empty Figure#primTranslate(int dx, int dy) [message #135597 is a reply to message #135519] |
Wed, 02 June 2004 10:02 |
| Eclipse User |
|
|
|
Originally posted by: rlemaigr.ulb.ac.be
I am sorry but I have no idea of a use case where this functionnality =
would be really needed and useful.
Maybe Jose has an idea about that and could do it ?
r=E9gis
On Tue, 1 Jun 2004 23:04:47 -0400, Randy Hudson <none@us.ibm.com> wrote:=
> This is a good summary. I am not sure why primtranslate does nothing.=
I
> think there is some history there. It probably goes back to some sort=
of
> optimization of avoiding unnecessary notification (at one point transl=
ate
> and primTranslate were not split into two method), or maybe it was to
> prevent people from thinking they could call setBounds().
>
> It probably doesn't affect most users since the default viewport uses =
its
> own coordinate system to implement scrolling, rather than translating =
its
> contents. It could be changed, but I think it is too risky for 3.0 an=
d =
> it
> is simple to workaround if it is needed. Please add the use case to t=
he
> bugzilla.
>
> <rlemaigr@ulb.ac.be> wrote in message
> news:opr8xvr3sqxn9g2u@xn--pcrgis-dva.mshome.net...
> About the setbounds method of Polyline:
>
> One of the reasons the bounds are always something very fuzzy in my mi=
nd
> is the difference between the way the bounds are used in, say, a
> RectangleFigure or a Label, and the way they are used in a Polyline:
> - in a Label or a RectangleFigure, they seem to be used to give a =
> location
> and a size to the figure. The paintFigure method is based on the bound=
s =
> to
> fill them with the content to display in the Figure. So: first you set=
=
> the
> bounds, and then the content to display is painted to fill them at bes=
t
> automatically.
> - in a Polyline this is exactly the inverse situation. You adjust the
> content to display by setting the position of the points (and the
> children?), and the getBounds() method calculate the bounds based on t=
hat
> content to display. So: first you set the content to display, and then=
=
> the
> bounds are calculated to be the smallest rectangle which contains all =
the
> points of the polyline (and also the children?).
>
> So now you can understand why the setbounds method does not work prope=
rly
> on a polyline: as the bounds of a Polyline are automaticaly calculated=
> when they are needed by the painting algorithm (based on the location =
of
> the points (and the children?) of the polyline), you can't set them
> yourself by calling setBounds() ! I don't know the behaviour of the
> polyline if you call this method but I wouldn't try to do it.
>
>
> Now about the primtranslate method, I asked myself the same question a=
s
> you: why doesn't this method do something like that
> protected void primtranslate(int x, int y)
> {
> getPoints().translate(x,y);
> for(all the children figures)
> child.primTranslate(x,y);
> }
> in order to translate the polyline and its children when its parent is=
> moved ??
>
> I am not sure about that. Here is my own explanation but it is not
> completely satisfying so you will have to wait for a better answer.
>
> I think this was made like that because Polyline is the base for the
> implementation of the Connection interface with the class
> PolylineConnection.
> A polyline connection is something that connects two figures and
> automaticaly adjust itself when these two figures are moved (or at lea=
st
> it is its purpose). To adjust itself, it makes use of a connection rou=
ter
> (for laying out the intermidiate points) and two connection anchors (f=
or
> specifying the location of the endpoints). His default layout is
> DelegatingLayout so its children also adjust their locations and sizes=
> themselves when the anchors of the connection are moved and the =
> connection
> is relayed out.
>
> Keeping that in mind, you will understand why the primTranslate() meth=
od
> is redifined to do nothing. What triggers a change in the location of =
the
> points of a polyline connection is a change of the position of its =
> anchors
> (its endpoints), not a change in the position of its parent. So there =
is
> no reason to translate a polyline connection when its parent moves.
>
> But assuming that, they should have override this method in the
> PolylineConnection class and not in the Polyline class. That I don't
> understand. That's why my explanation is probably wrong :S .
>
>
> [[ Maybe you will find that funny but I have never properly understood=
> what the bounds of a figure exactly are. I wonder if I am alone in thi=
s
> situation. In my mind it is misty. The javadoc says it has to be the
> smallest rectangle which contains all the graphical elements introduce=
d =
> by
> a Figure, but whatever the way I turn this in my mind it always seems
> there is something that I missed and I am not satisfied.
>
> Here is what I understand about the bounds:
> The purpose of the bounds are not only positionning a figure, it is al=
so
> to limit the space where a figure can introduce its paintings and the
> paintings of its children. Draw2d doesn't allow a figure and its child=
ren
> to paint outside of its bounds. So before draw2d enters the paint meth=
od
> of a Figure, it reduces the clipping area of the Graphics object to th=
e
> intersection of the current clipping area and the bounds of the figure=
to
> paint (+-). If the clipping area is empty, the Figure is not painted. =
=
> That
> will more likely happen if the bounds are small. So for efficiency, yo=
u
> have to set the bounds to the SMALLEST rectangle that is acceptable.
> If there was no such a limitation of the space occupied by a Figure, e=
ach
> time you'd want to repaint a small piece of the ui, you would have to
> repaint the all tree of figures because each of them would be likely t=
o
> introduce some painting in the small piece of the ui to repaint ! So I=
> think using correctly the bounds to limit the space available for a =
> figure
> to paint allows some VERY BIG improvements of the repainting algorithm=
.. =
> ]]
>
> r=E9gis
>
>
>
>
>
> You can't set the bounds of a Polyline as you set the bounds of anothe=
r
> figure.
>
> On Tue, 1 Jun 2004 22:49:16 +0200, Jose M Beleta <beleta@attglobal.net=
>
> wrote:
>
>> What's the reason for Polygon (Polyline) to have an empty
>> primTranslate(int
>> dx, int dy) method . Because that setBounds does not work as expected=
..
>>
>> Jose M beleta
>>
>>
>
>
>
-- =
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
|
|
| |
| Re: Polygon has an empty Figure#primTranslate(int dx, int dy) [message #135685 is a reply to message #135646] |
Wed, 02 June 2004 11:14 |
| Eclipse User |
|
|
|
Originally posted by: rlemaigr.ulb.ac.be
Ok, that I have understood, for some reason you needed a method to =
translate a figure without fireing a move event to avoid useless =
notifications in some cases.
But what I don't understand is just what did you mean by "Please add the=
=
use case to the bugzilla" ? Which use case ? Do you mean, reporting a ne=
w =
"bug" and asking why exactly the method primtranslate does nothing in =
polyline ? (yes I am slow sometimes I know :D )
r=E9gis
On Wed, 2 Jun 2004 10:23:37 -0400, Randy Hudson <none@us.ibm.com> wrote:=
> Well, as I said at avoid fireFigureMoved(). Handles are listeners of =
=
> this
> notification. I'm not arguing, just trying to guess why we made this
> brilliant optimization :-).
>
> <rlemaigr@ulb.ac.be> wrote in message
> news:opr8yzycn5xn9g2u@xn--pcrgis-dva.mshome.net...
> I am sorry but I have no idea of a use case where this functionnality
> would be really needed and useful.
>
> Maybe Jose has an idea about that and could do it ?
>
> r=E9gis
>
>
> On Tue, 1 Jun 2004 23:04:47 -0400, Randy Hudson <none@us.ibm.com> wrot=
e:
>
>> This is a good summary. I am not sure why primtranslate does nothing=
.. =
>> I
>> think there is some history there. It probably goes back to some sor=
t =
>> of
>> optimization of avoiding unnecessary notification (at one point =
>> translate
>> and primTranslate were not split into two method), or maybe it was to=
>> prevent people from thinking they could call setBounds().
>>
>> It probably doesn't affect most users since the default viewport uses=
=
>> its
>> own coordinate system to implement scrolling, rather than translating=
=
>> its
>> contents. It could be changed, but I think it is too risky for 3.0 a=
nd
>> it
>> is simple to workaround if it is needed. Please add the use case to =
the
>> bugzilla.
>>
>> <rlemaigr@ulb.ac.be> wrote in message
>> news:opr8xvr3sqxn9g2u@xn--pcrgis-dva.mshome.net...
>> About the setbounds method of Polyline:
>>
>> One of the reasons the bounds are always something very fuzzy in my m=
ind
>> is the difference between the way the bounds are used in, say, a
>> RectangleFigure or a Label, and the way they are used in a Polyline:
>> - in a Label or a RectangleFigure, they seem to be used to give a
>> location
>> and a size to the figure. The paintFigure method is based on the boun=
ds
>> to
>> fill them with the content to display in the Figure. So: first you se=
t
>> the
>> bounds, and then the content to display is painted to fill them at be=
st
>> automatically.
>> - in a Polyline this is exactly the inverse situation. You adjust the=
>> content to display by setting the position of the points (and the
>> children?), and the getBounds() method calculate the bounds based on =
=
>> that
>> content to display. So: first you set the content to display, and the=
n
>> the
>> bounds are calculated to be the smallest rectangle which contains all=
=
>> the
>> points of the polyline (and also the children?).
>>
>> So now you can understand why the setbounds method does not work =
>> properly
>> on a polyline: as the bounds of a Polyline are automaticaly calculate=
d
>> when they are needed by the painting algorithm (based on the location=
of
>> the points (and the children?) of the polyline), you can't set them
>> yourself by calling setBounds() ! I don't know the behaviour of the
>> polyline if you call this method but I wouldn't try to do it.
>>
>>
>> Now about the primtranslate method, I asked myself the same question =
as
>> you: why doesn't this method do something like that
>> protected void primtranslate(int x, int y)
>> {
>> getPoints().translate(x,y);
>> for(all the children figures)
>> child.primTranslate(x,y);
>> }
>> in order to translate the polyline and its children when its parent i=
s
>> moved ??
>>
>> I am not sure about that. Here is my own explanation but it is not
>> completely satisfying so you will have to wait for a better answer.
>>
>> I think this was made like that because Polyline is the base for the
>> implementation of the Connection interface with the class
>> PolylineConnection.
>> A polyline connection is something that connects two figures and
>> automaticaly adjust itself when these two figures are moved (or at le=
ast
>> it is its purpose). To adjust itself, it makes use of a connection =
>> router
>> (for laying out the intermidiate points) and two connection anchors (=
for
>> specifying the location of the endpoints). His default layout is
>> DelegatingLayout so its children also adjust their locations and size=
s
>> themselves when the anchors of the connection are moved and the
>> connection
>> is relayed out.
>>
>> Keeping that in mind, you will understand why the primTranslate() met=
hod
>> is redifined to do nothing. What triggers a change in the location of=
=
>> the
>> points of a polyline connection is a change of the position of its
>> anchors
>> (its endpoints), not a change in the position of its parent. So there=
is
>> no reason to translate a polyline connection when its parent moves.
>>
>> But assuming that, they should have override this method in the
>> PolylineConnection class and not in the Polyline class. That I don't
>> understand. That's why my explanation is probably wrong :S .
>>
>>
>> [[ Maybe you will find that funny but I have never properly understoo=
d
>> what the bounds of a figure exactly are. I wonder if I am alone in th=
is
>> situation. In my mind it is misty. The javadoc says it has to be the
>> smallest rectangle which contains all the graphical elements introduc=
ed
>> by
>> a Figure, but whatever the way I turn this in my mind it always seems=
>> there is something that I missed and I am not satisfied.
>>
>> Here is what I understand about the bounds:
>> The purpose of the bounds are not only positionning a figure, it is a=
lso
>> to limit the space where a figure can introduce its paintings and the=
>> paintings of its children. Draw2d doesn't allow a figure and its =
>> children
>> to paint outside of its bounds. So before draw2d enters the paint met=
hod
>> of a Figure, it reduces the clipping area of the Graphics object to t=
he
>> intersection of the current clipping area and the bounds of the figur=
e =
>> to
>> paint (+-). If the clipping area is empty, the Figure is not painted.=
>> That
>> will more likely happen if the bounds are small. So for efficiency, y=
ou
>> have to set the bounds to the SMALLEST rectangle that is acceptable.
>> If there was no such a limitation of the space occupied by a Figure, =
=
>> each
>> time you'd want to repaint a small piece of the ui, you would have to=
>> repaint the all tree of figures because each of them would be likely =
to
>> introduce some painting in the small piece of the ui to repaint ! So =
I
>> think using correctly the bounds to limit the space available for a
>> figure
>> to paint allows some VERY BIG improvements of the repainting algorith=
m.
>> ]]
>>
>> r=E9gis
>>
>>
>>
>>
>>
>> You can't set the bounds of a Polyline as you set the bounds of anoth=
er
>> figure.
>>
>> On Tue, 1 Jun 2004 22:49:16 +0200, Jose M Beleta <beleta@attglobal.ne=
t>
>> wrote:
>>
>>> What's the reason for Polygon (Polyline) to have an empty
>>> primTranslate(int
>>> dx, int dy) method . Because that setBounds does not work as expecte=
d.
>>>
>>> Jose M beleta
>>>
>>>
>>
>>
>>
>
>
>
-- =
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
|
|
| | | |
| Re: Polygon has an empty Figure#primTranslate(int dx, int dy) [message #135879 is a reply to message #135841] |
Wed, 02 June 2004 20:53 |
| Eclipse User |
|
|
|
Originally posted by: rlemaigr.ulb.ac.be
No, in this case, I think the behaviour of draw2d is understandable and =
is =
good.
In your example, what will cause problems is the fact that you put a =
polyline in a container with a layout manager, and this layout manager =
will try to set the bounds of the polyline, which can not be done. I thi=
nk =
this is normal.
I think it is normal to prevent the user or a layout manager from settin=
g =
the bounds of a polyline because it doesn't make much sense to do so, im=
o.
Suppose draw2d let the user set the bounds of a polyline. The translatio=
n =
of the polyline could be done without problem, but what about resizing ?=
=
What should become the points when the polyline is resized ? So setting =
=
bounds of a polyline doesn't make sense and that's why draw2d calculates=
=
the bounds based on the points positions choosed by the user.
On the otherhand, what seems strange is that the polyline doesn't move =
with its parent, because the primTranslate method does nothing. I think =
=
that's the real problem, not the impossibility of setting the bounds whi=
ch =
is quite natural.
By the way, you could replace the code:
> protected IFigure createFigure()
> {
> Polygon figure =3D new Polygon();
> PointList pointList =3D new PointList(4);
> pointList.addPoint(0, 0);
> pointList.addPoint(20, 0);
> pointList.addPoint(20, 20);
> pointList.addPoint(0, 20);
> figure.setPoints(pointList);
> return figure;
> }
by
protected IFigure createFigure()
{
Figure fig =3D new Figure();
fig.setSize(new Dimension(20,20));
fig.setBorder(new LineBorder(1));
return fig;
}
and then use the XYLayoutManager with constraints like new =
Rectangle(x,y,-1,-1) (where x and y are the constraints written in your =
=
model for the model object to display) for preventing it from resizing =
your figures (I think it is possible).
And in more complicated cases, you could also overrides the paintFigure =
=
method of a Figure to draw the polyline in the bounds of the figure.
r=E9gis
On Thu, 3 Jun 2004 01:16:03 +0200, Jose M Beleta <beleta@attglobal.net> =
=
wrote:
>> I am sorry but I have no idea of a use case where this functionnality=
>> would be really needed and useful.
>
> Very simple:
>
> Why I can do this in
> org.eclipse.gef.editparts.AbstractGraphicalEditPart#createFi gure():
>
> protected IFigure createFigure()
> {
> Ellipse figure =3D new Ellipse();
> figure.setBounds(new Rectangle(0, 0, 20, 20));
> return figure;
> }
>
> but cannot do the following:
>
> protected IFigure createFigure()
> {
> Polygon figure =3D new Polygon();
> PointList pointList =3D new PointList(4);
> pointList.addPoint(0, 0);
> pointList.addPoint(20, 0);
> pointList.addPoint(20, 20);
> pointList.addPoint(0, 20);
> figure.setPoints(pointList);
> return figure;
> }
>
> Both are Shapes arn't they?
>
> Jose
>
> <rlemaigr@ulb.ac.be> escribi=F3 en el mensaje
> news:opr8yzycn5xn9g2u@xn--pcrgis-dva.mshome.net...
> I am sorry but I have no idea of a use case where this functionnality
> would be really needed and useful.
>
> Maybe Jose has an idea about that and could do it ?
>
> r=E9gis
>
>
> On Tue, 1 Jun 2004 23:04:47 -0400, Randy Hudson <none@us.ibm.com> wrot=
e:
>
>> This is a good summary. I am not sure why primtranslate does nothing=
.. =
>> I
>> think there is some history there. It probably goes back to some sor=
t =
>> of
>> optimization of avoiding unnecessary notification (at one point =
>> translate
>> and primTranslate were not split into two method), or maybe it was to=
>> prevent people from thinking they could call setBounds().
>>
>> It probably doesn't affect most users since the default viewport uses=
=
>> its
>> own coordinate system to implement scrolling, rather than translating=
=
>> its
>> contents. It could be changed, but I think it is too risky for 3.0 a=
nd
>> it
>> is simple to workaround if it is needed. Please add the use case to =
the
>> bugzilla.
>>
>> <rlemaigr@ulb.ac.be> wrote in message
>> news:opr8xvr3sqxn9g2u@xn--pcrgis-dva.mshome.net...
>> About the setbounds method of Polyline:
>>
>> One of the reasons the bounds are always something very fuzzy in my m=
ind
>> is the difference between the way the bounds are used in, say, a
>> RectangleFigure or a Label, and the way they are used in a Polyline:
>> - in a Label or a RectangleFigure, they seem to be used to give a
>> location
>> and a size to the figure. The paintFigure method is based on the boun=
ds
>> to
>> fill them with the content to display in the Figure. So: first you se=
t
>> the
>> bounds, and then the content to display is painted to fill them at be=
st
>> automatically.
>> - in a Polyline this is exactly the inverse situation. You adjust the=
>> content to display by setting the position of the points (and the
>> children?), and the getBounds() method calculate the bounds based on =
=
>> that
>> content to display. So: first you set the content to display, and the=
n
>> the
>> bounds are calculated to be the smallest rectangle which contains all=
=
>> the
>> points of the polyline (and also the children?).
>>
>> So now you can understand why the setbounds method does not work =
>> properly
>> on a polyline: as the bounds of a Polyline are automaticaly calculate=
d
>> when they are needed by the painting algorithm (based on the location=
of
>> the points (and the children?) of the polyline), you can't set them
>> yourself by calling setBounds() ! I don't know the behaviour of the
>> polyline if you call this method but I wouldn't try to do it.
>>
>>
>> Now about the primtranslate method, I asked myself the same question =
as
>> you: why doesn't this method do something like that
>> protected void primtranslate(int x, int y)
>> {
>> getPoints().translate(x,y);
>> for(all the children figures)
>> child.primTranslate(x,y);
>> }
>> in order to translate the polyline and its children when its parent i=
s
>> moved ??
>>
>> I am not sure about that. Here is my own explanation but it is not
>> completely satisfying so you will have to wait for a better answer.
>>
>> I think this was made like that because Polyline is the base for the
>> implementation of the Connection interface with the class
>> PolylineConnection.
>> A polyline connection is something that connects two figures and
>> automaticaly adjust itself when these two figures are moved (or at le=
ast
>> it is its purpose). To adjust itself, it makes use of a connection =
>> router
>> (for laying out the intermidiate points) and two connection anchors (=
for
>> specifying the location of the endpoints). His default layout is
>> DelegatingLayout so its children also adjust their locations and size=
s
>> themselves when the anchors of the connection are moved and the
>> connection
>> is relayed out.
>>
>> Keeping that in mind, you will understand why the primTranslate() met=
hod
>> is redifined to do nothing. What triggers a change in the location of=
=
>> the
>> points of a polyline connection is a change of the position of its
>> anchors
>> (its endpoints), not a change in the position of its parent. So there=
is
>> no reason to translate a polyline connection when its parent moves.
>>
>> But assuming that, they should have override this method in the
>> PolylineConnection class and not in the Polyline class. That I don't
>> understand. That's why my explanation is probably wrong :S .
>>
>>
>> [[ Maybe you will find that funny but I have never properly understoo=
d
>> what the bounds of a figure exactly are. I wonder if I am alone in th=
is
>> situation. In my mind it is misty. The javadoc says it has to be the
>> smallest rectangle which contains all the graphical elements introduc=
ed
>> by
>> a Figure, but whatever the way I turn this in my mind it always seems=
>> there is something that I missed and I am not satisfied.
>>
>> Here is what I understand about the bounds:
>> The purpose of the bounds are not only positionning a figure, it is a=
lso
>> to limit the space where a figure can introduce its paintings and the=
>> paintings of its children. Draw2d doesn't allow a figure and its =
>> children
>> to paint outside of its bounds. So before draw2d enters the paint met=
hod
>> of a Figure, it reduces the clipping area of the Graphics object to t=
he
>> intersection of the current clipping area and the bounds of the figur=
e =
>> to
>> paint (+-). If the clipping area is empty, the Figure is not painted.=
>> That
>> will more likely happen if the bounds are small. So for efficiency, y=
ou
>> have to set the bounds to the SMALLEST rectangle that is acceptable.
>> If there was no such a limitation of the space occupied by a Figure, =
=
>> each
>> time you'd want to repaint a small piece of the ui, you would have to=
>> repaint the all tree of figures because each of them would be likely =
to
>> introduce some painting in the small piece of the ui to repaint ! So =
I
>> think using correctly the bounds to limit the space available for a
>> figure
>> to paint allows some VERY BIG improvements of the repainting algorith=
m.
>> ]]
>>
>> r=E9gis
>>
>>
>>
>>
>>
>> You can't set the bounds of a Polyline as you set the bounds of anoth=
er
>> figure.
>>
>> On Tue, 1 Jun 2004 22:49:16 +0200, Jose M Beleta <beleta@attglobal.ne=
t>
>> wrote:
>>
>>> What's the reason for Polygon (Polyline) to have an empty
>>> primTranslate(int
>>> dx, int dy) method . Because that setBounds does not work as expecte=
d.
>>>
>>> Jose M beleta
>>>
>>>
>>
>>
>>
>
>
>
-- =
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
|
|
| | | |
| Re: Polygon has an empty Figure#primTranslate(int dx, int dy) [message #135987 is a reply to message #135956] |
Thu, 03 June 2004 10:53 |
| Eclipse User |
|
|
|
Originally posted by: rlemaigr.ulb.ac.be
I don't know.
Sure there is something confusing, but I don't see a good way for avoidi=
ng =
this confusion...I think we have to live with that...
Your idea of renaming Polygon in ClosedPolyline is not perfect, because =
=
there are in Polygon the two methods containsPoint(Point) and =
fillShape(Graphics) which don't act at all like they would in a Polyline=
:
- the containsPoint() method of a polygon returns true iff the Point is =
=
*inside the polygon*, which is not the expected behaviour for a Polyline=
,
- and the fillShape method fills the polygon with the background color =
which makes no sense for a Polyline...
So you can't call the Polygon class " Closed *Polyline* " without =
introducing other confusions...
In fact, for this reason I think the Polygon class should not have been =
a =
child class of Polyline at all, and Polyline should not have been a chil=
d =
class of Shape because fillShape doesn't make sense for a Polyline.
And as setBounds() doesn't make sense for a Polyline nor for a Polygon, =
so =
they shouldn't implement the IFigure interface or extends the Figure cla=
ss =
because they don't behave like a normal Figure ?
The whole thing is a big knot ! So I give up :D
Also, maybe the fact that java doesn't allow multiple inheritance makes =
=
the class hierarchy harder to organize than in other languages and leads=
=
to this kind of problems. I don't know. I think this is not perfect but =
I =
wonder if that could have been (in java at least).
r=E9gis
PS: about the Triangle class, I don't know why it works...but wait a =
minute I will go and see the code :DDD
On Thu, 3 Jun 2004 12:13:49 +0200, Jose M Beleta <beleta@attglobal.net> =
=
wrote:
> R=E9gis,
>
> I don't agree with you in this case:
>
> When I say setBounds I am saying setLocation because the setLocation
> implementation is always thru setBounds keep in mind that primTranslat=
e =
> is
> called from setBounds.
>
> Polygon is a Shape as Ellipse is. I don't care if Polygon is a Polylin=
e.
>
> If I use a circle build from a Ellipse as the figure of an EditPart it=
> behaves accordingly, if I move it the circle moves.
>
> But if try to use and square build from a Polygon, when I move the =
> EditPart
> the square remains at point (0,0).
>
> I the Polyline class was intented for another purpose another hierarch=
y
> should have been used for Polygon or for Polyline.
>
> All your explanation is about implementation, of course that I know ho=
w =
> to
> implement it to avoid the problem. Yes I know that the bound of the =
> Polygon
> cannot be set, but I knew it after reading the code, and that's the
> problem!!!
>
> Human knowledge goes on by using analogies. For me and for a child a =
> circle
> and a square are both figures that can be drawn and so they are =
> analogous.
> If I ask the child to draw a square into the center of the chalkboard =
it
> will draw it without any problem. The case is that Draw2d will draw it=
> allways in the left top corner of the board, instead of Draw2d perhaps=
a
> more appropiate name would be Draw0d.
>
> So here I cannot use the analogy; I have to learn that a polygon behav=
es
> differently than a circle. My learning is more difficult.
>
> Curiously enough there is a class called Triangle that behaves correct=
ly.
> And I learned in the school that a triangle is a polygon, but this is =
not
> the case in Draw2d.
>
>> because the primTranslate method does nothing. I think
>> that's the real problem
>
> Of course this is the cause, this is what I am saying. Look at the tit=
le =
> of
> the thread ;-)
>
> But this is not the important one. As always the real problem is namin=
g
> (filology as Nietzsche said). Rename Polygon to ClosedPolyline and mos=
t =
> of
> the difficulties will disappear.
>
> Jose
>
> <rlemaigr@ulb.ac.be> escribi=F3 en el mensaje
> news:opr8zt3jnpxn9g2u@xn--pcrgis-dva.mshome.net...
> No, in this case, I think the behaviour of draw2d is understandable an=
d =
> is
> good.
>
> In your example, what will cause problems is the fact that you put a
> polyline in a container with a layout manager, and this layout manager=
> will try to set the bounds of the polyline, which can not be done. I =
> think
> this is normal.
>
> I think it is normal to prevent the user or a layout manager from sett=
ing
> the bounds of a polyline because it doesn't make much sense to do so, =
=
> imo.
> Suppose draw2d let the user set the bounds of a polyline. The translat=
ion
> of the polyline could be done without problem, but what about resizing=
?
> What should become the points when the polyline is resized ? So settin=
g
> bounds of a polyline doesn't make sense and that's why draw2d calculat=
es
> the bounds based on the points positions choosed by the user.
>
> On the otherhand, what seems strange is that the polyline doesn't move=
> with its parent, because the primTranslate method does nothing. I thin=
k
> that's the real problem, not the impossibility of setting the bounds =
> which
> is quite natural.
>
> By the way, you could replace the code:
>
>> protected IFigure createFigure()
>> {
>> Polygon figure =3D new Polygon();
>> PointList pointList =3D new PointList(4);
>> pointList.addPoint(0, 0);
>> pointList.addPoint(20, 0);
>> pointList.addPoint(20, 20);
>> pointList.addPoint(0, 20);
>> figure.setPoints(pointList);
>> return figure;
>> }
>
> by
>
> protected IFigure createFigure()
> {
> Figure fig =3D new Figure();
> fig.setSize(new Dimension(20,20));
> fig.setBorder(new LineBorder(1));
> return fig;
> }
>
> and then use the XYLayoutManager with constraints like new
> Rectangle(x,y,-1,-1) (where x and y are the constraints written in you=
r
> model for the model object to display) for preventing it from resizing=
> your figures (I think it is possible).
>
> And in more complicated cases, you could also overrides the paintFigur=
e
> method of a Figure to draw the polyline in the bounds of the figure.
>
> r=E9gis
>
>
> On Thu, 3 Jun 2004 01:16:03 +0200, Jose M Beleta <beleta@attglobal.net=
>
> wrote:
>
>>> I am sorry but I have no idea of a use case where this functionnalit=
y
>>> would be really needed and useful.
>>
>> Very simple:
>>
>> Why I can do this in
>> org.eclipse.gef.editparts.AbstractGraphicalEditPart#createFi gure():
>>
>> protected IFigure createFigure()
>> {
>> Ellipse figure =3D new Ellipse();
>> figure.setBounds(new Rectangle(0, 0, 20, 20));
>> return figure;
>> }
>>
>> but cannot do the following:
>>
>> protected IFigure createFigure()
>> {
>> Polygon figure =3D new Polygon();
>> PointList pointList =3D new PointList(4);
>> pointList.addPoint(0, 0);
>> pointList.addPoint(20, 0);
>> pointList.addPoint(20, 20);
>> pointList.addPoint(0, 20);
>> figure.setPoints(pointList);
>> return figure;
>> }
>>
>> Both are Shapes arn't they?
>>
>> Jose
>>
>> <rlemaigr@ulb.ac.be> escribi=F3 en el mensaje
>> news:opr8yzycn5xn9g2u@xn--pcrgis-dva.mshome.net...
>> I am sorry but I have no idea of a use case where this functionnality=
>> would be really needed and useful.
>>
>> Maybe Jose has an idea about that and could do it ?
>>
>> r=E9gis
>>
>>
>> On Tue, 1 Jun 2004 23:04:47 -0400, Randy Hudson <none@us.ibm.com> wro=
te:
>>
>>> This is a good summary. I am not sure why primtranslate does nothin=
g.
>>> I
>>> think there is some history there. It probably goes back to some so=
rt
>>> of
>>> optimization of avoiding unnecessary notification (at one point
>>> translate
>>> and primTranslate were not split into two method), or maybe it was t=
o
>>> prevent people from thinking they could call setBounds().
>>>
>>> It probably doesn't affect most users since the default viewport use=
s
>>> its
>>> own coordinate system to implement scrolling, rather than translatin=
g
>>> its
>>> contents. It could be changed, but I think it is too risky for 3.0 =
and
>>> it
>>> is simple to workaround if it is needed. Please add the use case to=
=
>>> the
>>> bugzilla.
>>>
>>> <rlemaigr@ulb.ac.be> wrote in message
>>> news:opr8xvr3sqxn9g2u@xn--pcrgis-dva.mshome.net...
>>> About the setbounds method of Polyline:
>>>
>>> One of the reasons the bounds are always something very fuzzy in my =
=
>>> mind
>>> is the difference between the way the bounds are used in, say, a
>>> RectangleFigure or a Label, and the way they are used in a Polyline:=
>>> - in a Label or a RectangleFigure, they seem to be used to give a
>>> location
>>> and a size to the figure. The paintFigure method is based on the bou=
nds
>>> to
>>> fill them with the content to display in the Figure. So: first you s=
et
>>> the
>>> bounds, and then the content to display is painted to fill them at b=
est
>>> automatically.
>>> - in a Polyline this is exactly the inverse situation. You adjust th=
e
>>> content to display by setting the position of the points (and the
>>> children?), and the getBounds() method calculate the bounds based on=
>>> that
>>> content to display. So: first you set the content to display, and th=
en
>>> the
>>> bounds are calculated to be the smallest rectangle which contains al=
l
>>> the
>>> points of the polyline (and also the children?).
>>>
>>> So now you can understand why the setbounds method does not work
>>> properly
>>> on a polyline: as the bounds of a Polyline are automaticaly calculat=
ed
>>> when they are needed by the painting algorithm (based on the locatio=
n =
>>> of
>>> the points (and the children?) of the polyline), you can't set them
>>> yourself by calling setBounds() ! I don't know the behaviour of the
>>> polyline if you call this method but I wouldn't try to do it.
>>>
>>>
>>> Now about the primtranslate method, I asked myself the same question=
as
>>> you: why doesn't this method do something like that
>>> protected void primtranslate(int x, int y)
>>> {
>>> getPoints().translate(x,y);
>>> for(all the children figures)
>>> child.primTranslate(x,y);
>>> }
>>> in order to translate the polyline and its children when its parent =
is
>>> moved ??
>>>
>>> I am not sure about that. Here is my own explanation but it is not
>>> completely satisfying so you will have to wait for a better answer.
>>>
>>> I think this was made like that because Polyline is the base for the=
>>> implementation of the Connection interface with the class
>>> PolylineConnection.
>>> A polyline connection is something that connects two figures and
>>> automaticaly adjust itself when these two figures are moved (or at =
>>> least
>>> it is its purpose). To adjust itself, it makes use of a connection
>>> router
>>> (for laying out the intermidiate points) and two connection anchors =
=
>>> (for
>>> specifying the location of the endpoints). His default layout is
>>> DelegatingLayout so its children also adjust their locations and siz=
es
>>> themselves when the anchors of the connection are moved and the
>>> connection
>>> is relayed out.
>>>
>>> Keeping that in mind, you will understand why the primTranslate() =
>>> method
>>> is redifined to do nothing. What triggers a change in the location o=
f
>>> the
>>> points of a polyline connection is a change of the position of its
>>> anchors
>>> (its endpoints), not a change in the position of its parent. So ther=
e =
>>> is
>>> no reason to translate a polyline connection when its parent moves.
>>>
>>> But assuming that, they should have override this method in the
>>> PolylineConnection class and not in the Polyline class. That I don't=
>>> understand. That's why my explanation is probably wrong :S .
>>>
>>>
>>> [[ Maybe you will find that funny but I have never properly understo=
od
>>> what the bounds of a figure exactly are. I wonder if I am alone in t=
his
>>> situation. In my mind it is misty. The javadoc says it has to be the=
>>> smallest rectangle which contains all the graphical elements introdu=
ced
>>> by
>>> a Figure, but whatever the way I turn this in my mind it always seem=
s
>>> there is something that I missed and I am not satisfied.
>>>
>>> Here is what I understand about the bounds:
>>> The purpose of the bounds are not only positionning a figure, it is =
=
>>> also
>>> to limit the space where a figure can introduce its paintings and th=
e
>>> paintings of its children. Draw2d doesn't allow a figure and its
>>> children
>>> to paint outside of its bounds. So before draw2d enters the paint =
>>> method
>>> of a Figure, it reduces the clipping area of the Graphics object to =
the
>>> intersection of the current clipping area and the bounds of the figu=
re
>>> to
>>> paint (+-). If the clipping area is empty, the Figure is not painted=
..
>>> That
>>> will more likely happen if the bounds are small. So for efficiency, =
you
>>> have to set the bounds to the SMALLEST rectangle that is acceptable.=
>>> If there was no such a limitation of the space occupied by a Figure,=
>>> each
>>> time you'd want to repaint a small piece of the ui, you would have t=
o
>>> repaint the all tree of figures because each of them would be likely=
to
>>> introduce some painting in the small piece of the ui to repaint ! So=
I
>>> think using correctly the bounds to limit the space available for a
>>> figure
>>> to paint allows some VERY BIG improvements of the repainting algorit=
hm.
>>> ]]
>>>
>>> r=E9gis
>>>
>>>
>>>
>>>
>>>
>>> You can't set the bounds of a Polyline as you set the bounds of anot=
her
>>> figure.
>>>
>>> On Tue, 1 Jun 2004 22:49:16 +0200, Jose M Beleta <beleta@attglobal.n=
et>
>>> wrote:
>>>
>>>> What's the reason for Polygon (Polyline) to have an empty
>>>> primTranslate(int
>>>> dx, int dy) method . Because that setBounds does not work as expect=
ed.
>>>>
>>>> Jose M beleta
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
-- =
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
|
|
| | | |
| Re: Polygon has an empty Figure#primTranslate(int dx, int dy) [message #136252 is a reply to message #136079] |
Thu, 03 June 2004 18:37 |
| Eclipse User |
|
|
|
Originally posted by: rlemaigr.ulb.ac.be
Yes...and that's why freeformfigures caused me a LOT of troubles (in fac=
t =
I gave up to understand it but that doesn't matter)...
When you read the code of Polyline, it is quite simple to understand tha=
t =
the bounds can't be set and how they are calculated but the complexity o=
f =
the freeform classes is much higher...
Bounds of Figures are something very confusing for me because sometimes =
=
they are used for repositionning and resizing a Figure, and sometimes th=
ey =
are calculated at best only to optimize the painting algorithm like in =
polyline and freeform figures (if i am not wrong) and as you said in the=
=
text package (which I don't know at all).
If you add to that difficulty the coordinates systems, the possiblity of=
=
zooming, the exact meaning of the translateToAbsolute(), =
TranslateToRelative(), paintFigure(), repaint(), revalidate(), validate(=
), =
invalidate(), findFigureAt(), containsPoint() and layout() methods, when=
=
we have to override some of these, and the events/listeners system you =
have something that is really hard to understand for us !
(personnaly I find it more difficult to understand than GEF)
And then, with the energy of despair, our eyes full of tears, we =
desperately go and see in the docs of the library, hoping for a beautifu=
l =
piece of Art explaining the whole thing...but no...there is nothing ther=
e =
waiting for us...we are just all alone with the vicious code, three litt=
le =
examples and the javadoc...do you understand what we can feel at times =
like these ?
:'''(
Well, I quit the jokes...
Thank you for your time and the explanations you have given to us on thi=
s =
matter,
r=E9gis
On Thu, 3 Jun 2004 16:34:58 -0400, Randy Hudson <none@us.ibm.com> wrote:=
> The same issue of "being a Figure subclass" occurs again in the =
> draw2d.text
> package, where it is up to the figures to determine their own bounds =
> based
> on their text fragments and the way they wrapped. Also, it occurs in =
the
> freeform figures where freeform figures calculate their bounds as the =
=
> area
> which encompasses their children.
>
>
-- =
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
|
|
|
| Re: Polygon has an empty Figure#primTranslate(int dx, int dy) [message #136258 is a reply to message #136069] |
Fri, 04 June 2004 03:57 |
| Eclipse User |
|
|
|
Randy,
> If we had thought longer and harder, we
> would have seen these other use cases ...
This simple sentence summarizes the differences between your philosophy and
mine. I think that you think that Polygon - or any other class - needs to be
implemented depending on the way it will be used; my opinion is that Polygon
should be implemented depending on what it is, if it is a Figure - or a
Shape - and Figures move then Polygon should move.
Use cases are good to build systems, but in my opinion not so good to make
APIs or generic tools. The really good tools are those that are used in ways
its designer could never imagine.
You do not need to think longer or harder, your product is great, but in my
opinion, perhaps, sometimes, I would like that you thought a little bit
differently.
Jose
"Randy Hudson" <none@us.ibm.com> escribi
|
|
|
| Re: Polygon has an empty Figure#primTranslate(int dx, int dy) [message #136314 is a reply to message #136258] |
Fri, 04 June 2004 15:51 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
We don't start with class names and then write code. We have a problem
which needs to be solved, we solve it, and then we try to name the stuff as
best we can.
"Jose M Beleta" <beleta@attglobal.net> wrote in message
news:c9p9i0$gi7$1@eclipse.org...
> Randy,
>
> > If we had thought longer and harder, we
> > would have seen these other use cases ...
>
> This simple sentence summarizes the differences between your philosophy
and
> mine. I think that you think that Polygon - or any other class - needs to
be
> implemented depending on the way it will be used; my opinion is that
Polygon
> should be implemented depending on what it is, if it is a Figure - or a
> Shape - and Figures move then Polygon should move.
>
> Use cases are good to build systems, but in my opinion not so good to make
> APIs or generic tools. The really good tools are those that are used in
ways
> its designer could never imagine.
>
> You do not need to think longer or harder, your product is great, but in
my
> opinion, perhaps, sometimes, I would like that you thought a little bit
> differently.
>
> Jose
>
|
|
|
Goto Forum:
Current Time: Sun Nov 09 17:19:30 EST 2025
Powered by FUDForum. Page generated in 0.07243 seconds |
Home