[Tutor] Developing a GUI application

[Andrei]

Hi Terry,

Terry Carroll wrote:
> I'd like advice from the more seasoned programmers here: how do you 
> approach a GUI-based app?

Approaches differ in formality and order of execution and opinions at 
any point in time vary - and they vary with time as well. I'm assuming 
this is a hobby-level project with yourself acting as developer and most 
important customer. So I'll suggest an approach that I think will keep 
you motivated and will help avoid getting bogged down in looking for the 
perfect decision at every step.

It helps if you start with some concrete ideas of what you'll want to be 
able to do with the application. It's not necessary to go all PowerPoint 
on it, but writing down some keywords and sketching interface ideas may 
help you explore your goals. You can even do quick real interface 
designs using e.g. wxGlade - it's often motivating to have *something* 
tangible available. These are not supposed to be final, set-in-stone and 
complete designs - just generic sketches.

> I figure one way to do it is to write the nuts and bolts of it using plain
> old line oriented techniques; and then write the GUI, calling the
> functions already written.

Having two interfaces is a way to make sure you don't accidentally 
couple your interface code to your internal model/storage. There's a 
nicer way to help achieving this: unit tests. However, you may not 
appreciate their advantages until you have more experience. Personally I 
have never used the two-interfaces approach.

> The other way would be to write a GUI shell with all the controls, but 

I would choose for a vertical development: implement everything you need 
(interface, storage, logic) to achieve some small part of the 
functionality - e.g. start by having a list of CD-ROM names and burn 
dates. This should work in the GUI, in the model and in your storage 
parts. Once that is tested and OK, add the next bit of functionality, etc.

You will invariably encounter problems due to previous decisions when 
doing this, but all beginners' applications - as well as most 
professionals' applications :) - eventually end up in a state of 
unmaintainable mess anyway. Making mistakes is a very good way of 
learning and even truly dumb and ugly mistakes can usually be worked 
around or refactored away; software is very malleable, particularly if 
you don't have outside constraints.
With a bit of luck, your software will be almost continuously in a 
usable state and using it will give you new ideas all the time, which 
you had not thought of beforehand.

> calling dummy functions; then write the functions to do the tasks.

You should look into objects - if you don't have at least a basic 
understanding of them, GUI development with wxPython will prove 
difficult and confusing. They are also pretty much essential for well 
structured Python programs.

> (If it matters: I'm going to use wxPython; and my app is yet another CDROM 
> database program; more details available if it matters.)

-- 
Yours,

Andrei

=====
Mail address in header catches spam. Real contact info:
''.join([''.join(s) for s in zip(
"poet at aao.l pmfe!Pes ontuei ulcpss  edtels,s hr' one oC.",
"rjc5wndon.Sa-re laed o s npbi ot.Ira h it oteesn edt C")])