changes in 2.5

wxPython Users
1

Could we keep the default drawing methods we have now:
dc.DrawRectangle(x,y,w,h)
instead of having to change it to:
dc.DrawRectangle((x,y),(w,h))
or dc.DrawRectangleXY(x,y,w,h)

Just to make it easier to use, without having to ever use wxPoint or wxSize or extra tuples.

And the new Bind method for events is an improvement:
      self.Bind(wx.EVT_SIZE, self.OnSize)
      self.Bind(wx.EVT_BUTTON, self.OnButtonClick, theButton)
      self.Bind(wx.EVT_MENU, self.OnExit, id=ID_EXIT)
but why not go all the way and allow for event binding that is even simpler than in other gui toolkits:
      self.Bind("size", self.OnSize) # window event
      theButton.Bind(self.OnClick) # default button event
      file_exit.Bind(self.OnFileExit) # default menu event

2.5 gets rid of ID numbers, why not wxPoints and macros (like EVT_SIZE) too? If there are C++ wxWindows users migrating to Python they could still do it the old way.

2

Doug Holton wrote:

Could we keep the default drawing methods we have now:
dc.DrawRectangle(x,y,w,h)
instead of having to change it to:
dc.DrawRectangle((x,y),(w,h))
or dc.DrawRectangleXY(x,y,w,h)

Just to make it easier to use, without having to ever use wxPoint or wxSize or extra tuples.

This was discussed on wxPython-dev. It comes down to either staying consistent with the rest of the library, or not having the enhanced methods at all. Often people will already be tracking positions or sizes in a wx[Point|Size] or in a 2 element sequence and so the new methods save them the step of unpacking their data just to have it pakced back in a wxPoint or wxSize by the wx code. If you don't like using the packed data then the old methods are still available with the new names.

And the new Bind method for events is an improvement:
     self.Bind(wx.EVT_SIZE, self.OnSize)
     self.Bind(wx.EVT_BUTTON, self.OnButtonClick, theButton)
     self.Bind(wx.EVT_MENU, self.OnExit, id=ID_EXIT)
but why not go all the way and allow for event binding that is even simpler than in other gui toolkits:
     self.Bind("size", self.OnSize) # window event

I really dislike toolkits that use strings for binding events, it's too easy to make a mistake on "arealylongeventname" and it also means more work for me to document and maintain an "eventname" --> EVT_WHATEVER mapping.

     theButton.Bind(self.OnClick) # default button event

Shortcuts like this could be added, but many window types don't have an event that could be considered the default one, so it leads to more inconsistencies. Also, overriding this for derived classes and still allowing access to the full form of Bind in the base class woudl require a trick or two and could confuse newbies.

     file_exit.Bind(self.OnFileExit) # default menu event

What is file_exit? A wx.MenuItem? If so it won't work because you don't bind handlers to the menu item or even to the menu (although that may change) but to the frame the menubar is attached to. That is where the events are delivered.

2.5 gets rid of ID numbers, why not wxPoints and macros (like EVT_SIZE) too?

They are not macros in Python, never have been. In 2.5 they are instances of a wx.PyEventBinder object, which I think gives a lot of flexibility for future development and enhancements.

If there are C++ wxWindows users migrating to Python they could still do it the old way.

But doing it the new way should be an as easy as possible transition too.

···

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

3

"Doug Holton" <d.holton@vanderbilt.edu> wrote in message

<snip>

And the new Bind method for events is an improvement:
      self.Bind(wx.EVT_SIZE, self.OnSize)
      self.Bind(wx.EVT_BUTTON, self.OnButtonClick, theButton)
      self.Bind(wx.EVT_MENU, self.OnExit, id=ID_EXIT)
but why not go all the way and allow for event binding that is even
simpler than in other gui toolkits:
      self.Bind("size", self.OnSize) # window event
      theButton.Bind(self.OnClick) # default button event
      file_exit.Bind(self.OnFileExit) # default menu event

One thing to remember about that sort of syntax is that your events are
bound to methods of the button or other control, not to methods of the
frame.

Personally, I tend to wrap things like the creation and binding of controls
in factory functions, so that the exact syntax used doesn't matter much - it
is only used once in the function definition. As an example, I make buttons
using the function:

def MakeButton(win, text, sizer = None, func = None) :
        btn = wx.Button(win, -1, text)
        if func :
            wx.EVT_BUTTON(win, btn.GetId(), func)
        if sizer :
            SizerAdd(sizer, btn)
        return btn

(Where SizerAdd is yet another factory function.) This means the
form-building part of the code has lines like:

    MakeButton(self, "Load...", hs, self.OnLoad)

It's only the code that is different for each button that is specified in
the main code. The GetId() function is very useful, and saves all sorts of
messing around with ids.

I dislike the idea of using strings to identify functionality in the way you
suggest. Although python will not spot mistakes like wx.EVT_SIZ at
"compile" time, tools like pychecker can, while they have no chance with
"siz" vs. "size". You can also get more information from a python shell -
if you can't remember whether it should be wx.EVT_SIZ or wx.EVT_SIZE, you
can open a python shell and type

import wx
[x for x in dir(wx) if "EVT_SIZ" in x]

['EVT_SIZE', 'wxEVT_SIZE']

Much faster than looking through the documentation (not that I have a
problem with the documentation - it's just that there's a lot of it).