wx.lib.ogl - weirdness after LineShape.InsertLineControlPoint

[Gary_Greyling]

Hello Everybody,

This is my first post to the list so i guess a short intro is in order. My name is Gary and i'm a software developer, sounds much like an AA meeting

Some details first:
OS: Debian testing/unstable (4.0)
Python: 2.4
wx-gtk: 2.6.3.2
Application: Flow Charting

The issue i'm having is as follows, the default behavior of a line attached to say 2 RectangleShapes is to point to the center of each object. Now the issue is that once you add a line control point the line edges lock into position on the edge where they where last. The question: Is this intentional and/or is there a way to change this ?

I have read through the code and the list archives and have not found anything with regards to this. Help you be greatly appreciated.

Thanks
Gary
I'm

[Brian_Elmegaard]

Gary Greyling <gary.greyling@gmail.com> writes:

This is my first post to the list

Isn't it your second?

I have similar problems as you have. I find wxogl very interesting but
I simply cannot figure out how attachmentpoints and controlpoints
work.

I have read through the code and the list archives and have not found
anything with regards to this. Help you be greatly appreciated.

Me too.

I had some questions in
http://article.gmane.org/gmane.comp.python.wxpython/42428/match= but I
got no answers. I think ogl is the right tool for me, but I do think
some more documentation is required. The best way I can think of
currently, is to go ahead and write it, but i am not really sure how
to get started.

No help, but same hopes as you.

···

--
Brian (remove the sport for mail)
http://www.et.web.mek.dtu.dk/Staff/be/be.html

Rugbyklubben Speed – Danmarks ældste Rugbyklub

[Pierre_Hjalm]

Brian Elmegaard <be@mek.dtu.dk> writes:

> Gary Greyling <gary.greyling@gmail.com> writes:
>
> > This is my first post to the list
>
> Isn't it your second?
>
> I have similar problems as you have. I find wxogl very interesting but
> I simply cannot figure out how attachmentpoints and controlpoints
> work.
>
> > I have read through the code and the list archives and have not found
> > anything with regards to this. Help you be greatly appreciated.
>
> Me too.
>
> I had some questions in
> http://article.gmane.org/gmane.comp.python.wxpython/42428/match= but I
> got no answers. I think ogl is the right tool for me, but I do think
> some more documentation is required. The best way I can think of
> currently, is to go ahead and write it, but i am not really sure how
> to get started.
>
> No help, but same hopes as you.

I suppose it would fall upon me to answer this (and earlier questions
about ogl), but I have been quite busy. Sorry about that.

There's also the fact that I'm not that familiar with lines since
I don't use them in my own (dormant) project.

But I'll take a look and see what I can figure out. You should have
an answer by the end of the week, even if it is that I don't know
what I'm doing

···

--
  Pierre Hjälm - Not so OGL anymore

[Brian_Elmegaard]

Pierre Hjälm <pierre.hjalm@dis.uu.se> writes:

But I'll take a look and see what I can figure out. You should have
an answer by the end of the week, even if it is that I don't know
what I'm doing

Thanks, Pierre. I will really appreciate this or just some guidelines
on how to dig into it.

Some general questions that you may consider for the end of the week:
How did you learn wxogl?
How have you been able to convert it all to python without actually
doing anything with (some of) it?

tia,

···

--
Brian (remove the sport for mail)
http://www.et.web.mek.dtu.dk/Staff/be/be.html

Rugbyklubben Speed – Danmarks ældste Rugbyklub

[Robin]

Brian Elmegaard wrote:

I think ogl is the right tool for me, but I do think
some more documentation is required. The best way I can think of
currently, is to go ahead and write it, but i am not really sure how
to get started.

Add docstrings to the classes and methods, using reStructuredText format as understood by the epydoc tool. Then send me patch files that I can apply to the source code in CVS.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

[Gary_Greyling]

Hello Brian,

