Trying to understand GraphicsPath

wxPython Users
1

Hi all

I am having fun learning how to draw a chart using BPMN (Business Process
Modelling Notation).

Here is a link to a poster showing all the symbols -

http://bpt.hpi.uni-potsdam.de/pub/Public/BPMNCorner/BPMN1_1_Poster_EN.pdf

Drawing the symbols in no real problem - some of them are quite challenging,
but that is part of the fun.

I am trying to work out how to do a HitTest, so that I can detect if the
user wants to drag a symbol. At this stage I am concentrating on a Circle.

GraphicsPath has a Contains() method - you pass it a Point, and it returns
True if the point is within the path, else False. This seems like the
obvious way to perform the test.

If you run the attached program, you will see that there are three circles.
One is a plain circle, the second has a thick transparent border, and the
third has a thick solid border.

Using gtk2, HitTest always returns None, no matter where I click. Maybe the
Contains() method is not supported on gtk2. [See my P.S. at the bottom]

Using msw, HitTest works correctly, but it is actually cleverer than I want
it to be. The first circle works perfectly, the second two return True if I
click within the border, but False if I click in the centre of the circle. I
want a click anywhere within the outer circle to return True, but I cannot
figure out how to do it.

I have tried three approaches -

1. AddCircle() for the outer and the inner circles
2. AddCircle() for the outer, then create a sub-path and AddCircle() to the
sub-path for the inner circle
3. AddEllipse() for the outer and the inner circles

They all give the same result.

I do not have a clear understanding of what constitutes a Path, what
constitutes a SubPath, how the Stroke/Fill/Draw methods interact with them,
and how to manipulate them to give the desired effect. The docs do not give
any assistance here.

Most symbols are quite a bit more complex than a simple circle. I will need
to detect a click anywhere within outer perimeter of the shape.

Any info will be much appreciated.

Frank Millman

P.S. I have just noticed that gtk2 returns True if you click on the actual
line defining the circle, but not if you click within the circle.
Unfortunately this does not help me.

bpmn11.py (2.41 KB)

2

Frank Millman wrote:

I am having fun learning how to draw a chart using BPMN (Business Process
Modelling Notation).

Frank, did you consider using wx.lib.floatcanvas? There is a bunch of code in there that does hit-testing all that for you.

The current version uses DCs, rather than GraphicsContext, so ti doesn't handle alpha blending, which you may need (but may not). However there is new version about to be released (and currently in a branch in SVN that is based on GraphicsContext.

Also, now that I think about it, you can create a custom DrawObject for FloatCanvas1 that uses a GraphicsContext to draw, if you do need some of those features:

http://morticia.cs.dal.ca/FloatCanvas/wiki/SmoothLines

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer

NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

3

Christopher Barker wrote:

Frank Millman wrote:
> I am having fun learning how to draw a chart using BPMN (Business
> Process Modelling Notation).

Frank, did you consider using wx.lib.floatcanvas? There is a
bunch of code in there that does hit-testing all that for you.

