Cascading menus

[stevee at redac.co.uk]

Hello,

I am attempting to convert a program using an old in house GUI system
to use Python and Tkinter. The in house system uses an interactive
stack based language rather like Forth, called EPL.

Our current interface is a horrible! It contains masses of cascaded
menus. We wish to move a more modern style using with much fewer
menus.

However for the first phase we want to end up with the same menu set
as we currently have but implemented in Python. We can then improve
this using Python/Tkinter.

I have produced a translator that converts one of our old style menu
definitions into Python which works OK.

However I have problems with cascading menus due to a major difference
between the way Python and EPL do this. EPL behaves like this:

   A menu button with an associate sub menu knows that it is to
   display a right arrow to the right of the menu and that when
   selected the menu cascade has to remain on screen. It also has some
   EPL code associated with it that gets run whenever the menu button
   is selected. Somewhere inside that EPL code it will ask to display
   a sub menu. That sub menu will be posted in the correct location
   relative to the original menu. This mechanism allows a lot of
   flexibility in what happens before and after the sub menu is
   displayed. One thing that does happen is that a choice between
   several different sub menus can happen.

In python of course sub menus are directly connected to their parent
menu buttons using add_cascade() and python/Tkinter copes with
displaying the sub menu immediately when the user selects the options.

Now I have two possible solutions to this. I either:

 1. translate EPL into a more Python style. This is my preferred
    option as it is a better step towards having a Python based GUI.

or:

 2. Produce a modified Python/Tkinter with a new form of add_cascade
    (with a different name, so we can still use add_cascade) that:

    a) Displays an arrow on the menu button.
    b) On selection it leaves the current menus displayed.
    c) It can have a Python command associated with that we can use to
       run some arbitrary EPL code.
    d) No sub menu is automatically displayed.

    Then add a version of the menu post command that displays the menu
    at the correct location relative to the currently displayed menu.

    The obvious down side of this approach is that we will have our
    own version of Python/Tkinter/Tk that will need to be re applied
    if we wish to move to newer versions of the software in future.
    (This of course assumes that our changes will not be considered
    sufficiently general to go into the real source code.)

    The plus point is that this solution should be much faster to
    implement and I am very short of time (as usual!).

So my questions (finally) about the modified Python/Thinter approach
are:

1. What do people think of it?
2. Is it feasible?
3. Are there any gotchas I haven't considered?

Thanks for any help you may provide.

Steve


Sent via Deja.com http://www.deja.com/
Before you buy.