I have figured out some things and can send you some code if you are interested, however it only works when you have attachment mode set to edge .... and yes it's terribly hacky.

Gary

Brian Elmegaard wrote:

···

Gary Greyling <gary.greyling@gmail.com> writes:

This is my first post to the list
    
Isn't it your second?

I have similar problems as you have. I find wxogl very interesting but
I simply cannot figure out how attachmentpoints and controlpoints
work.

I have read through the code and the list archives and have not found
anything with regards to this. Help you be greatly appreciated.
    
Me too.

I had some questions in
http://article.gmane.org/gmane.comp.python.wxpython/42428/match= but I
got no answers. I think ogl is the right tool for me, but I do think
some more documentation is required. The best way I can think of
currently, is to go ahead and write it, but i am not really sure how
to get started.

No help, but same hopes as you.

[Gary_Greyling]

Thank you Pierre, any input will be appreciated...

Gary

Pierre Hjälm wrote:

Brian Elmegaard <be@mek.dtu.dk> writes:

> Gary Greyling <gary.greyling@gmail.com> writes:
> > > This is my first post to the list
>

<snip>

[Pierre_Hjalm]

Gary Greyling <gary.greyling@gmail.com> writes:

> Hello Everybody,
>
> The issue i'm having is as follows, the default behavior of a line
> attached to say 2 RectangleShapes is to point to the center of each
> object. Now the issue is that once you add a line control point the line
> edges lock into position on the edge where they where last. The
> question: Is this intentional and/or is there a way to change this ?
>

Ok, I must confess that I don't quite understand the question.

If you look at how the demo does it, it creates a line and adds two
line control points. This makes the line attach to the edge of the shapes.

I'm not quite sure how you would manage to do otherwise. Could you
perhaps put together an example of your problem?

And just to be practical, Brian's questions:

> Some general questions that you may consider for the end of the week:
> How did you learn wxogl?
> How have you been able to convert it all to python without actually
> doing anything with (some of) it?
>