The current version uses DCs, rather than GraphicsContext, so
ti doesn't handle alpha blending, which you may need (but may
not). However there is new version about to be released (and
currently in a branch in SVN that is based on GraphicsContext.

Also, now that I think about it, you can create a custom
DrawObject for
  FloatCanvas1 that uses a GraphicsContext to draw, if you do
need some of those features:

http://morticia.cs.dal.ca/FloatCanvas/wiki/SmoothLines

-Chris

Thanks for the suggestion, Chris.

I have not tried FloatCanvas yet, as I have no requirement for numpy, and I
am trying to avoid too many dependencies.

I will wait a bit to see if Robin comes up with any ideas. If not, I will
bit the bullet, install numpy, and start playing with FloatCanvas.

Thanks again

Frank

4

P.S. I have just noticed that gtk2 returns True if you click on the actual
line defining the circle, but not if you click within the circle.
Unfortunately this does not help me.

On wxGTK, wxGraphics* uses cairo for drawing. wxGraphicsPath.Contains()
is calling the 'cairo_point_in_stroke()' to do hit testing. This only
tests the stroked area (not the fill). Cairo has a different function
for doing hit-testing on a fill 'cairo_point_in_fill()'. This is not
used in wxGraphicsPath, hence your problem.

If you want to get hit-testing working for wxGTK, you could use
wxGraphicsPath.GetNativePath() to get a pointer to the raw cairo_path_t,
then call 'cairo_point_in_fill' using ctypes/pycairo.

I posted some notes on the pyWiKi on using cairo with wxPython; you
could follow a similar strategy to convert between wxGraphicsPaths and
pycairo.Path objects.

FWIW, I recommend cairo for drawing on Windows as well as GTK, as the
API is great and you have svg/pdf/png output as well as screen-output.

BC

···

_______________________________________________
wxpython-users mailing list
wxpython-users@lists.wxwidgets.org
http://lists.wxwidgets.org/mailman/listinfo/wxpython-users

5

Frank Millman wrote:

Hi all

I am having fun learning how to draw a chart using BPMN (Business Process
Modelling Notation).

Here is a link to a poster showing all the symbols -

http://bpt.hpi.uni-potsdam.de/pub/Public/BPMNCorner/BPMN1_1_Poster_EN.pdf

Drawing the symbols in no real problem - some of them are quite challenging,
but that is part of the fun.

I am trying to work out how to do a HitTest, so that I can detect if the
user wants to drag a symbol. At this stage I am concentrating on a Circle.

GraphicsPath has a Contains() method - you pass it a Point, and it returns
True if the point is within the path, else False. This seems like the
obvious way to perform the test.

If you run the attached program, you will see that there are three circles.
One is a plain circle, the second has a thick transparent border, and the
third has a thick solid border.

Using gtk2, HitTest always returns None, no matter where I click. Maybe the
Contains() method is not supported on gtk2. [See my P.S. at the bottom]

Please add a bug report about this.

Using msw, HitTest works correctly, but it is actually cleverer than I want
it to be. The first circle works perfectly, the second two return True if I
click within the border, but False if I click in the centre of the circle. I
want a click anywhere within the outer circle to return True, but I cannot
figure out how to do it.

My guess is that it wasn't intended to act this way, so please enter a bug report about this too.

···

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

6

I am quite sure it was intended to act the way it does. The docs of Contains() say "Returns true if the point is within the path.". The last two circles are not two circles, but a ring. The area which is filled is considered "in", everything else "out".
For fc2, I definately want to have the current behaviour. However, it was nice if GraphicsPath had more Contains* methods. For example the current Contains() method returns False if I have a very thick border and click it. I doubt this is possibly to do with the underlying toolkits though.

-Matthias

···

Am 01.09.2008, 22:53 Uhr, schrieb Robin Dunn <robin@alldunn.com>:

Frank Millman wrote:

Using msw, HitTest works correctly, but it is actually cleverer than I want
it to be. The first circle works perfectly, the second two return True if I
click within the border, but False if I click in the centre of the circle. I
want a click anywhere within the outer circle to return True, but I cannot
figure out how to do it.

My guess is that it wasn't intended to act this way, so please enter a bug report about this too.

7

Addendum:

Use wx.GraphicsPath.Contains and set fillStyle to wx.WINDING_RULE instead of the default wx.ODDEVEN_RULE . Then you example works on msw.

-Matthias

···

Am 01.09.2008, 23:12 Uhr, schrieb Nitro <nitro@dr-code.org>:

Am 01.09.2008, 22:53 Uhr, schrieb Robin Dunn <robin@alldunn.com>:

Frank Millman wrote:

Using msw, HitTest works correctly, but it is actually cleverer than I want
it to be. The first circle works perfectly, the second two return True if I
click within the border, but False if I click in the centre of the circle. I
want a click anywhere within the outer circle to return True, but I cannot
figure out how to do it.

My guess is that it wasn't intended to act this way, so please enter a bug report about this too.

I am quite sure it was intended to act the way it does. The docs of Contains() say "Returns true if the point is within the path.". The last two circles are not two circles, but a ring. The area which is filled is considered "in", everything else "out".
For fc2, I definately want to have the current behaviour. However, it was nice if GraphicsPath had more Contains* methods. For example the current Contains() method returns False if I have a very thick border and click it. I doubt this is possibly to do with the underlying toolkits though.

8

So you recommend bypassing most of graphicscontext and use cairo directly?

I am interested since I am still evaluating the different methods of
drawing in wxpython.

/Chris

···

On Mon, Sep 1, 2008 at 10:27 PM, Bryan Cole <bryan@cole.uklinux.net> wrote:

FWIW, I recommend cairo for drawing on Windows as well as GTK, as the
API is great and you have svg/pdf/png output as well as screen-output.

9

Frank Millman wrote:

I have not tried FloatCanvas yet, as I have no requirement for numpy, and I
am trying to avoid too many dependencies.

don't be too afraid, numpy is very robust and easy to install. It's also very useful, even if you don't have a lot of numbers to crunch. The core of it really should be in the standard lib, but what can you do?

However, folks often do want to minimize dependencies. As I think about it numpy was pretty critical for FloatCanvas1, because it was used for all the zooming and scaling computation. However, with FC2, GraphicsContext is doing a lot of that -- I wonder how key it is now? Maybe pretty key, I think it's used for generating buffers for bitmaps and the like, too, but I'm not sure.

Matthias, what do you think? Is the numpy dependency still important?

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

10

Yes, it's very essential. The filtering capabilities use it, the transforms use it (especially the projection transforms), bounding boxes use it and probably more things.
Removing numpy would

a) be hard to remove from fc2, because we rely on it.
b) slow down fc2 too much in general.
c) I don't see a good reason to not use numpy. Python is too slow for math-intensive applications written in pure python. Numpy was written to help exactly this. 10 MB of extra dependencies are not noteworthy these days (if you use handphones or similar maybe, but then fc will be way too slow on them anyways). Numpy is a mature library, so including and relying on it should not be a problem.

