[wxPython] crashing demo

I get a stack overflow in the demo when trying the activex adobe demo.
In the dos window I see

C:\Python\wxPython\demo>python demo.py
Traceback (innermost last):
  File "Main.py", line 264, in OnSelChanged
    self.RunDemo(itemText)
  File "Main.py", line 286, in RunDemo
    module = __import__(itemText, globals())
  File "ActiveXWrapper_Acrobat.py", line 25, in ?
    raise ImportError("Can't load PDF.OCX, install Acrobat 4.0")
ImportError: Can't load PDF.OCX, install Acrobat 4.0

but I do have PDF 4.0 installed in the registry it's the inproc32 server
C:\Program Files\Adobe\Acrobat 4.0\Reader\ActiveX\pdf.ocx

I'm using win98 second edition.

···

--
Robin Becker

Hi,

I'm using a wxScrolledWindow to create a zoomable drawing canvas (it is
to look at maps, but that's no relevant to the problem). I do this by
creating a zoom method, that changes the maxWidth and maxHeight of the
scrolled window, rescaled the stuff I'm drawing, then scrolls the window
to where I want it.

The problem is that the window re-paints itself a hwole bunch of times,
makeing it flash, and be kind of slow when there is lots of stuff in the
window. I put a few diagnostic "prints" in the code, and found that the
PAINT event is called four times when I zoom. How do I stop the window
from repainting until I'm done with all the zooming and scrolling?

I've enclosed the code, trimmed down as much as I could do easily. You
zoom in by clicking with the right mouse button, or using the menu.
(zoom out with the left button)

By the way, Robin, what changed with the drawing code in version 2.1.16?
I now have to assign EVT_PAINT(no big deal), and it seems to be quite a
bit faster! (Linux, wxGTK)

-Chris

draw_test3.py (5.79 KB)

···

--
Christopher Barker,
Ph.D.
cbarker@jps.net --- --- ---
http://www.jps.net/cbarker -----@@ -----@@ -----@@
                                   ------@@@ ------@@@ ------@@@
Water Resources Engineering ------ @ ------ @ ------ @
Coastal and Fluvial Hydrodynamics ------- --------- --------
------------------------------------------------------------------------
------------------------------------------------------------------------

on my system (Win2K, wxPython 2.1.16), this code behaves reasonably (i.e. one call to PAINT per zoom).

-greg

···

At 12:10 PM 6/28/2000 -0700, Chris Barker wrote:

The problem is that the window re-paints itself a hwole bunch of times,
makeing it flash, and be kind of slow when there is lots of stuff in the
window. I put a few diagnostic "prints" in the code, and found that the
PAINT event is called four times when I zoom. How do I stop the window
from repainting until I'm done with all the zooming and scrolling?

----
greg Landrum (greglandrum@earthlink.net)
Software Carpenter/Computational Chemist

