[Pythoncard-users] making PythonCard events just wxPython events

Rowland and I were discussing the requirements for reworking the current
PythonCard event system. The transcript is below. Since we're considering
several major changes I'm going to go ahead and tag what's in cvs as version
0.5.3 before starting in on the changes. The event system change won't have
a major impact on the current samples, we'll still be doing
on_widgetName_eventName, but it is a major change to the framework.
Splitting widget.py into separate files of "components" is also a big
change. I'll go ahead and do a 0.5.3 zip later today. *** 0.5.3 will require
wxPython 2.3.1 or later ***

This event system change is going to bind PythonCard pretty tightly to
wxPython. As I've mentioned in other messages, I don't have a problem with
that. If you have some issues with PythonCard only working on top of
wxPython, now is the time to speak up.

ka
---

altis: PythonCard events are wxPython events

altis: PythonCard event names for handlers stay the same, mouseClick,
keyDown

altis: a dispatcher is still used in order to support a Message Watcher or
other listeners

altis: and provide the target of an event in addition to the native event

altis: there should be a way of binding events at runtime such as
bindEvent(self.components.btnRun, 'mouseClick') or
bindEvent(self.components.btnRun, 'mouseClick',
self._handlers['on_btnRun_mouseClick']

altis: so that's a place where we could be more general in our even binding,
so that the autobinding of on_name_event is a specific case, but actually
you could bind an event name to any method

altis: that would allow for binding outside the main background class and is
probably the right thing to do

altis: any helper methods such as posting an event would also use the
shortcut names like 'mouseClick'

altis: the event names have to be expanded to include "close", "size" "idle"
and many other common events
Rowland Smith: what do you mean by 'expanded'?
altis: right now we don't handle close and size events

altis: question, should we ditch the message hierarchy and just support
binding the same handler to multiple widgets, menus, widgets directly?
altis: explicit versus implicit
altis: so explicit is probably better

altis: your command events probably have to be reworked

Rowland Smith: does explicit mean if it's not bound nobody sees it - i.e. no
hierarchy
altis: i was thinking explicity would mean there isn't a hierarchy search,
either you bind buttons 1 - 9 to handle on_mouseClick or they don't get
handled, so no implicity background and stack handlers
Rowland Smith: i think javabeans and other models just use explicit
binding - a message is only fired to bound handlers
altis: i'm fine with it, yet another deviation from hypercard and that's
fine too