NAVIGATION
CATEGORIES
REFERRENCE
LINKS
Having a separate Menu class
5 answers - 1494 bytes -
My latest endeavor is breaking down my gigantic wx.Frame subclass into
smaller pieces. So far, I have broken all of my widgets away except for my
toolbar and menu. These last two are confusing me because they involve
binding to methods inside other widgets.
Currently, inside my wx.Frame class, I bind methods to my menu as follows:
self.Bind(wx.EVT_MENU, SelectAll, editselectall)
I don't want to keep all of my menu code inside of my frame code, so I want
a few separate class (derived from wx.Menu) to represent my File, Edit,
View, etc. menus. Then there would be another class derived from
wx.MenuBarwhich should be the only object that is invoked in my frame
class.
What confuses me is binding (The problem is roughly the same for the
toolbar.). In the frame class, I just bind to constructed member variables
(like self.control in the snippet above). However, if I were to have a
separate MenuBar class with Menus inside it, I don't know how to bind these
widget methods to the menu events. I was thinking about passing a list of
functions as parameters, but I wasn't sure if this was the best way to go
about doing things, since there would be about 20 different functions to
pass.
Here's the question: How can I break my menu from the wx.Frame class and put
it into a separate file? (I'm assuming that this requires subclasses of
wx.Menu and wx.MenuBar).
-SakethNo.1 | | 2145 bytes |
| 
Saketh Bhamidipati wrote:
My latest endeavor is breaking down my gigantic wx.Frame subclass into
smaller pieces. So far, I have broken all of my widgets away except for
my toolbar and menu. These last two are confusing me because they
involve binding to methods inside other widgets.
Here's the question: How can I break my menu from the wx.Frame class and
put it into a separate file? (I'm assuming that this requires subclasses
of wx.Menu and wx.MenuBar).
There are two ways to approach this. The first is to keep it tightly
coupled with the frame, and just have a function in another module that
knows all about the frame. The frameinit__ would call this function
and pass itself to the function, and the function would still bind stuff
to the frame. Something like this:
frame.Bind(wx.EVT_MENU, SelectAll, editselectall)
The other way to do this would be to use something like the pubsub or
dispatcher modules to enable looser coupling between your menu/toolbar
and the frame (or wherever the handlers may reside, with looser coupling
you could move them out of the frame too if it makes sense.)
Basically you would have your EVT_MENU handlers "publish" a message, and
the things that used to be EVT_MENU handlers would "subscribe" to that
message. When the menu event happens the message is sent and then the
subscriber is called. You can also have multiple subscribers listening
for the same message if desired.
Since the menu/toolbar events are delivered to the frame, you still need
to have a reference to the frame for event binding, but the function
that builds the menu does not need to know all the nitty-gritty details
about the contents of the frame, what methods to call, etc. So your
event bindings could now look something like this:
frame.Bind(wx.EVT_MENU, source=editselectall,
handler=lambda e, Publisher().sendMessage("editselectall"))
And in the frame instead of event bindings you would just have message
subscriptions, like this:
Publisher().subscribe(SelectAll, "editselectall")No.2 | | 2223 bytes |
| 7/11/06, Robin Dunn <robin (AT) alldunn (DOT) comwrote:
Saketh Bhamidipati wrote:
My latest endeavor is breaking down my gigantic wx.Frame subclass into
smaller pieces. So far, I have broken all of my widgets away except for
my toolbar and menu. These last two are confusing me because they
involve binding to methods inside other widgets.
Here's the question: How can I break my menu from the wx.Frame class and
put it into a separate file? (I'm assuming that this requires subclasses
of wx.Menu and wx.MenuBar).
There are two ways to approach this. The first is to keep it tightly
coupled with the frame, and just have a function in another module that
knows all about the frame. The frameinit__ would call this function
and pass itself to the function, and the function would still bind stuff
to the frame. Something like this:
frame.Bind(wx.EVT_MENU, SelectAll, editselectall)
--
The other way to do this would be to use something like the pubsub or
dispatcher modules to enable looser coupling between your menu/toolbar
and the frame (or wherever the handlers may reside, with looser coupling
you could move them out of the frame too if it makes sense.)
Basically you would have your EVT_MENU handlers "publish" a message, and
the things that used to be EVT_MENU handlers would "subscribe" to that
message. When the menu event happens the message is sent and then the
subscriber is called. You can also have multiple subscribers listening
for the same message if desired.
Since the menu/toolbar events are delivered to the frame, you still need
to have a reference to the frame for event binding, but the function
that builds the menu does not need to know all the nitty-gritty details
about the contents of the frame, what methods to call, etc. So your
event bindings could now look something like this:
frame.Bind(wx.EVT_MENU, source=editselectall,
handler=lambda e,
Publisher().sendMessage("editselectall"))
And in the frame instead of event bindings you would just have message
subscriptions, like this:
Publisher().subscribe(SelectAll, "editselectall")
--No.3 | | 519 bytes |
| Saketh Bhamidipati:
I think I'll go with the first way. The publisher/subscriber paradigm is
a bit over my head at the moment. I was trying to do what Task Coach
does to loosely couple the menu and its bound methods, but that's
somewhat confusing as well.
What is confusing you?
Cheers, Frank
To unsubscribe, e-mail: wxPython-users-unsubscribe (AT) lists (DOT) wxwidgets.org
For additional commands, e-mail: wxPython-users-help (AT) lists (DOT) wxwidgets.orgNo.4 | | 1358 bytes |
| 7/11/06, Frank Niessink <frank (AT) niessink (DOT) comwrote:
Saketh Bhamidipati:
I think I'll go with the first way. The publisher/subscriber paradigm is
a bit over my head at the moment. I was trying to do what Task Coach
does to loosely couple the menu and its bound methods, but that's
somewhat confusing as well.
What is confusing you?
Cheers, Frank
To unsubscribe, e-mail: wxPython-users-unsubscribe (AT) lists (DOT) wxwidgets.org
For additional commands, e-mail: wxPython-users-help (AT) lists (DOT) wxwidgets.org
The pattern's implementation. Although I understand the
theoretical ideas behind it, I've been unable to find a simple example of
the pattern in action. In Task Coach, the pattern is buried under
many layers of abstraction that I'm still trying to dig through.
The pattern is the pattern that I have the most experience with,
ironically. However, I have never implemented it. I am assuming that the
publisher/subscriber paradigm is a version of the pattern, or vice
versa. Again, what confuses me is the implementation.
Am I supposed to write and mixins? In that case, I
suppose that the wx.Frame subclass would also inherit the mixin,
and the wx.Menu and wx.MenuBar subclasses would inherit the
mixins.No.5 | | 2340 bytes |
| Saketh Bhamidipati:
Frank Niessink:
What is confusing you?
The pattern's implementation. Although I understand the
theoretical ideas behind it, I've been unable to find a simple example
of the pattern in action. In Task Coach, the pattern is buried
under many layers of abstraction that I'm still trying to dig through.
Yes, I might have done things a bit over the top there. :-/
The pattern is the pattern that I have the most experience
with, ironically. However, I have never implemented it. I am assuming
that the publisher/subscriber paradigm is a version of the
pattern, or vice versa. Again, what confuses me is the implementation.
Agreed, in my view observer/observables == publish/subscribe.
Am I supposed to write and mixins? In that case, I
suppose that the wx.Frame subclass would also inherit the
mixin, and the wx.Menu and wx.MenuBar subclasses would inherit the
mixins.
If you are interested in the 'UICommand' class as a means to decouple
actions from menu/toolbar on the one hand and domain objects on the
other hand, you don't need to use the classes at all.
The basic idea is this: a UICommand is an action that a user can invoke
through a menu item or a toolbar item. You can bind it to one or more
meu items and to toolbar items. It contains all information that is
needed for that, such as the menu text, the help text, the bitmap to
use, the menu type (wx.ITEM_NRMAL by default) and optionally a stock id
(e.g. wx.ID_SAVE for the save menu item/toolbar button). For each user
command you want to have in your application, you override the base
class and implement the doCommand() method to perform the actual work.
In Task Coach this usually means calling some method on a domain class
or on a controller.
There are a lot of subclasses of UICommand, most of which are the result
of removing duplication between the different actual ui commands. I
would advise to start with something like the UICommand base class and
only use what you really need.
Cheers, Frank
To unsubscribe, e-mail: wxPython-users-unsubscribe (AT) lists (DOT) wxwidgets.org
For additional commands, e-mail: wxPython-users-help (AT) lists (DOT) wxwidgets.org
QUESTION ON "Python"
- ListCtrl without scrollbars
- AW: Create an owen widget
- tempfile and passing files around
- binder and events newbie simple question..
- Using SpinCtrl with decimal values?
- drawing lines
- How to wrap a program with PyCrust?
- Bug with setting row label size in the gridmovers library
- hbb"wxPython in Action" on slashdot
- hbb"wxPython in Action" on slashdot
- drawing lines
- Need Help
- How can I copy files recursively?
- Problems with GTK+ 2, and window updating/refreshing.
- Weird Install Error: wxPython
- Logical Sorting
- how does one tell the screen to Refresh from within another module?
- wxAUI in wxpython
- wxPython and Linux dependencies
- ANN: WidgetListCtrl