I see the same behaviour here. After a bit of investigation I think I've
tracked it down to the SetScrollBar and Scroll calls in zoom. The former
causes one Refresh() call, while the later causes two more (one for each
scrollbar apparently. I got down to one call per zoom by (a) folding the
Scroll call into the SetScrollBar call and (b) commenting out the Refresh()
call.

While I was messing with it I also tossed in some double buffering code I've
used in another (nonscrolled) ap. I've attached the modified version of your
file. Feel free to use or toss any of the changes as you see fit.

-tim

draw_test3.py (6.37 KB)

···

I'm using a wxScrolledWindow to create a zoomable drawing canvas (it is
to look at maps, but that's no relevant to the problem). I do this by
creating a zoom method, that changes the maxWidth and maxHeight of the
scrolled window, rescaled the stuff I'm drawing, then scrolls the window
to where I want it.

The problem is that the window re-paints itself a hwole bunch of times,
makeing it flash, and be kind of slow when there is lots of stuff in the
window. I put a few diagnostic "prints" in the code, and found that the
PAINT event is called four times when I zoom. How do I stop the window
from repainting until I'm done with all the zooming and scrolling?

I've enclosed the code, trimmed down as much as I could do easily. You
zoom in by clicking with the right mouse button, or using the menu.
(zoom out with the left button)

By the way, Robin, what changed with the drawing code in version 2.1.16?
I now have to assign EVT_PAINT(no big deal), and it seems to be quite a
bit faster! (Linux, wxGTK)

-Chris

----------------------------------------
Content-Type: text/plain; name="draw_test3.py"
Content-Transfer-Encoding: 7bit
Content-Description:
----------------------------------------

--

regards,

Tim Hochberg

Hochberg & Associates | (tim.hochberg@ieee.org)|

Hi,

I'm using MDIParentFrame that have menubar which is can call a
wxMDIChildFrame.
In wxMDIChild frame i create text control where the user can enter their
name , addres or etc.

The problem is that the wxTextCtrl in wxMDIChildFrame cannot move to next
entry when u press tab or enter button.

Another problem in wxMDIChildFrame cannot appear wxHtmlWindow in first
intialize but when resize, then html document should okay.

Robin,
I have change but still get a same problem. Do u have any example programme
that i can refer .

Sorry for bad english...

Irwan Azam
ISP/Support System
Telekom Multimedia
Malaysia
603-7074538

Bulk2.py (13.1 KB)

Robin,
I have change but still get a same problem. Do u have any example

programme

that i can refer .

Here is the solution I was describing before:

class MyMiniFrame(wxMDIChildFrame):
    def __init__(self, parent, ID, title, pos, size, style):
        wxMDIChildFrame.__init__(self, parent, ID, title, pos, size, style)

        panel = wxPanel(self, -1)

        wxStaticText(panel, -1, "Name:",
                     wxDLG_PNT(panel, wxPoint(4, 15)), wxDefaultSize)
        wxStaticText(panel, -1, "Address:",
                     wxDLG_PNT(panel, wxPoint(4, 25)), wxDefaultSize)

        wxStaticText(panel, -1, "Position", wxPoint(4, 70), wxSize(75, 20))

        self.sizeCtrl = wxTextCtrl(panel, -1, "",
                                  wxDLG_PNT(panel, wxPoint(27, 15)),
                               wxDLG_SZE(panel, wxSize(100, -1)),
style=wxTE_PROCESS_ENTER)
        self.sizeCtrl.SetFocus()

        self.posCtrl = wxTextCtrl(panel, -1, "",
                                 wxDLG_PNT(panel, wxPoint(27, 25)),
                                 wxDLG_SZE(panel, wxSize(150, -1)),
style=wxTE_PROCESS_ENTER)

        self.getCtrl=wxTextCtrl(panel, 10, "", wxPoint(80, 70), wxSize(150,
20), style=wxTE_PROCESS_ENTER)

        self.okay=wxButton(panel,1000,"Okay")
        self.okay.SetPosition(wxPoint(4,100))

        EVT_BUTTON(self,1000,self.OnWriteFile)

        self.cancel=wxButton(panel,1001,"Cancel")
        self.cancel.SetPosition(wxPoint(104,100))

        EVT_BUTTON(self,1001,self.OnCancel)

There is still a problem. When the first wxMDIChildFrame initialize there is
nothing on that panel, but when u resize or click the maximize button then
wxTextCtrl can work.

Thanks for your example.

There is still a problem. When the first wxMDIChildFrame initialize there

is

nothing on that panel, but when u resize or click the maximize button then
wxTextCtrl can work.

That is a bug that has been fixed already since the last release. To work
aroud it until the next release you need to force a resize of the
wxMDIChildFrame after it has the panel. Something like this should do it:

    sz = self.GetSize()
    self.SetSize( (sz.width-1, sz.height) )

···

--
Robin Dunn
Software Craftsman
robin@AllDunn.com
http://wxpython.org Java give you jitters?
http://wxpros.com Relax with wxPython!

In article <G46KfAAd1bW5Ew+Y@jessikat.demon.co.uk>, Robin Becker
<robin@jessikat.co.uk> writes

I get a stack overflow in the demo when trying the activex adobe demo.
In the dos window I see

C:\Python\wxPython\demo>python demo.py
Traceback (innermost last):
File "Main.py", line 264, in OnSelChanged
   self.RunDemo(itemText)
File "Main.py", line 286, in RunDemo
   module = __import__(itemText, globals())
File "ActiveXWrapper_Acrobat.py", line 25, in ?
   raise ImportError("Can't load PDF.OCX, install Acrobat 4.0")
ImportError: Can't load PDF.OCX, install Acrobat 4.0

but I do have PDF 4.0 installed in the registry it's the inproc32 server
C:\Program Files\Adobe\Acrobat 4.0\Reader\ActiveX\pdf.ocx

I'm using win98 second edition.

I tried the same demos on my win95 box and each time get a crash. Not
only that I seem to lock up huge amounts of memory and then fail to
reboot cleanly. Has anyone else had these kinds of problems?

···

--
Robin Becker

I've seen this kind of effect in my program too. And it only happens on
Linux/wxGTK, but not on MSW. What happens in my case is I load and display
an image and then I draw graphics (lines and rectangles) over the image.
The multiple redraws happen when I display a dialog box and drag it across
the image where it and the graphics have to repaint them selves. Then there
is this flickering effect of multiple redraws. The more graphics drawn, the
more it flickers.

The worst case seems to be when I display a rectangle and a modeless dialog
box. When I move the rectangle with a mouse, data is updated in the dialog
box. If I have several of these rectanges displayed, each having its own
dialog box, and I drag one of the dialog boxes over the image, the
flickering can last several seconds.

I'm using wxPanel inside a wxFrame. Everything is displayed in the Panel.
I've messed around with it for several day at one point but got nowhere.
Fortunately my customers are all Windows users and as I said before it
doesn't happen on MSW.

Bob

···

At 12:10 PM 6/28/00 -0700, you wrote:

Hi,

I'm using a wxScrolledWindow to create a zoomable drawing canvas (it is
to look at maps, but that's no relevant to the problem). I do this by
creating a zoom method, that changes the maxWidth and maxHeight of the
scrolled window, rescaled the stuff I'm drawing, then scrolls the window
to where I want it.

The problem is that the window re-paints itself a hwole bunch of times,
makeing it flash, and be kind of slow when there is lots of stuff in the
window. I put a few diagnostic "prints" in the code, and found that the
PAINT event is called four times when I zoom. How do I stop the window
from repainting until I'm done with all the zooming and scrolling?

I've enclosed the code, trimmed down as much as I could do easily. You
zoom in by clicking with the right mouse button, or using the menu.
(zoom out with the left button)

By the way, Robin, what changed with the drawing code in version 2.1.16?
I now have to assign EVT_PAINT(no big deal), and it seems to be quite a
bit faster! (Linux, wxGTK)

-Chris

--
Christopher Barker,
Ph.D.
cbarker@jps.net --- --- ---
http://www.jps.net/cbarker -----@@ -----@@ -----@@
                                  ------@@@ ------@@@ ------@@@
Water Resources Engineering ------ @ ------ @ ------ @
Coastal and Fluvial Hydrodynamics ------- --------- --------
------------------------------------------------------------------------
------------------------------------------------------------------------#!/u
sr/bin/env python

from wxPython.wx import *

import random

ID_ABOUT = 101
ID_EXIT = 102
ID_ZOOM_IN = 104
ID_ZOOM_OUT = 105
ID_ZOOM_TO_FIT = 106

class AppWindow(wxFrame): # The Main Window of the Application
def __init__(self, parent, ID, title):
  wxFrame.__init__(self, parent, ID, title,
                                   wxDefaultPosition, wxSize(500, 500))
  self.CreateStatusBar()
  self.SetStatusText("")
  
  file_menu = wxMenu()
  file_menu.Append(ID_EXIT, "E&xit","Terminate the program")

  view_menu = wxMenu()
  view_menu.Append(ID_ZOOM_IN, "Zoom &In","Zoom in")
  view_menu.Append(ID_ZOOM_OUT, "Zoom &Out","Zoom out")
  view_menu.Append(ID_ZOOM_TO_FIT, "Zoom to &Fit","Zoom to fit the window")

  help_menu = wxMenu()
  help_menu.Append(ID_ABOUT, "&About",
        "More information About this program")
  
  menuBar = wxMenuBar()
  menuBar.Append(file_menu, "&File")
  menuBar.Append(view_menu, "&View")
  menuBar.Append(help_menu, "&Help")
  
  self.SetMenuBar(menuBar)
  
  EVT_MENU(self, ID_ABOUT, self.OnAbout)
  EVT_MENU(self, ID_EXIT, self.TimeToQuit)
  EVT_MENU(self, ID_ZOOM_IN, self.zoom_in)
  EVT_MENU(self, ID_ZOOM_OUT, self.zoom_out)
  EVT_MENU(self, ID_ZOOM_TO_FIT, self.zoom_to_fit)
  
def OnAbout(self, event):
  dlg = wxMessageDialog(self, "This is a test program that tests\n"
              "out a zooming scrolled window\n",
              "About Me", wxOK | wxICON_INFORMATION)
  dlg.ShowModal()
  dlg.Destroy()

def zoom_in(self,event):
  self.map_win.Zoom(event,2.0)
def zoom_out(self,event):
  self.map_win.Zoom(event,0.5)
def zoom_to_fit(self,event):
  self.map_win.Zoom_to_fit()

def TimeToQuit(self, event):
  self.Close(true)
  
class Map_win(wxScrolledWindow):
def __init__(self, parent, id = -1, size = wxDefaultSize):
  wxScrolledWindow.__init__(self, parent, id, wxPoint(0, 0), size,
wxSUNKEN_BORDER)
  
  self.maxWidth = self.GetClientSize().width
  self.maxHeight = self.GetClientSize().height

  EVT_PAINT(self, self.OnPaint)
  EVT_LEFT_DOWN(self, self.OnLeftButtonEvent)
  EVT_RIGHT_DOWN(self, self.OnRightButtonEvent)

  self.SetBackgroundColour(wxNamedColor("BLACK"))
  
  self.SetCursor(wxStockCursor(wxCURSOR_CROSS))
  
  self.SetScrollbars(20, 20, self.maxWidth/20, self.maxHeight/20)

def OnPaint(self, event=0):
  print "\nOnPaint has been called"
  dc = wxPaintDC(self)
  self.PrepareDC(dc)
  self.DoDrawing(dc)

def DoDrawing(self, dc):
  print "DoDrawing has been called"
  dc.BeginDrawing() # I think this only makes a difference in MSW
  dc.SetBackground(wxCYAN_BRUSH)
  dc.Clear()
  dc.SetPen(wxBLACK_PEN)
  #check aspect ratio
  if (self.maxWidth/self.maxHeight < bb_delta_x / bb_delta_y):
    convert = self.maxWidth / float((bb_delta_x))
  else:
    convert = self.maxHeight / float((bb_delta_y))
  
  for polygon in polygons:
    #convert to pixel coordinates
    polygon_p =
    for point in polygon:
      polygon_p.append((int(convert * point[0]),int(convert*point[1])))
    dc.SetBrush(wxBrush(wxNamedColour('RED')))
    dc.DrawPolygon(polygon_p)
  dc.EndDrawing()

def ConvertCoords(self,x,y):
  xView, yView = self.ViewStart()
  xDelta, yDelta = self.GetScrollPixelsPerUnit()
  return (x + (xView * xDelta),y + (yView * yDelta))

def Zoom(self,event,factor):
  print "\nZoom has been called"
  zoom_limit = 4000.0
  width = self.GetClientSize().width
  height = self.GetClientSize().height
  try:
    if event.IsButton: # Mouse event, center on position
      center_x,center_y = self.ConvertCoords(event.GetX(),event.GetY())
  except AttributeError: # probably a menu event, center on window
    center_x,center_y = self.ConvertCoords(width/2,height/2)
  if factor > 1: #zooming in
    if (self.maxWidth*factor > zoom_limit or
        self.maxHeight*factor > zoom_limit):
      #reset factor to limit
      factor = zoom_limit/self.maxWidth
      self.maxWidth = int(self.maxWidth*factor)
      self.maxHeight = int(self.maxHeight*factor)
      center_x,center_y = center_x*factor,center_y*factor
    else:
      self.maxWidth = int(self.maxWidth*factor)
      self.maxHeight = int(self.maxHeight*factor)
      center_x,center_y = center_x*factor,center_y*factor
  else: # zooming out
    if (self.maxWidth*factor < width and
        self.maxHeight*factor < height):
      self.maxWidth = width
      self.maxHeight = height
      center_x,center_y = self.ConvertCoords(width/2,
                         height/2)
    else:
      self.maxWidth = int(self.maxWidth*factor)
      self.maxHeight = int(self.maxHeight*factor)
      center_x,center_y = center_x*factor,center_y*factor
  # compute where to scroll to center image
  xDelta, yDelta = self.GetScrollPixelsPerUnit()
  scroll_x = (center_x - width/2)/xDelta
  scroll_y = (center_y - width/2)/yDelta
  self.SetScrollbars(20, 20, self.maxWidth/20, self.maxHeight/20)

  #dc = wxClientDC(self)

  #self.DoDrawing(wxClientDC(self))
  self.Scroll(scroll_x,scroll_y)
  self.Refresh()

def Zoom_to_fit(self):
  self.maxWidth = self.GetClientSize().width
  self.maxHeight = self.GetClientSize().height
  self.DoDrawing(wxClientDC(self))
  self.SetScrollbars(20, 20, self.maxWidth/20, self.maxHeight/20)
  self.Refresh()

def OnLeftButtonEvent(self,event):
  self.Zoom(event,2.0)
def OnRightButtonEvent(self,event):
  self.Zoom(event,0.5)
  
class MyApp(wxApp):
def OnInit(self):
  frame = AppWindow(NULL, -1, "Map Display Tool")
  self.map_win = Map_win(frame,-1,frame.GetClientSize())
  frame.map_win = self.map_win
  frame.Show(true)
  
  self.SetTopWindow(frame)
  
  return true

# Build a list of polygons
polygon = [(20,15),
    (30,32.5),
    (20,50),
    (40,50),
    (50,65),
    (60,50),
    (80,50),
    (70,32.5),
    (80,15),
    (60,15),
    (50,0),
    (40,15)]
polygons =
for i in range(100):
dxdy = (random.randint(0,500),random.randint(0,500))
polygons.append(map(lambda xy,dxdy: (xy[0]+dxdy[0],xy[1]+dxdy[1]),
polygon,[dxdy]*len(polygon)))

bb_delta_x = 500
bb_delta_y = 500

app = MyApp(0)
app.MainLoop()

-------------------------------------------------
Robert B. Klimek
NASA Glenn Research Center
robert.klimek@grc.nasa.gov
(216) 433-2837
--------------------------------------------------

Thanks Greg, Tim, and Robert.

It is odd that the GTK version and MSW version behaves differently in
this way. Perhaps I'll post a question to the wxWindows list, and see if
anyone has any clues.

Tim, thanks for the code improvements. putting the Scroll commands into
SetScrollbars was just what I needed. As for my explicit refresh(), I'm
pretty sure that was needed at some point, but my demo seems to work
without it, so I'll try leaving it out.

As for your double-buffering scheme. I had tried something like that,
but kept the memDC outside of the DoDrawing method, and had it
(maxWidth,maxHeight) in size. This made it scroll really fast, (OnPaint
just called a blit), but I had memory problems if it got too big, so I
canned it.

With your approach, what is the advantage of using the double buffering
at all? it still has to re-draw every time (try it with 500 polygons, it
can get pretty slow). Also, is there any penalty to re-creating the
wxEmptyBitmap and wxMemoryDC everytime, rather than only when it changes
size?

-Chris

···

--
Christopher Barker,
Ph.D.
cbarker@jps.net --- --- ---
http://www.jps.net/cbarker -----@@ -----@@ -----@@
                                   ------@@@ ------@@@ ------@@@
Water Resources Engineering ------ @ ------ @ ------ @
Coastal and Fluvial Hydrodynamics ------- --------- --------
------------------------------------------------------------------------
------------------------------------------------------------------------

I've been having problems with wxScrolledWindow do a whole lot of extra
refreshes under wxGTK (apparently there is not the same problem under
wxMSW) see an earlier thread for the discussion (Re: [wxPython] Keeping
scroll window from redrawing when Idon't want it to).

I looked again at the docs, and noticed:

void SetScrollbars(int pixelsPerUnitX, int pixelsPerUnitY, int noUnitsX,
int noUnitsY, int xPos = 0, int yPos = 0, bool noRefresh = FALSE)

I've tried setting noRefresh to 1 in wxPython with the line:

self.SetScrollbars(20,20,40,40,20,20,1)

TypeError: wxScrolledWindow_SetScrollbars requires at most 7 arguments;
8 given

I'm only giving it 7 arguments, so I'm confused.

In general, what do you use for a C++ bool?

-Chris

···

--
Christopher Barker,
Ph.D.
cbarker@jps.net --- --- ---
http://www.jps.net/cbarker -----@@ -----@@ -----@@
                                   ------@@@ ------@@@ ------@@@
Water Resources Engineering ------ @ ------ @ ------ @
Coastal and Fluvial Hydrodynamics ------- --------- --------
------------------------------------------------------------------------
------------------------------------------------------------------------

void SetScrollbars(int pixelsPerUnitX, int pixelsPerUnitY, int noUnitsX,
int noUnitsY, int xPos = 0, int yPos = 0, bool noRefresh = FALSE)

That last parameter must not have been there originally as it's not defined
for the wrapper... I've added it now for the next release.

I've tried setting noRefresh to 1 in wxPython with the line:

self.SetScrollbars(20,20,40,40,20,20,1)

TypeError: wxScrolledWindow_SetScrollbars requires at most 7 arguments;
8 given

I'm only giving it 7 arguments, so I'm confused.

When the C++ function is called self is also passed which brings the total
count to 8.

In general, what do you use for a C++ bool?

An integer.

···

--
Robin Dunn
Software Craftsman
robin@AllDunn.com
http://wxpython.org Java give you jitters?
http://wxpros.com Relax with wxPython!

I know this is off-topic, but I sent this note, and got this reply from
David Ascher at ActiveState:

# Begin enclosed note#

···

#

Do you intend to keep Active Python (and Komodo and VisualPython
generated code) compatable with the open-source version? If so, it would
hep allay the fears of folks worried about comercial companies
"highjacking" Python.

Of course. We have no interest in hijacking anything. We will work
with
the rest of the Python development team to avoir incompatibilities. We
see our work as providing convenient distributions, and providing
add-ons
to the core.

Are you planning on adding the Macintosh to your list of supported
platforms. One of Python's strengths is its platform independence, and
the Mac is not dead as a platform. Mac hardware is getting to be very
powerfull, and particularly with OSX coming, its use as a server
platform is increasing.

OSX is definitely interesting to us. We don't currently have the
resources necessary to do "ActivePython on the mac" well (speaking of
the
"old" MacOS). Our choice of distributions is also primarily driven by
customer demand. I'll definitely record your request for a mac version,
and if enough folks like you ask, then we'll see what we can do!

Thanks a lot for your feedback,

-- David Ascher

# End Enclosed Note.

So, they are not intending to fork the code, or anything destructive
like that. I was also very glad to see that David Ascher is involved. He
has beeen a strong member of the Python community for a long time.

-Chris

--
Christopher Barker,
Ph.D.
cbarker@jps.net --- --- ---
http://www.jps.net/cbarker -----@@ -----@@ -----@@
                                   ------@@@ ------@@@ ------@@@
Water Resources Engineering ------ @ ------ @ ------ @
Coastal and Fluvial Hydrodynamics ------- --------- --------
------------------------------------------------------------------------
------------------------------------------------------------------------

Hi folks,

There is a movement affoot on the wx-develpers list to build a Canvas
widget for high level drawing, borrowing many ideas from the TK canvas.
As I think this is a widget that would be highly used by the wxPython
community, I've decided to get some feedback here. I am compiling a list
of features that we would like to see in this new canvas. I have no idea
how many of them will get implimented, but we might as well start with a
wish list! By the way, if any of you are good C++ coders, this would be
a great thing to contribute to!

wxCanvas is a class that provides a way to draw in a window, and
interact with that drawing at a very high level. Primary consideration
will be for display on the screen, but printing of the currently
displayed image will be provided as well. In the long run, screen
drawing will be well optimised to be fast on all supported platforms.
The Canvas will be zoomable and scrollable. The coordinate system of the
canvas will be setable by the user, so that drawing can be done in any
units.

A complete drawing will be made up of individual objects. These objects
will be persistant, so that they can individually be altered,
re-ordered, or deleted, with the canvas itself taking care of all the
re-drawing required.

Individual objects can be either vector or raster based. Some of the
supported objects will be:

Ellipses
Rectangles (rounded?)
Polylines
Polygons
Splines (or should "splined" be a property of a polyline(gon) ?

These will have properties like LineColor, LineStyle, FillColor,
FillStyle, etc...

Text (with foreground/background colours, size, and font)

Points (individual pixels)

Bitmaps (wxImages?)

Windows (such as wxTextCtrl, etc.)
Controls (Buttons, etc.)

Individual objects can be combined to form a higher level object that
can be treated as a single object. These individual "group" objects can
each have their own coordinate system.

Objects can have callbacks assigned to them (such as mouse click events)

Multiple objects can be created with a single call like:

        /* pseudocode*/
DrawRectangles(ListofCoordinates,ListofProperties).

Well, that's all I have for the moment. Please send your comments and
suggestions.

-Chris

···

--
Christopher Barker,
Ph.D.
cbarker@jps.net --- --- ---
http://www.jps.net/cbarker -----@@ -----@@ -----@@
                                   ------@@@ ------@@@ ------@@@
Water Resources Engineering ------ @ ------ @ ------ @
Coastal and Fluvial Hydrodynamics ------- --------- --------
------------------------------------------------------------------------
------------------------------------------------------------------------

Yes, sounds very useful.

Sounds like a 2D diagramming canvas - like Visio. I think that sort of
thing is useful for lots of different appliations (hence MS adding Visio to
Office).

Movement quality (smoothness, speed) is important in this sort of
application - for when a user moves an object. It would also be nice if
lines connecting objects adjusted when moved.

I've made a few other comments on your suggestions below.

Thanks to all involved,

Tom.

"Chris Barker" <cbarker@jps.net> wrote in message
news:39AEEB99.B60335CB@jps.net...

Hi folks,

There is a movement affoot on the wx-develpers list to build a Canvas
widget for high level drawing, borrowing many ideas from the TK canvas.
As I think this is a widget that would be highly used by the wxPython
community, I've decided to get some feedback here. I am compiling a list
of features that we would like to see in this new canvas. I have no idea
how many of them will get implimented, but we might as well start with a
wish list! By the way, if any of you are good C++ coders, this would be
a great thing to contribute to!

wxCanvas is a class that provides a way to draw in a window, and
interact with that drawing at a very high level. Primary consideration
will be for display on the screen, but printing of the currently
displayed image will be provided as well. In the long run, screen
drawing will be well optimised to be fast on all supported platforms.
The Canvas will be zoomable and scrollable. The coordinate system of the
canvas will be setable by the user, so that drawing can be done in any
units.

A complete drawing will be made up of individual objects. These objects
will be persistant, so that they can individually be altered,
re-ordered, or deleted, with the canvas itself taking care of all the
re-drawing required.

Clipping?

Individual objects can be either vector or raster based. Some of the
supported objects will be:

Ellipses
Rectangles (rounded?)
Polylines
Polygons
Splines (or should "splined" be a property of a polyline(gon) ?

These will have properties like LineColor, LineStyle, FillColor,
FillStyle, etc...

Text (with foreground/background colours, size, and font)

Yes, clearly legible text is critical in diagrams.

Points (individual pixels)

Bitmaps (wxImages?)

Windows (such as wxTextCtrl, etc.)
Controls (Buttons, etc.)

Controls sounds useful.

···

Individual objects can be combined to form a higher level object that
can be treated as a single object. These individual "group" objects can
each have their own coordinate system.

Objects can have callbacks assigned to them (such as mouse click events)

Multiple objects can be created with a single call like:

        /* pseudocode*/
DrawRectangles(ListofCoordinates,ListofProperties).

Well, that's all I have for the moment. Please send your comments and
suggestions.

-Chris

--
Christopher Barker,
Ph.D.
cbarker@jps.net --- --- ---
http://www.jps.net/cbarker -----@@ -----@@ -----@@
                                   ------@@@ ------@@@ ------@@@
Water Resources Engineering ------ @ ------ @ ------ @
Coastal and Fluvial Hydrodynamics ------- --------- --------
------------------------------------------------------------------------
------------------------------------------------------------------------

Tom wrote:

Sounds like a 2D diagramming canvas - like Visio. I think that sort of
thing is useful for lots of different appliations (hence MS adding Visio to
Office).

I don't think that's quite where this is headed, although it certainly
could be used to make a tool like that.

Movement quality (smoothness, speed) is important in this sort of
application - for when a user moves an object.

That seems to be just what has caught the developer's interest, so
that's what is being worked on now. It should be pretty good, but I
think the highest priority is providing a High level interface, which
will impact the performance some.

It would also be nice if lines connecting objects adjusted when moved.

I'm not sure that's going to make it into the Cavas at this point,
although I will add it to my wish-list of features. Have you checked out
wxOGL? IT is a drawing tool that does just that, maybe ito's what you
need. (It should be in the wxPython Demo)

I've made a few other comments on your suggestions below.

Thanks

-Chris

···

--
Christopher Barker,
Ph.D.
cbarker@jps.net --- --- ---
http://www.jps.net/cbarker -----@@ -----@@ -----@@
                                   ------@@@ ------@@@ ------@@@
Water Resources Engineering ------ @ ------ @ ------ @
Coastal and Fluvial Hydrodynamics ------- --------- --------
------------------------------------------------------------------------
------------------------------------------------------------------------

I guess I'm a bit unclear on the difference between wxOGL and wxCanvas.
While wxCanvas uses the native DC and seems more oriented towards dynamic
graphics, they both seem to be fairly high level API's for 2D diagramming on
a canvas, based on combinations of geometric primitives.

Tom

"Chris Barker" <cbarker@jps.net> wrote in message
news:39B53C6F.FF7014A7@jps.net...

Tom wrote:
> Sounds like a 2D diagramming canvas - like Visio. I think that sort of
> thing is useful for lots of different appliations (hence MS adding Visio

to

···

> Office).

I don't think that's quite where this is headed, although it certainly
could be used to make a tool like that.

> Movement quality (smoothness, speed) is important in this sort of
> application - for when a user moves an object.

That seems to be just what has caught the developer's interest, so
that's what is being worked on now. It should be pretty good, but I
think the highest priority is providing a High level interface, which
will impact the performance some.

> It would also be nice if lines connecting objects adjusted when moved.

I'm not sure that's going to make it into the Cavas at this point,
although I will add it to my wish-list of features. Have you checked out
wxOGL? IT is a drawing tool that does just that, maybe ito's what you
need. (It should be in the wxPython Demo)

> I've made a few other comments on your suggestions below.

Thanks

-Chris

--
Christopher Barker,
Ph.D.
cbarker@jps.net --- --- ---
http://www.jps.net/cbarker -----@@ -----@@ -----@@
                                   ------@@@ ------@@@ ------@@@
Water Resources Engineering ------ @ ------ @ ------ @
Coastal and Fluvial Hydrodynamics ------- --------- --------
------------------------------------------------------------------------
------------------------------------------------------------------------

Tom wrote:

I guess I'm a bit unclear on the difference between wxOGL and wxCanvas.
While wxCanvas uses the native DC and seems more oriented towards dynamic
graphics, they both seem to be fairly high level API's for 2D diagramming on
a canvas, based on combinations of geometric primitives.

I havn't looked too closely at OGL, but the reason I havn't is that it
appears to be very specifically designed for creating diagrams. As far
as I can tell, it was built as the graphics engine for Hardy, and thus
is a pretty special purpose tool. The wxCanvas project is designed to be
general purpose from the begining. Specifically, it seems that there is
a lot of effort being put into well optimized code for dealing with
bitmap objects. It doesn't look like OGL handles them at all.

Of course, using ideas and code from OGL is probably a good idea!

-Chris

···

--
Christopher Barker,
Ph.D.
cbarker@jps.net --- --- ---
http://www.jps.net/cbarker -----@@ -----@@ -----@@
                                   ------@@@ ------@@@ ------@@@
Water Resources Engineering ------ @ ------ @ ------ @
Coastal and Fluvial Hydrodynamics ------- --------- --------
------------------------------------------------------------------------
------------------------------------------------------------------------

I guess I'm a bit unclear on the difference between wxOGL and wxCanvas.
While wxCanvas uses the native DC and seems more oriented towards dynamic
graphics, they both seem to be fairly high level API's for 2D diagramming

on

a canvas, based on combinations of geometric primitives.

wxOGL is good for things like Visio, technical drawings composed of simple
shapes and such. I think wxCanvas will be good for things like PySol
(http://pysol.tsx.org) or other graphically intensive things.

···

--
Robin Dunn
Software Craftsman
robin@AllDunn.com
http://wxpython.org Java give you jitters?
http://wxpros.com Relax with wxPython!