-Matthias

···

Am 02.09.2008, 18:59 Uhr, schrieb Christopher Barker <Chris.Barker@noaa.gov>:

Frank Millman wrote:

I have not tried FloatCanvas yet, as I have no requirement for numpy, and I
am trying to avoid too many dependencies.

don't be too afraid, numpy is very robust and easy to install. It's also very useful, even if you don't have a lot of numbers to crunch. The core of it really should be in the standard lib, but what can you do?

However, folks often do want to minimize dependencies. As I think about it numpy was pretty critical for FloatCanvas1, because it was used for all the zooming and scaling computation. However, with FC2, GraphicsContext is doing a lot of that -- I wonder how key it is now? Maybe pretty key, I think it's used for generating buffers for bitmaps and the like, too, but I'm not sure.

Matthias, what do you think? Is the numpy dependency still important?

11

Nitro wrote:

···

Am 01.09.2008, 23:12 Uhr, schrieb Nitro <nitro@dr-code.org>:

Am 01.09.2008, 22:53 Uhr, schrieb Robin Dunn <robin@alldunn.com>:

Frank Millman wrote:

Using msw, HitTest works correctly, but it is actually cleverer than I want
it to be. The first circle works perfectly, the second two return True if I
click within the border, but False if I click in the centre of the circle. I
want a click anywhere within the outer circle to return True, but I cannot
figure out how to do it.

My guess is that it wasn't intended to act this way, so please enter a bug report about this too.

I am quite sure it was intended to act the way it does. The docs of Contains() say "Returns true if the point is within the path.". The last two circles are not two circles, but a ring. The area which is filled is considered "in", everything else "out".
For fc2, I definately want to have the current behaviour. However, it was nice if GraphicsPath had more Contains* methods. For example the current Contains() method returns False if I have a very thick border and click it. I doubt this is possibly to do with the underlying toolkits though.

Addendum:

Use wx.GraphicsPath.Contains and set fillStyle to wx.WINDING_RULE instead of the default wx.ODDEVEN_RULE . Then you example works on msw.

I was going to check the rule setting but forgot about it when I answered the email. Thanks!

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

12

> FWIW, I recommend cairo for drawing on Windows as well as GTK, as the
> API is great and you have svg/pdf/png output as well as screen-output.

So you recommend bypassing most of graphicscontext and use cairo directly?

Yes. The availability of cross-platform SVG output is the compelling
reason for me.

To use cairo on windows, you need to install libcairo.dll (+ libpng.dll,
as a dependency) and the pycairo pacakge.

For efficient construction of large paths, I have a compiled helper
module with functions like "Path_fromArray", to create a path from data
in a numpy array.

One caveat: I've not yet tested text-rendering on win32 or benchmarked
performance on this platform.

BC

···

On Tue, 2008-09-02 at 17:23 +0200, Christoffer Sørensen wrote:

