Have you guys seen this program?

Just an FYI.
http://wxpita.googlecode.com

Maybe there is some cooperation that could be created between projects.

---------- Forwarded message ----------
From: Feihong Hsu <[EMAIL PROTECTED]>
Date: Dec 18, 2007 9:08 PM
Subject: Re: [Chicago] wxpita
The Chicago Python Users Group <[EMAIL PROTECTED]>


I think to join the project you have to get a Google Code account (or
maybe you just need a Gmail account), and you go to the project page
(http://wxpita.googlecode.com), and click the 'Join project' link.
Then I, as the Project Owner, have to approve you as a Project Member.

Once you are a Project Member you should be able to edit the wiki and
otherwise muck around. I would love some help getting the
documentation written. Or writing simple example programs that are
bundled into the examples.zip download.

BTW, I finally added the data binding stuff into the latest release of
wxPita. It integrates with an event-driven programming framework
called Trellis, which is written by Philip J. Eby. If people are
interested, I can do a two-for-one talk about Trellis and
wxPita/wxPython. Since I already gave a talk this month, if January is
full then I'll wait until February.

Cheers,
Feihong



Clint Laskowski <[EMAIL PROTECTED]> wrote:
 I've started to play with wxPita a bit and it is very cool. Is there
anything written up on it yet in terms of simple documentation?

 How do I join the project or add to the wiki for it? I've started
writing some notes and I'd be glad to add them as the start of
documentation, if there is interest.

 -- Clint

 Feihong Hsu wrote:
I'm not 100% sure I understand your question, but I'll take a stab at an answer.

 The core of wxPita's API is the layout and event binding stuff. All
that happens outside of wxPython -- although the names of the classes
are the same, no widgets are being created when you're using that part
of the framework.

 Since the wxPita classes aren't real widgets, you can't treat them as
if they were. So I came up with two special ways to modify the state
of the GUI right after the widgets are initialized:

 - Fake methods
 - Init callbacks

 The fake methods just emulate simple method calls that you can make
on the real widgets. For example,

 f.combobox.SetSelection(0)

 Where f.combobox is a wrapper object for wx.ComboBox. This doesn't
execute anything, it just saves the name of the method and its
arguments for later, to be invoked right after the real widget is
created.

 The Init callbacks look like this:

 @f.Init
 def _():
     for s in ['cat', 'bat', 'dog', 'foo', 'box']:
         f.combobox.Append(s)

     # You can't use a Fake Method for this because wx.Font
     # objects can't be instantiated until the wx.App object has been created:
     f.combobox.SetFont(wx.Font(14, wx.SWISS, wx.NORMAL, wx.NORMAL))

 The Init callback is invoked right after widget creation, but the
difference is that by that time, the wrapper objects have been
replaced by the real widgets. So, whereas f.combobox was a wrapper
before, inside the Init callback it's a real live wxPython widget. So
you can do anything inside the Init callback that you can normally do
in wxPython.

 Incidentally, I decided to do away with the Fake Method approach.
It's too magical and weird. I also changed the Init callback slightly
from how it was in yesterday's presentation (it doesn't accept a
parameter anymore, and it can only be used on container wrappers).

 The comments and questions I got were excellent; they really helped
me settle certain design decisions that were nagging me.  In
particular, the event binding API I devised with was quite ugly, but
after fooling around for a while I finally came up with something
halfway decent:

 @f.button.button_clicked
 def onclick(evt):
     print 'You clicked on', evt.EventObject.GetLabel()

 @f.combobox.combobox_selected
 def _(evt)
     print 'You selected', evt.EventObject.GetSelectionString()

 f.button2.button_clicked.register(onclick)

 Again, I'm still using the wxPython names for everything, except now
I provide the option of using the event type IDs, which are generally
more descriptive than the the event binder names.

 I will see if I can upload everything to Google Code over the
weekend. The reason I didn't today was because I got sidetracked by
data binding, but I can't figure that out very quickly so I'll just
check in what I have now.

 Cheers,
 Feihong

 sheila miguez <[EMAIL PROTECTED]> wrote:
 Feihong's talk was fun. I did not hear all of the suggestion about
 delegating things back to the wxWidgets. Could someone give a
 synopsis?

 --
 sheila
 _______________________________________________
 Chicago mailing list
 [EMAIL PROTECTED]
 http://mail.python.org/mailman/listinfo/chicago


 ________________________________
Never miss a thing. Make Yahoo your homepage. ________________________________
 _______________________________________________ Chicago mailing list
[EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/chicago
__________ NOD32 2724 (20071214) Information __________ This message
was checked by NOD32 antivirus system. http://www.eset.com



 ________________________________

Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.
_______________________________________________
Chicago mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/chicago




-- 
Vehicle Information Number. Check for Authentic VIN
http://lucasmanual.com/vin
TurboGears Documentation:
http://www.lucasmanual.com/mywiki/TurboGears


_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
Searchable Archives: http://leafe.com/archives/search/dabo-users
This message: http://leafe.com/archives/byMID/dabo-users/[EMAIL PROTECTED]

Reply via email to