So, what's wrong with wxOGL and wxCanvas for the object canvas? It would be
nice to have the reasons stated clearly, so we can use that as part of our
design guidelines for a new object canvas.
Bad APIs, missing functionality, too slow? I haven't used either, so I don't
know the issues or why Chris ended up writing his own object canvas. About
all I know is that Cliff Wells had a lot of issues with getting wxOGL to do
what he wanted.
ka
Kevin Altis wrote:
So, what's wrong with wxOGL and wxCanvas for the object canvas? It would be
nice to have the reasons stated clearly, so we can use that as part of our
design guidelines for a new object canvas.Bad APIs, missing functionality, too slow? I haven't used either, so I don't
know the issues or why Chris ended up writing his own object canvas.
Honestly, I didn't look nearly as hard at wxOGL as I should have. At
first glance, it looked very much designed for drawing the kind of
things you'd need for a CASE tool, which is what, it was designed for.
It didn't look to me that it would be suitable as a general purpose
drawing framework, but that may just be function of the examples I had
seen. I really didn't look very hard. On the other hand, drawing in
Floating Point coordinates is critical for my purposes, so I think it
would fail in that regard anyway. In addition to floating point
coordinates one of my uses is for drawing map stuff, in latitude,
longitude coordinates, which requires a transformation (projection) from
a sphere to a flat surface.
As for wxCanvas (are you talking about Klass' canvas?), it simply wasn't
ready when I started my project. I have intended to keep an eye on it,
as it looks like Klass has done some fabulous work. One issue I had is
that for my purpose, I generally need to represent data as a picture,
rather than drawing a picture for its own sake. These are similar, but
there are differences in the details of what features you need. For
example, when specifying the line width with which to draw a polygon, I
usually want to specify the width in pixels, and have the width not
change when zooming. This is because when zoomed out you need the line
to be fat enough to see, but when zoomed in, you want to be able to see
more detail, and thus need a thinner line. When drawing a picture,
rather than data, you want the line widths to scale with everything else
when zooming in and out. Klass' original motivation for the canvas was a
drawing tool, so that's how it works. We discussed supporting both
approaches, and there were some difficulties, mostly around how you
would compute bounding boxes accurately, etc. I don't know if he ended
up supporting constant line widths or not.
Another issue for me is that neither option was exactly what I needed,
and both are in C++, so I would need to use C++ to add to them to fit my
needs, and I'm not a C++ programmer. In the long run, I'm hoping to get
one of my colleagues working on a C++ canvas, which might follow my
Python code, but might also be based on either xwOGL or wxCanvas. I'm
not sure when, if ever that will happen, however, I'm still trying to
sell wxWindows/wxPython to my group.
By the way, I have not followed wxCanvas development for a while: is it
ready to be wrapped for wxPython?
I'd love to hear what uses people have found for wxOGL, and what their
experiences are.
-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
Chris.Barker@noaa.gov
I haven't worked on that stuff in a few weeks, so I don't recall all of the
issues, but a couple that come to mind:
1) Poor documentation. I have no real complaint about the other wxWindows
docs, so this should be some indication of its quality.
2) Limitations in how objects are placed. All objects are placed relative to
the center of the shape and it can be difficult to place a shape relative
to an edge (even with rectangular shapes). Floating-point coordinates
might help some in thisrespect (to avoid round-off errors when computing
the coordinates of a point on a shape), but it would be better to be able
to place shapes by any point on the shape rather than just its center.
3) Poor documentation. Really, really poor. I still have no idea what 80%
of the library is for or how to use it.
Other than this, I did find that wxOGL has uses far beyond the obvious one of
doing diagram-type layouts (as Kevin knows, I was using it as the framework
for a dialog editor), so it would be nice to see the API explained better. It
is certainly very fast and with some work could be one of the more useful parts
of wx.
I think even the developers of wxOGL were rather short-sighted on the potential
uses wxOGL could be put to. For instance, the docs insist that a wxBitmapShape
can't be resized, but in fact, with a little coding, this is _easily_
implemented.
Maybe I'll make a simple dialog editor (based on the one I was working on) for
the wxPython demo. It wouldn't have much practical use, but might expand
people's perception of wxOGL. Robin - interested?
On Tue, 16 Apr 2002 10:09:41 -0700 Kevin Altis wrote:
So, what's wrong with wxOGL and wxCanvas for the object canvas? It would be
nice to have the reasons stated clearly, so we can use that as part of our
design guidelines for a new object canvas.Bad APIs, missing functionality, too slow? I haven't used either, so I don't
know the issues or why Chris ended up writing his own object canvas. About
all I know is that Cliff Wells had a lot of issues with getting wxOGL to do
what he wanted.
--
Cliff Wells, Software Engineer
Logiplex Corporation (www.logiplex.net)
(503) 978-6726 x308 (800) 735-0555 x308
Cliff Wells wrote:
3) Poor documentation. Really, really poor. I still have no idea what 80%
of the library is for or how to use it.
I think that explains why I never looked too far into it. With limited
docs and limited examples, I had no indication that it might be "just
what I was looking for!"
Other than this, I did find that wxOGL has uses far beyond the obvious one of
doing diagram-type layouts (as Kevin knows, I was using it as the framework
for a dialog editor), so it would be nice to see the API explained better. It
is certainly very fast and with some work could be one of the more useful parts
of wx.
A little more research is required, and maybe it could be the basis for
a general purpose object canvas.
-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
Chris.Barker@noaa.gov
> So, what's wrong with wxOGL and wxCanvas for the object canvas? It would
be
> nice to have the reasons stated clearly, so we can use that as part of
our
> design guidelines for a new object canvas.
>
> Bad APIs, missing functionality, too slow? I haven't used either, so I
don't
> know the issues or why Chris ended up writing his own object canvas.
Honestly, I didn't look nearly as hard at wxOGL as I should have. At
first glance, it looked very much designed for drawing the kind of
things you'd need for a CASE tool, which is what, it was designed for.
Yes.
It didn't look to me that it would be suitable as a general purpose
drawing framework,
Probably not. Plus doing all event handling with C++ virtuals makes the
Python wrapper real heavy.
As for wxCanvas (are you talking about Klass' canvas?), it simply wasn't
ready when I started my project.
And still hasn't been put into CVS. I get the impression that it is still a
moving target.
Another issue for me is that neither option was exactly what I needed,
and both are in C++, so I would need to use C++ to add to them to fit my
needs, and I'm not a C++ programmer. In the long run, I'm hoping to get
one of my colleagues working on a C++ canvas, which might follow my
Python code, but might also be based on either xwOGL or wxCanvas. I'm
not sure when, if ever that will happen, however, I'm still trying to
sell wxWindows/wxPython to my group.
Perhaps a low-level engine in C++ upon which things like wxOGL or wxCanvas
could be built in Python?
By the way, I have not followed wxCanvas development for a while: is it
ready to be wrapped for wxPython?
I havn't looked any new code for a while. Last I did I felt that at least a
subset of the classes could be wrapped without too much hassle, but I was
under the impression that there were several more things he was going to
change so I've been reluctant to start.
--
Robin Dunn
Software Craftsman
robin@AllDunn.com Java give you jitters?
http://wxPython.org Relax with wxPython!