On Mon, Sep 1, 2008 at 10:27 PM, Bryan Cole <bryan@cole.uklinux.net> wrote:

I am interested since I am still evaluating the different methods of
drawing in wxpython.

/Chris
_______________________________________________
wxpython-users mailing list
wxpython-users@lists.wxwidgets.org
http://lists.wxwidgets.org/mailman/listinfo/wxpython-users

13

Bryan Cole wrote:

Yes. The availability of cross-platform SVG output is the compelling
reason for me.

presumably you get PDF and other, too!

For efficient construction of large paths, I have a compiled helper
module with functions like "Path_fromArray", to create a path from data
in a numpy array.

Very nice! This could be just what we're looking for! Have you contributed that code to the pyCairo project? It should be doable without requiring any numpy headers (like was done for PIL, for instance). Using the array interface for transferring bitmaps to/from Cairo would be nice, too.

A couple questions:

* Is there a way to manipulate just part of a path once it is constructed? i.e. you make a path for a 1000pt polygon, and you want to change the location of the 564th point -- can you do that, or do you need to create a whole new path?

* Can you specify line widths in floating point? i.e. I want to specify a line width of say 0.01, and then have Cairo scale everything up to some reasonable size, like a factor of 200. The point would be to be able to use whatever coordinate system was natural to the user's data, then have Cairo do the scaling to the resolution desired.

* same question as above but for font sizes.

One caveat: I've not yet tested text-rendering on win32 or benchmarked
performance on this platform.

hmm -- well, it'll be interesting to see.

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

14

Frank Millman wrote:

Hi all

I am having fun learning how to draw a chart using BPMN
(Business Process
Modelling Notation).

[...]

I am trying to work out how to do a HitTest, so that I can
detect if the user wants to drag a symbol.

Many thanks to all for the really informative replies.

I can now get it working on msw using wx.WINDING_RULE (thanks, Matthias),
but it appears from Bryan's reply that it is not possible to get it working
on gtk2 using native wxPython and GraphicsContext.

As an alternative, I am looking at wx.Region, as this also has a Contains()
method. It looks promising, but there is something fundamental I do not
understand.

I can create a circular Region using RegionFromBitmap(), and it correctly
reports whether a particular mouse click is within the circle, on both
platforms.

However, I cannot figure out how to position the Region on the screen - it
defaults to (0,0). The other wx.Region constructors include positional
information in their arguments, but RegionFromBitmap does not.

In the attached program, the circles in the centre are given wx.Regions
based on rectangles. The one in the top left is given a wx.Region based on a
bitmap containing a circle.

HitTest works on the three circles in the centre, but it also returns True
(wx.InRegion) if you click in the four corners just outside the circle, but
within the rectangle. HitTest works correctly on the circle in the top left,
but I can't figure out how to position it anywhere else.

Any hints will be much appreciated.

Frank

bpmn12.py (2.86 KB)

15

Very nice! This could be just what we're looking for! Have you
contributed that code to the pyCairo project?

No, but this would indeed be the best home for it. Right now I just use
function calls, passing the Context and data-array as an argument.
Pycairo is a "proper" python extension with cairo objects wrapped into
compiled python types. These new functions should probably be added as
methods to the PyCairoContext object, however I'm kinda rusty on the
full details of defining python types in C.

It should be doable
without requiring any numpy headers (like was done for PIL, for
instance). Using the array interface for transferring bitmaps to/from
Cairo would be nice, too.

What interface does PIL use? buffer or array? I just used the numpy API
directly. I hope to maintain compatibility with py-2.4.

* Is there a way to manipulate just part of a path once it is
constructed? i.e. you make a path for a 1000pt polygon, and you want to
change the location of the 564th point -- can you do that, or do you
need to create a whole new path?

This is a bit tricky. The path data structure is a "ragged" C-array.
Adding extra points in would require recreating the array. Editing
existing points would be possible (probably) but accessing a point in
the middle of the array requires iteration over each item to get there
(because elements may have different lengths). Pycairo doesn't provide
any sort of access to the internal data, so this would need a new API.

If you created specialisation of the general Path, with a homogeneous
elements (i.e. all lines, no curves), you could arrange for direct,
random access. In any case, I think the overhead of recreating each path
from a python data structure is dwarfed by the cost of antialiased
rendering, so there's not too much value in attempting to maintain
direct access to the path internal data.

