Seeking tips for multiplatform development

wxPython Users
1

I've been working with wxPython 2.4.2.4 on Linux, and today
decided to try running my code as-is on Windows NT4 with
wxPython 2.4.2.4.

Well... it kind of runs, but some oddities I've noticed so far:

1) event handler for a menu item:
def OnFileOpen(self, event):
  print event.GetEventObject()

On Linux, this outputs the menu item instance, as expected:
<mainMenu.FileOpenMenu instance; proxy of C++ wxMenu instance at _8394f78_wxMenu_p>

while on Windows, the output is the MainFrame instance:
<daboApp.MainFrame instance; proxy of C++ wxMDIParentFrame instance at _7f1830_wxMDIParentFrame_p>

2) location of event.Skip() matters under Windows:
I have a wx.Notebook subclass, with an OnPageChanged event
handler. Under Linux, I did my stuff, and then called event.Skip().
Under Windows, I found I needed to move event.Skip() to the
top of the method, before calls such as: event.GetSelection(), or
various Assertion errors would occur.

3) I have a wx.Grid on a page in a notebook that works beautifully
in Linux, but on Windows it paints and then disappears. If I
change pages, I can see the grid flash into view before the page
changes. I haven't played around too much with this yet.

I guess my question now is: is there a recommended approach
to multi-platform development? Is there a "lowest common
denomenator" platform to develop on? Do I have to worry
about wx behaving wildly differently on the different flavors
of Windows, or just wildly differently when crossing the
major platforms of Mac/Linux/Windows?

I'm going to test my app on OSX this evening as well...

I'd prefer to develop on Linux but would like to know what
steps I can take now to minimize the tweaking that will need to
happen later to keep the app running on all platforms. I'm
just a one-man shop so I'm not going to be able to test on
all platforms and flavors every time I make a modification.

I'm looking for both general tips, as well as specific examples,
so if you have experience deploying your wxPython apps
to different platforms, please don't be shy!

···

--
Paul

2

Paul McNett wrote:

I've been working with wxPython 2.4.2.4 on Linux, and today
decided to try running my code as-is on Windows NT4 with
wxPython 2.4.2.4.

Well... it kind of runs, but some oddities I've noticed so far:

That's pretty much my experience too. wxPython is "write once...debug
everywhere". I don't know that any other system is any better however.
wxWindows "wrapper" approach does make for a few more platform
inconsistancies, but you get native look and feel in exchange.

I'd prefer to develop on Linux but would like to know what
steps I can take now to minimize the tweaking that will need to
happen later to keep the app running on all platforms.

Read this Wiki page:

http://wiki.wxpython.org/index.cgi/wxPython_20Platform_20Inconsistencies

And better yet, add to it! I'd love to see your list of issues put on
that page. Documentation is our only hope!

just a one-man shop so I'm not going to be able to test on
all platforms and flavors every time I make a modification.

There is simply no substitute for testing. However, it does get better
as you go along, you learnt he cross-platfrom way of doing things.

I'm looking for both general tips, as well as specific examples,

The specific examples are on that Wiki page.

so if you have experience deploying your wxPython apps
to different platforms, please don't be shy!

My experience so far has been that while there are differences between
the platforms, usually the is one way to solve a given problem that
works on all of them. I have yet to have an platform specific code in my
stuff. It's often the case that the documented way works, and it's just
that you don't have to do everything quite right on some platforms, in
some cases, so READ THE DOCS.

I don't think any one platform is more lower common denominator than any
other...

-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

3

Chris Barker writes:

Paul McNett wrote:
> Well... it kind of runs, but some oddities I've noticed so
> far:

That's pretty much my experience too. wxPython is "write
once...debug everywhere". I don't know that any other system
is any better however. wxWindows "wrapper" approach does make
for a few more platform inconsistancies, but you get native
look and feel in exchange.

Oh yes! Please don't anyone come away from my post thinking I'm
dissing wxPython... I am greatly enjoying it but wanted to fire
up some discussion on these issues. I've tried Tkinter, PyQt,
and now wxPython. I'm sticking with wxPython, and will deal
with inconsistencies as I find them, because I can tell I'll be
able to prototype quickly, and deliver powerful multiplatform
applications. wxPython/wxWindows is starting to come together
for me, and I haven't even invested that much time yet.

Read this Wiki page:
http://wiki.wxpython.org/index.cgi/wxPython_20Platform_20Inconsistencies

And better yet, add to it! I'd love to see your list of
issues put on that page. Documentation is our only hope!

Okay, I'll revisit the Wiki and play around with it and try to
contribute. Historically, I've disliked web user interfaces but
I can see the value in a central refuge of useful information.
I've also had people unintentionally delete my contributions
before (on a different wiki) and that left a bad taste in my
mouth.

My experience so far has been that while there are
differences between the platforms, usually the is one way to
solve a given problem that works on all of them. I have yet
to have an platform specific code in my stuff. It's often the
case that the documented way works, and it's just that you
don't have to do everything quite right on some platforms, in
some cases, so READ THE DOCS.

Yes, I found this too. So far I've been able to solve everything
except for the GetEventObject() problem so that both
Windows/Linux works fine -- and my code tightened up in the
process.

