wxPython Conventions

[akameswaran at gmail.com]

I'm also fairly new to wxPython, but I've done GUI's in a variety of
languages.    I'm not sure about putting the systray - haven't had to
do it.  But your second question, put it in it's own class.  For
desktop apps I almost allways do a limited M/V/C pattern - M/VC - ok so
I mung the view and controller together.  Doing that made it easy for
me to replace tKinter with a newer wxGUI, and if a new toolkit comes
out - It'll be easy to move.  Since I'm a newbie to wxPython - I've
keep having to change my event handling due to ignorant usage - when
making these mistakes, it's a lot easier to nuke and recreate a widget,
or event path if your data and functions are in separate classes.  Now
as for attaching the class, I'm not sure how you've modelled your
software.  Performace considerations are also a real factor - if
performance is not a driving factor, and the program is simple enough -
just let each widget have a reference to the objects it talks to.

Ie, I have a package named GMailAccount, which contains a
GMailAccountInformation class.  Now when you create the widget for
getting this text, maybe a wx.Panel with a couple of textctrl, assign
the widget a GMailAccountInformation.

When performance starts to matter, probably want to go to some object
caching scheme in a model class, and have the widgets interface with
that - but now we're getting into a full M/V/C - and I haven't had to
do that yet in my playing with wx.

Hope this helps.