* Can you specify line widths in floating point? i.e. I want to specify
a line width of say 0.01, and then have Cairo scale everything up to
some reasonable size, like a factor of 200. The point would be to be
able to use whatever coordinate system was natural to the user's data,
then have Cairo do the scaling to the resolution desired.

* same question as above but for font sizes.

Everything in cairo is specified in floating point "user units" and is
designed to by fully scalable. This should also be true for wxGraphics*,
for that matter.

Robins "Tease" is a recent post suggests there's cross-platform
cairo-integration coming in a future wxPython release. I'd like know
what new features this will include.

BC

16

Frank Millman wrote:

However, I cannot figure out how to position the Region on the screen - it
defaults to (0,0). The other wx.Region constructors include positional
information in their arguments, but RegionFromBitmap does not.

wx.Region has the Offset method that lets you relocate where it's origin is located.

···

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

17

Robin Dunn wrote:

Frank Millman wrote:
> However, I cannot figure out how to position the Region on
the screen
> - it defaults to (0,0). The other wx.Region constructors include
> positional information in their arguments, but
RegionFromBitmap does not.

wx.Region has the Offset method that lets you relocate where
it's origin is located.

Perfect! Thank you.

Frank

18

Frank Millman wrote:

Frank Millman wrote:
I can now get it working on msw using wx.WINDING_RULE (thanks, Matthias),
but it appears from Bryan's reply that it is not possible to get it working
on gtk2 using native wxPython and GraphicsContext.

As an alternative, I am looking at wx.Region, as this also has a Contains()
method. It looks promising, but there is something fundamental I do not
understand.

Frank,

I think you may be going about this the wrong way -- so I offer an alternative.

The problem with all these methods is that you are using math to try to figure out whether an object is hit -- but once you try to include line width, filling, etc, you end up having to do as much work as drawing in the first place.

So, why not draw?

In FloatCanvas (version 1), hit testing is handled by drawing each "hitable" object on an offscreen bitmap in a unique color. When there is a mouse event, the color of the pixel where the mouse is is checked, and presto -- you know which (if any)object was hit.

There are some limitation to this method:
   1) you can only detect the top object of overlapping objects
   2) with anti-aliasing, an object can not be drawn in only one color. FC1 uses DCs, so this works. I don't know if anti-aliasing can be turned off with GCs.
   3) all hitable objects need to be drawn twice -- which can slow down rendering, though the hit-testing is blazingly fast!

Another route to take, which solves all of these problems (but may be slower to do a hit-test) is to maintain a small off-screen bitmap, then when you want to do a hit-test, you transform the coordinates so that the desired pixel is in the middle, draw each object to it, and check if the middle pixel changes color when the drawing is done. If you do a bounding box check first (or even better, use a spatial index) then you won't have to check many objects, and it should be plenty speedy for most use (MOUSE_MOVE events may be an issue.

At the end of the day, however, you'd still probably be better off using FloatCanvas 1 or 2 (or wxOGL, maybe), rather than figuring out how to solve all these issues yourself.

It's not the best time to get started with FC, as we are in a transition period -- FC1 does not support GCS very well, and FC is brand new and not fully tested and mature yet -- but we'd love to have a few more folks on board!

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer

NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

19

Christopher Barker wrote:

Frank Millman wrote:
> Frank Millman wrote:
> I can now get it working on msw using wx.WINDING_RULE (thanks,
> Matthias), but it appears from Bryan's reply that it is not
possible
> to get it working on gtk2 using native wxPython and GraphicsContext.
>
> As an alternative, I am looking at wx.Region, as this also has a
> Contains() method. It looks promising, but there is something
> fundamental I do not understand.

Frank,

I think you may be going about this the wrong way -- so I
offer an alternative.

The problem with all these methods is that you are using math
to try to figure out whether an object is hit -- but once you
try to include line width, filling, etc, you end up having to
do as much work as drawing in the first place.

So, why not draw?

Hi Chris, thanks for the info - I do appreciate the input.

A few points -

1. This is my first attempt at drawing, so I am definitely feeling my way. I
have looked at OGL and OGLLike, but a lack of documentation meant that I
could not be sure that they would give me all the functionality I need, and
I did not want to spend a lot of time only to find that it was wasted. I
also looked at DragImage and PseudoDC in the demo. I am particularly
impressed with PseudoDC - it works so smoothly, on gtk2 and on msw, but
again cannot be sure that it would give me what I need.