I don't think any one platform is more lower common
denominator than any other...

Thanks for your response; I'll really make an attempt at the
Wiki.

···

--
Paul

4

Paul McNett writes:

1) event handler for a menu item:
def OnFileOpen(self, event):
        print event.GetEventObject()

On Linux, this outputs the menu item instance, as expected:
<mainMenu.FileOpenMenu instance; proxy of C++ wxMenu instance
at _8394f78_wxMenu_p>

while on Windows, the output is the MainFrame instance:
<daboApp.MainFrame instance; proxy of C++ w

I've posted an example that demonstrates this platform
inconsistency. It is my first attempt on the wxPyWiki, so
someone experienced with the Wiki please tell me if I didn't
tread lightly enough:

http://wiki.wxpython.org/index.cgi/wxPython_20Platform_20Inconsistencies

···

--
Paul

5

Paul McNett wrote:

I've been working with wxPython 2.4.2.4 on Linux, and today decided to try running my code as-is on Windows NT4 with wxPython 2.4.2.4.

Well... it kind of runs, but some oddities I've noticed so far:

1) event handler for a menu item:
def OnFileOpen(self, event):
  print event.GetEventObject()

On Linux, this outputs the menu item instance, as expected:
<mainMenu.FileOpenMenu instance; proxy of C++ wxMenu instance at _8394f78_wxMenu_p>

while on Windows, the output is the MainFrame instance:
<daboApp.MainFrame instance; proxy of C++ wxMDIParentFrame instance at _7f1830_wxMDIParentFrame_p>

I'm not sure if it has been done yet, but correcting this difference has been discussed. In the meantime you can use something like the following to get the menu on all platforms:

  menu = self.GetMenuBar().FindItemById(event.GetId()).GetMenu()

2) location of event.Skip() matters under Windows:
I have a wx.Notebook subclass, with an OnPageChanged event
handler. Under Linux, I did my stuff, and then called event.Skip().
Under Windows, I found I needed to move event.Skip() to the
top of the method, before calls such as: event.GetSelection(), or
various Assertion errors would occur.

Please verify this. Skip() only sets a flag in the event object. Nothing else. And that value is not checked until the event handler has returned to ProcessEvent. So *when* you call it should not matter at all, only *if* you call it.

     void Skip(bool skip = TRUE) { m_skipped = skip; }

What could be different is what happens later if if you do or don't call it for a particular handler, as there can be differences in whether some default behaviour for a particular event is required or not.

3) I have a wx.Grid on a page in a notebook that works beautifully in Linux, but on Windows it paints and then disappears. If I change pages, I can see the grid flash into view before the page
changes. I haven't played around too much with this yet.

Double check that the grid window is a child of the notebook.

I guess my question now is: is there a recommended approach
to multi-platform development? Is there a "lowest common
denomenator" platform to develop on? Do I have to worry
about wx behaving wildly differently on the different flavors
of Windows,

Not usually, although bugs in older versions of the MS Common Controls DLL can sometimes affect wxWindows apps.

or just wildly differently when crossing the major platforms of Mac/Linux/Windows?

Well "wildly different" is probably a bit strong, but there will probably always be corner cases where things are a bit different. The only way to avoid that is to not use native widgets at all, and to ignore many of the native platform events/messages and just fabricate our own.

Anyway, the wiki page that has already been mentioned is intended as a way for people to document the differences as they find them, in order to help others not fall into the same problems.

···

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

6

Robin Dunn writes:

  menu =
self.GetMenuBar().FindItemById(event.GetId()).GetMenu()

Cool, thanks. I tried something similar, but used
wx.Window().FindWindowById(). That, of course, failed since
menu items don't descend from wxWindow.

> 2) location of event.Skip() matters under Windows:

Please verify this. Skip() only sets a flag in the event
object. Nothing else. And that value is not checked until
the event handler has returned to ProcessEvent. So *when*
you call it should not matter at all, only *if* you call it.

You are right, the difference wasn't in the location of
event.Skip() in my handler, but the fact that in the notebook's
__init__() I had called EVT_NOTEBOOK_PAGE_CHANGED() before
adding the pages. Moving this to the end of __init__ got rid of
the errors, while moving event.Skip() resulted in no change.

> 3) I have a wx.Grid on a page in a notebook that works
> beautifully in Linux, but on Windows it paints and then
> disappears. If I change pages, I can see the grid flash
> into view before the page changes. I haven't played around
> too much with this yet.

Double check that the grid window is a child of the notebook.

Actually, my problem was that on Linux I didn't need to call
self.GetSizer().Layout() after adding the grid to the page's
sizer, while on Windows I found that to be necessary unless I
resize the frame manually. On Linux I had:
self.SetDimensions(-1,-1,-1,-1) because through trial and error
I found that to work. Changing this to self.GetSizer().Layout()
made it work on both platforms. My bad.

Yes I'm learning, so bear with me <g>. Thanks to the Wiki and
this list, and the ease of the code/test/code cycle that
Python/wxPython offers, I was able to get my test app working
equally well on Windows and Linux.

···

--
Paul