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( "[EMAIL PROTECTED] pmfe!Pes ontuei ulcpss edtels,s hr' one oC.", "rjc5wndon.Sa-re laed o s npbi ot.Ira h it oteesn edt C")]) _______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