2. The attached program shows part of what I am trying to achieve. I have
actually got it working 'well enough' that I was ready to move on to other
things, so unless there is something fundamentally wrong with my approach I
am a bit reluctant to go back and revisit it now. How much effort would
there be in re-implementing this in FC? I am still getting some flicker on
msw, so if FC would help remove this it could be a reason to reconsider.

3. I may revise my entire approach anyway, depending on how my project
evolves. I am trying to create an 'executable' business process, which means
that the drawing must be saved in a structured format (probably xml) which
can be fed into a workflow engine, which I am writing at the same time.
Instead of allowing the user to manipulate the drawing directly, and
inferring the structure from the drawing, I may end up having the user
manipulate the structure, and then re-generate the drawing from the
structure after each change.

The jury is still out on the best way to accomplish this. Any comments will
be much appreciated.

Frank

bpmn13.py (13.4 KB)

20

Frank Millman wrote:

1. This is my first attempt at drawing, so I am definitely feeling my way. I
have looked at OGL and OGLLike, but a lack of documentation meant that I
could not be sure that they would give me all the functionality I need, and
I did not want to spend a lot of time only to find that it was wasted.

Well, it's more fun to write code than docs!

I don't know anything about OGL, but it sure looks like it was made for this sort of thing! Did you ask on the list? Do we know if the author (of the python version) is actively maintaining it or at least answering questions?

Anyway, I find myself doing this too, but I think it is a mistake -- if there is a lib that does most of what you want, and it is open source, I think it makes more sense to use that lib, and then add the feature or tow you may need, rather than starting from scratch -- unless your goal is to learn about drawing (or whatever)

also looked at DragImage

very minimal

and PseudoDC in the demo. I am particularly
impressed with PseudoDC - it works so smoothly, on gtk2 and on msw, but
again cannot be sure that it would give me what I need.

the question shouldn't be "will it give me what I need", but rather, "will it prevent me from building what I need" -- and I'd think a post or two to this list would probably answer that for you.

PsuedoDC is limited to DCs, so if you need any of the featured unique to GraphicsContext (anti-aliasing, alpha-blending, complex paths), it's probably not the way to go. It's still a lot more low-level that FloatCanvas or OGL though. I might have build FC on top of it if it had existed when I wrote FC. Though DCs inherently don't support full zooming and scaling, so perhaps not.

2. The attached program shows part of what I am trying to achieve. I have
actually got it working 'well enough' that I was ready to move on to other
things, so unless there is something fundamentally wrong with my approach I
am a bit reluctant to go back and revisit it now.

well, I think that question is: how many more features might you need? scaling? panning? more complex draw objects, etc. The nice thing about using a more feature lib is that you can get a lot of these features fro free -- even if you don't need them when you get started.

How much effort would
there be in re-implementing this in FC? I am still getting some flicker on
msw, so if FC would help remove this it could be a reason to reconsider.

From a quick look, this would be pretty easy to do in FC1 (I'm not as sure about FC2 -- it's brand new). The best way to check it out is to take a look at the demos in the source (I don't think all the little ones are distributed with wxPython right now):

http://svn.wxwidgets.org/viewvc/wx/wxPython/3rdParty/FloatCanvas/Demos/

MovingElements.py

Should get you started. You can ask specific questions on the floatcanvas mailing list.

It may be quite doable with FC2 as well -- ask on the list. I'm not yet up to speed with that.

3. I may revise my entire approach anyway, depending on how my project
evolves. I am trying to create an 'executable' business process, which means
that the drawing must be saved in a structured format (probably xml) which
can be fed into a workflow engine, which I am writing at the same time.
Instead of allowing the user to manipulate the drawing directly, and
inferring the structure from the drawing, I may end up having the user
manipulate the structure, and then re-generate the drawing from the
structure after each change.

The jury is still out on the best way to accomplish this. Any comments will
be much appreciated.

This seems to be begging for an MVC (or MVP) structure -- you need a data model, and that model could be manipulated in more than one way -- with the GUI, or otherwise programmaticly.

FC2 was designed with MVC in mind, so it may be a bit easier, but you could certainly do it with FC1 too.

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer

NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception