Dispatching events in wxPython

Friday 28 January 2005This is almost 20 years old. Be careful.

I’ve been getting back into wxPython coding, and have been trying to find a clean example of the Model-View-Controller pattern, but haven’t been having much luck. For example, I’d like to have menu commands where the main frame doesn’t have to know to invoke a method on the current view. I’d rather that some generic event machinery found that the view could handle the event, and let it do just that.

Matthew Scott’s uberwx technique, which uses the dispatch module to move events around, may just the ticket, but I have to try it out to know for sure.

Comments

[gravatar]
Be careful when using the default 'dispatch' module included with PyDispatcher. If you follow PEAK or PyProtocols development and make use of, or plan to at least experiment with, generic functions, the 'dispatch' module in those projects will conflict with PyDispatcher's dispatch module.

I solved this by renaming 'dispatch' to 'pydispatch' for the Schevo project, since it makes use of both libraries.
[gravatar]
Oops, didn't occur to me there was a conflict.

Interestingly, PyDispatcher looks a lot like a relatively simple generic function or Dispatcher object. The main things I'd have to add to PyProtocols would be weak reference support for automatic removal of receivers, and support for removing rules from a Dispatcher instance. Then, I could export an upward-compatible interface from PyProtocols' dispatch module. As a side effect, the PyProtocols version of the PyDispatch interface would also support arbitrary condition tests, not just "this or Any" tests.

That is, PyDispatcher's "send" is in effect just a generic function that supports removing rules, but lacks predicates. (Note that this also means that you could have different generic functions for different signals, and thereby have a more strongly-typed event system, if you like.)

Of course PyDispatcher and generic functions are tuned for performance under different conditions; if receivers come and go anywhere near as frequently as events are sent, then PyDispatcher will likely have better performance, since generic functions would have to incrementally rebuild their dispatch tree on the next send after a receiver is removed. (On the other other hand, if you have a generic function for each kind of event, these rebuilds might occur less frequently.)

Still, if somebody has an interesting example of PyDispatcher code (that runs the same way each time, i.e. not a GUI), it might serve as a good performance test for tuning up PyProtocols' dispatch tree maintenance.

Add a comment:

Ignore this:
Leave this empty:
Name is required. Either email or web are required. Email won't be displayed and I won't spam you. Your web site won't be indexed by search engines.
Don't put anything here:
Leave this empty:
Comment text is Markdown.