GUI in Windows

[Chad Netzer]

On Thu, 2003-05-29 at 18:01, morden wrote: 
> Chad Netzer wrote:

> > What kind of stability do you mean?  If you are aksing whether it
> 
> Written in such a way that what you don't know can't harm you.

???

Trivially easy interfaces can be written fairly easily in any modern GUI
toolkit (and Tk also <wink>).  Complex user interfaces can be a
nightmare in any toolkit.  Python makes a lot of the resource management
easier to handle, but that doesn't make the interface programming
inherently easy.

For example, with any toolkit, you probably have to wonder about these
things:

Where is my program state kept, in the widgets, or in my program model?

If my program state changes, will my widgets update, and stay in sync
with it?

If my widgets update my model state, and my model updates the widget's
state, will I get infinite loops?

What if changing data in a widget needs to cause changes to other
widgets?  Will this adversely affect how I design my program?

If I have a lot of widgets in a window, with their associated behavior,
how easy is it to add one more widget?  Will I be able to predict what
happens when a user interacts with that widget?

Can I subclass widgets and modify their behavior?  Is it easy to do so?

How can I save my GUI state and recover it later?  It is my program's
responsibility, or will the GUI toolkit do it?

What if I need to change GUI toolkits, will I have to rewrite my whole
program?

What if I want to reuse some group of widgets for another program, can I
separate out their functionality easily from my program?

What if I want to use some part of my program's computation somewhere
else, do I need to drag along the widgets?


That is just a few of the issues that can come up with any non-trivial
gui application, and are concerns that affect all the GUI toolkits to
some extent or another.  So, if you haven't thought about how to address
them, what you don't know can *always* harm you.


> Ok. I want a toolking that leaves as little room for misunderstanding as
> possible. Something written with an assumption that the user writing
> the python gui code has an IQ of Forrest Gump.

I know of no such toolkit. :)  They can all handle simple problems.  But
complicated interfaces are complicated with any toolkit.

> Looks like Tk would be my choice then because of it's proven track record.

The design of your program and its relation to the toolkit will have a much
bigger impact than the toolkit.  In my experience, if your needs require few
interactions (ie. a fairly static user interface) you will be okay.  Once
you need your widgets to interact with each other, as well as with the
normal program interaction, things can get really hairy VERY quickly.

Look into Model-View-Controller and Model-View-Presenter architectures and
you will have made a more valuable step than the specific choice of a widget
toolkit (since you state your widget needs are straightforward, and you have
to learn a new toolkit anyway).

Please remember the vast bulk of my experience is with Tk, and some of the
issues may be handled better in QT, GTK or WxWindows.  In particular, QT and
Gtk, inherently work with a signal/slots (or subscription/notification)
architecture, as opposed to "callbacks".  That is a big improvement.  WxWindows
may also provide this as well, I don't know.  You can download and use the
dispatcher.py module from the online Python Cookbook, to achieve similar
functionality with Tkinter.

Here is a link to the dispatcher module I mentioned:

<a href="http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/87056/">dispatcher.py</a>

-- 

Chad Netzer
(any opinion expressed is my own and not NASA's or my employer's)