OO menu management

[Egbert Bouwman]

I have difficulties in organizing my menus, especially in linking
them to the underlying application logic.

I try to follow the OO rules:
the gui classes, in their own module gui.py, do the gui work,
in my case with pygtk,
and they know nothing about the application logic in app.py.

So a button in the gui starts a callback that in realty is a method
in app.py, and the name of that callback is given to the gui
via an argument. That works well for a single button.

With a menu system it is different, because there are so many buttons.

I still have for each menu button:
- a callback-name variable in the gui class
- a real callback method in the application class
and now a dictionary that links those two.
That dictionary is argument-passed to the gui.

Additionally in the gui itself I have a nested list with for each button:
- the name of the menu button (MenuItem) itself
- the name of the sub-menu it belongs to
- the tekst on the button
- the sub-menu it may open
- the name of its callback (
- the callback arguments

It is quite complex, with a lot of correspondences that may go wrong.
So I wonder if my approach is the right one.
Do I understand the OO approach well ?
Should I relax the OO guidelines ?
Is there something in python which may help, but which I have overlooked ?

egbert

 

[Christopher T King]

I still have for each menu button:
- a callback-name variable in the gui class
- a real callback method in the application class
and now a dictionary that links those two.
That dictionary is argument-passed to the gui.

Additionally in the gui itself I have a nested list with for each button:
- the name of the menu button (MenuItem) itself
- the name of the sub-menu it belongs to
- the tekst on the button
- the sub-menu it may open
- the name of its callback (
- the callback arguments

I was doing the same thing in an app I was working on, only with a toolbox
instead of menus, but...

It is quite complex, with a lot of correspondences that may go wrong.
So I wonder if my approach is the right one.

What you're doing is a good way to make the menu system
toolkit-independent. This is helpful if you plan to make your entire
program toolkit-independent, i.e. you plan to include code for, say,
Tkinter, wxPython, and PyQt. If that's your final aim, though, I'd
suggest you rather look at AnyGui, which is a toolkit-independent toolkit
(the sort of thing Python should ship with), and just hardcode menus using
its menu widgets, rather than generalizing menus yourself.

If you're not looking for a toolkit-independent program, but rather just
one which you could easily rewrite the GUI code to work with another
toolkit at some point in the future, you're probably better off just
hardcoding the menus into the GUI portion of your program, since any
change of toolkit will require a complete rewrite of that portion anyways.

Hope this helps.