I used the old OGL docs (you'll have to google for them) and the source to
learn OGL. That, and lots of trial and error (the docs weren't always
correct).

The C code translated quite nicely to python, so there really wasn't much
to alter. Apart from the occasional bug fix.

···

--
  Pierre Hjälm

[Gary_Greyling]

Pierre Hjälm wrote:

Ok, I must confess that I don't quite understand the question.
If you look at how the demo does it, it creates a line and adds two
line control points. This makes the line attach to the edge of the shapes.
I'm not quite sure how you would manage to do otherwise. Could you
perhaps put together an example of your problem?

Yes and in the demo it works fine as the demo never adds a point to the
line for “bending” it. Once you add this point to the line, the place
it attaches to the objects on either point becomes locked in place.
Below is some code to demonstrate this.

`import wx

import wx.lib.ogl as ogl

class OTest(wx.App):

def OnInit(self):

   ogl.OGLInitialize()

   wx.InitAllImageHandlers()

   self.Frame = wx.Frame(None, -1, "Test",(0,0),(640,480))

   self.Canvas = ogl.ShapeCanvas(self.Frame)

   dc = wx.ClientDC(self.Canvas)

   self.Diagram = ogl.Diagram()

   self.Canvas.SetDiagram(self.Diagram)

   self.Diagram.SetCanvas(self.Canvas)

   rect1 = ogl.RectangleShape(150,50)

   rect1.AddToCanvas(self.Canvas)

   rect1.Move(dc,300,100)

   rect1.Show(True)

   rect2 = ogl.RectangleShape(150,50)

   rect2.AddToCanvas(self.Canvas)

   rect2.Move(dc,300,300)

   rect2.Show(True)

   line1 = ogl.LineShape()

   line1.AddToCanvas(self.Canvas)

   line1.Show(True)

   line1.MakeLineControlPoints(2)

   rect1.AddLine(line1,rect2)

   line1.InsertLineControlPoint()

   self.SetTopWindow(self.Frame)

   self.Frame.Show(True)

   return True

app = OTest()

app.MainLoop()

`

Simply drag either one of the boxes around to see what happens,
remove/comment the line1.InsertLineControlPoint() to see normal
behavior.

I used the old OGL docs (you'll have to google for them) and the source to
learn OGL. That, and lots of trial and error (the docs weren't always
correct).

I can imagine, the library never got the support it deserved …

The C code translated quite nicely to python, so there really wasn't much
to alter. Apart from the occasional bug fix.

I’ll start adding docstrings as i use the functions. I believe the demo
could use some updating as each “Shape” is and eventhandler and can be
made to be completely self aware. There is some interesting things you
can do then

Regards

Gary

[Brian_Elmegaard]

Gary Greyling <gary.greyling@gmail.com> writes:

       line1.InsertLineControlPoint()

I see this too. I would assume the control points should stay in the
centres of the rectangles.

···

--
Brian (remove the sport for mail)
http://www.et.web.mek.dtu.dk/Staff/be/be.html

Rugbyklubben Speed – Danmarks ældste Rugbyklub

[Brian_Elmegaard]

Pierre Hjälm <pierre.hjalm@dis.uu.se> writes:

And just to be practical, Brian's questions:

Thanks, I then guess that there has not been made a comprehesive test
of everything?

I have been doing some simple stuff to get started and I have found
the following bugs and solved some of the problems. Several questions
have arised:

Fixed Bugs(?):
*Rectangle attachment points are wrong. Change lines 1524-- in
_basic.py to
                if physicalAttachment == 0:
                    pt=left,(top+bottom)/2.0 #BE pt = self.CalcSimpleAttachment((left, bottom), (right, bottom), nth, no_arcs, line)
                elif physicalAttachment == 1:
                    pt=((left+right)/2.0,top) #BE pt = self.CalcSimpleAttachment((right, bottom), (right, top), nth, no_arcs, line)
                elif physicalAttachment == 2:
                    pt=(right,(top+bottom)/2.0) #BE pt = self.CalcSimpleAttachment((left, top), (right, top), nth, no_arcs, line)
                elif physicalAttachment == 3:
                    pt=((left+right)/2.0,bottom) #BE pt = self.CalcSimpleAttachment((left, bottom), (left, top), nth, no_arcs, line)

*Polygon region is not centred:
change line 1204 in _basic.py to:
        new_line = ShapeTextLine(self._xpos, self._ypos, string) #BE new_line = ShapeTextLine(0, 0, string)
add line 2426 to _basic.py
            self.CalculatePolygonCentre() #BE Added to have centered text - may give other problems?

*Polygon attachments are wrong: Change line 2693 in _basic.py to
            point = self._points[attachment]#BE point = self._points[0]

*Lines with more than 2 control points had all intermediate points
initiliazed in the middle. Change lines 338 in _lines.py to
            number_of_points=len(self._lineControlPoints)#BE
            for i in range(1,number_of_points):#for i in range(1,len(self._lineControlPoints)):

and line 353 to
                    self._lineControlPoints[i] = wx.RealPoint((x2 - x1) / float(number_of_points-1)*i + x1, (y2 - y1) / float(number_of_points-1)*i + y1) #BE self._lineControlPoints[i] = wx.RealPoint((x2 - x1) / 2.0 + x1, (y2 - y1) / 2.0 + y1)

Bugs(?) not fixed:
* the attachment modes defined in _oglmisc.py don't seem to be
available
* draw_handles doesn't give the effect I expected, show all control points

Questions unsolved:
*I still would like to know how to extract all information about the
current diagram.
*Are other line styles available, such as dashed, double, fat lines? What
about making lines consisting of different line types, i.e., solid and
dashed parallel to each other?
*Can lines be kept either vertical or horizontal and so that lines
with more control points can only turn 90 degrees?
*How can line control points be dragged?

tia,

···

--
Brian (remove the sport for mail)
http://www.et.web.mek.dtu.dk/Staff/be/be.html

Rugbyklubben Speed – Danmarks ældste Rugbyklub

[Gary_Greyling]

Brian Elmegaard wrote:

I see this too. I would assume the control points should stay in the
centres of the rectangles.

Well one would think that would be the default behavior and that is should remain so, however as you see it does not. I have checked out the source from cvs and will be going through there to see if i can find where it is going wrong. Maybe i can submit a fix for it soon .... <holds thumbs>

Gary

[Gary_Greyling]

Questions unsolved:
*I still would like to know how to extract all information about the
current diagram.
  

You need to be a little more specific here. What information are you after, things like shapes on the diagram are available and you can get the shape information from each shape including the x/y coordinates. Mail me off list if you want some examples as i have written a class that saves xml files for the flow diagrams i do in my app.

*Are other line styles available, such as dashed, double, fat lines? What
about making lines consisting of different line types, i.e., solid and
dashed parallel to each other?
  

The pen you use determines the line style, use a dashed pen if you want a dashed line same for "fat" lines, use a thinker pen. Again mail me if you want some examples. Double lines i would simply draw 2 lines ...

*Can lines be kept either vertical or horizontal and so that lines
with more control points can only turn 90 degrees?
  

Yup call LineShape.Straighten(dc) after you have moved any point on the line.

*How can line control points be dragged?
  

They can be dragged by default, just make sure the line is "selected" before you will see the control points. Simple click and drag ...

Hope this is usefull

Gary

[Pierre_Hjalm]

Gary Greyling <gary.greyling@gmail.com> writes:

> Pierre Hjälm wrote:
> > Ok, I must confess that I don't quite understand the question.
> >
> > If you look at how the demo does it, it creates a line and adds two
> > line control points. This makes the line attach to the edge of the shapes.
> >
> > I'm not quite sure how you would manage to do otherwise. Could you
> > perhaps put together an example of your problem?
> >
> Yes and in the demo it works fine as the demo never adds a point to the
> line for "bending" it. Once you add this point to the line, the place it
> attaches to the objects on either point becomes locked in place. Below
> is some code to demonstrate this.
>
Interestingly enough, it worked if you either used MakeLineControlPoints
to directly create more than 2 points, or if you called InsertLineControlPoint
before calling AddLine. That got me thinking in the right direction, and
sure enough, the bug was in the initialisation routine.

Could you please test the following (somewhat embarrasing) patch to _lines.py:

353c353
< self._initialised = True

···

---

                    self._initialised = True

It seems to do the trick, but I'm not sure it won't have some annoying
side effects...

--
  Pierre Hjälm - OGL warps my mind

[Gary_Greyling]

Hello Pierre,

You are a champion, thanks that does do the trick, i have the function now in my Line class overriding with the fix and all is working perfectly. I'll see if it breaks anything and report what i find. Thanks again.

Gary (4 spaces)

Pierre Hjälm wrote:

···

Could you please test the following (somewhat embarrasing) patch to _lines.py:

353c353
< self._initialised = True
---
  

                    self._initialised = True

[Gary_Greyling]

Hello Pierre,

The LineShape.InsertLineControlPoint asways inserts the point as the
second last item in LineShape._lineControlPoints. Below is code that
will find the real position of a point along the line and i suggest we
replace the InsertLineControlPoint with the code below.

` def InsertLineControlPoint(self, dc,
point):

    """Find the position in the control point list and insert the

control point there"""

    if dc: self.Erase(dc)

    insertpoint = 0

    if point:

        for insertpoint in range(0,len(self._lineControlPoints)-1):

            point1 =

self._lineControlPoints[insertpoint]

            point2 = self._lineControlPoints[insertpoint+1]

            if point1[0] > point2[0]:

                xran = range(int(point2[0]),int(point1[0]))

            else:

                xran = range(int(point1[0]),int(point2[0]))

            if point1[1] > point2[1]:

                yran = range(int(point2[1]),int(point1[0]))

            else:

                yran = range(int(point1[1]),int(point2[1]))

            if point[0] in xran and point[1] in yran:

                break

    else:

        last_point = self._lineControlPoints[-1]

        second_last_point = self._lineControlPoints[-2]

        point = ((last_point[0] + second_last_point[0]) / 2.0,

(last_point[1] + second_last_point[1]) / 2.0)

    realpoint = wx.RealPoint(point[0],point[1])

    self._lineControlPoints.insert(insertpoint+1, realpoint)

`

Hope somebody finds this usefull, it was driving me nuts as
everytime i added a control point it would have to be done at the end
of the line, rather than where i wanted

Regards

Gary

[Pierre_Hjalm]

Gary Greyling <gary.greyling@gmail.com> writes:

> Hello Pierre,
>
> The LineShape.InsertLineControlPoint asways inserts the point as the
> second last item in LineShape._lineControlPoints. Below is code that
> will find the real position of a point along the line and i suggest we
> replace the InsertLineControlPoint with the code below.
>
> def InsertLineControlPoint(self, dc, point):
> """Find the position in the control point list and insert the
> control point there"""

You probably want to make it more compatible with the old method.

    def InsertLineControlPoint(self, dc = None, point = None):

dc and point are optional. But otherwise it seems like a great idea, unless
someone actually expects the old behaviour. Perhaps another argument could
be added:

    def InsertLineControlPoint(self, dc = None, point = None, inorder = False):

where if inorder is set it uses your way and if false (the default) it uses the
old way? Depending on how you interpret inorder, it could of course be the
other way round

···

--
  Pierre Hjälm

[Gary_Greyling]

Hello Pierre,

Pierre Hjälm wrote:

You probably want to make it more compatible with the old method.

    def InsertLineControlPoint(self, dc = None, point = None):
  

Oops, my bad. You are 100% correct here.

dc and point are optional. But otherwise it seems like a great idea, unless
someone actually expects the old behaviour. Perhaps another argument could
be added:

    def InsertLineControlPoint(self, dc = None, point = None, inorder = False):

where if inorder is set it uses your way and if false (the default) it uses the
old way? Depending on how you interpret inorder, it could of course be the
other way round
  

Agreed, should i code it up and send it to you for inclusion ?

Gary

[Pierre_Hjalm]

Gary Greyling <gary.greyling@gmail.com> writes:

> Hello Pierre,
>
> You are a champion, thanks that does do the trick, i have the function
> now in my Line class overriding with the fix and all is working
> perfectly. I'll see if it breaks anything and report what i find. Thanks
> again.
>
> Gary (4 spaces)
>
> Pierre Hjälm wrote:
> > Could you please test the following (somewhat embarrasing) patch to _lines.py:
> >
> > 353c353
> > < self._initialised = True
> > ---
> >
> >> self._initialised = True
> >>
>
Since I haven't heard anything I assume all is well and hopefully Robin
will incorporate this patch.

···

--
  Pierre Hjälm

[Pierre_Hjalm]

Gary Greyling <gary.greyling@gmail.com> writes:

> Hello Pierre,
>
> Pierre Hjälm wrote:
> > You probably want to make it more compatible with the old method.
> >
> > def InsertLineControlPoint(self, dc = None, point = None):
> >
> Oops, my bad. You are 100% correct here.
> > dc and point are optional. But otherwise it seems like a great idea, unless
> > someone actually expects the old behaviour. Perhaps another argument could
> > be added:
> >
> > def InsertLineControlPoint(self, dc = None, point = None, inorder = False):
> >
> > where if inorder is set it uses your way and if false (the default) it uses the
> > old way? Depending on how you interpret inorder, it could of course be the
> > other way round
> >
> Agreed, should i code it up and send it to you for inclusion ?
>
Well, if it's compatible with the original then just post it here
and Robin might be persuaded to include it

···

--
  Pierre Hjälm