Re: [Pythoncard-users] Decision Analysis , a Python script to be re-coded in PythonCard

[Andy T. <an...@cr...>]

Ron,

I would add some URLs to useful guides to GUI programming but I can't 
seem to find any. In their absence I'll tip in my thoughts on the basics 
of the process and wish you well on your journey;

Kevin Altis wrote:

[snip Kevin's very useful reply]

> 
> 
>>-----Original Message-----
>>From: pyt...@li...
>>[mailto:pyt...@li...]On Behalf Of Ronald
>>D Stephens
>>Sent: Monday, September 03, 2001 12:34 PM
>>To: pyt...@li...
>>Subject: [Pythoncard-users] Decision Analysis , a Python script to be
>>re-coded in PythonCard
>>
>>
>>Well, my first Python script or applet was a simple weighted
>>average type of program to help in making decisions that can be
>>analyzed by comparing various options for various criteria,
>>weighted by importance for each criteria, and scored by calculating a
>>simple weighted average for each option and then comparing the
>>scores for various options, with higher scores representing better
>>options.


Tip number one : Always know what you want to achieve. Sounds like we 
are OK here then.

>>
>>This program is a commnad line Python program that runs OK in
>>IDLE or Pythonwin.
>>
>>My goal is to make it work with a gui user interface. My thinking
>>is that this will be a good learning exercise for me in learning
>>PythonCard.


Possibly, but looking at your code you have an awful lot of 
functionality in there, and a lot of it is related to presenting menus 
in a character mode environment. I would apply some RAD techniques 
though, and develop 'little and often'. Start with a simple concept and 
implement that. Once you've got that working to your satisfaction add a 
little more functionality, then a little more, and a little more, until 
- voila - you have your completed application. If you try and convert 
your existing working code in one go the paradigm shift will confuse you 
even more.

>>
>>I have previosuly tried to code a gui version of this in Tkinter,
>>but I became frustrated before I had a working version.


Didn't we all, thats why we are working on PythonCard ;-) Don't forget 
that one of the purposes of this project is to make it easy to develop 
graphical applications. You can help us by sharing your frustrations 
(not that there will be many) and joys as you go along the development path.

>>
>>I think PythonCard is already up to the task of coding a version
>>of my Decision Analysis. Am I right or is it too early for this?


Look at what we've got already. You can code *anything* you like in the 
PythonCard prototype, its just a question of how many compromises you 
currently have to make for missing functionality. That is a reason to 
develop applications in the current framework, to find out what we have 
missed and to add it to the feature list.

>>
>>I realize that I will need to start from scratch and re-code this
>>completely, since the gui version is so much different; although I
>>welcome any comments to the contrary.


Sorry, you are right on that front;

Tip two: seperate display from function in all GUI applications. Make it 
look right and then make it work right (or vice versa, whatever lights 
your candle). By logically keeping the display of data apart from its 
manipulation you make your code simple and easy to maintain. Kevin has 
given you some top tips about using events. Bear this in mind when you 
develop your application. You can get the contents and display right 
before adding the event handlers you need to tie everything together, 
you don't need to do it all at once.

>>
>>I am thinking of using sliders for data entry, although I could
>>use other forms of data input, obviously.


Sliders would be good, none of the existing samples use them so you 
would be breaking new ground here. Try out the use of them before you 
start coding your logic, if they feel and look good then use them but 
don't be afraid to try a few different things before settling on what 
suits the application best. Bear in mind here the difference between the 
presentation of data and the value of it. Sliders can have a numeric 
value, but so can other widgets. All you need to keep in the back of 
your mind is that you need the user to enter a number, the mechanism 
they use to provide it is a presentation issue only. This way your 
application logic should not need to change if you decide to alter your 
presentation.

>>
>>If any one has any comments, or general suggetions before I get
>>too far along on this project, please let me know.


Hope I've been of some help.

>>
>>Since I am a newbie and busy with a full time job, this task may
>>take me awhile, so don't expect immediate results. But once I do
>>get it, maybe the results will be of use somehow. I doubt it
>>would be usefull enough to include in the samples of PythonCard, but
>>anyway, here I go....it's all about learning at this point.
>>
>>I caught on to Python easier than I expected, and I was pleased
>>to be able to do this simple program. But learning gui event driven
>>programming has been hard for me (I suppose learning to really
>>use classes, OOP, gui's and event driven programming all at once is
>>causing me confusion ;-)))). Anyway, I am determined to stick it
>>out with PythonCard though.
>>


Tip three: You will benefit for applying OOP techniques to your 
application but they aren't *absolutely* necessary. Concentrate on the 
events model first.

I'm an OO innocent but I'm managing to battle through. I just have to 
remember to keep everything nice and modular and then when I actually 
understand what mixins and model/view controllers are I can refactor my 
code - if I want to.

>>
>>Ron Stephens
>>
[snip sample code]
>>
>>
>>

Regards,
Andy
-- 
-----------------------------------------------------------------------
 From the desk of Andrew J Todd esq.
"Shave my poodle!"