pythoncard-users Mailing List for PythonCard (Page 199)

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!"

Kevin Altis:
> Neil actually did a demo that uses the .rsrc.py files to make a web page
> suitable for use in a browser, so the layout of PythonCard background can
> sort of be used as HTML. I thought Neil was going to check the files into
> cvs at:
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pythoncard/proto/samples/
>
> but I don't see the files (Neil can you check them in?). The original
> message is:
> http://groups.yahoo.com/group/pythoncard/message/397
 OK, Pyker.hta and PykerLaunch.hta are now in CVS. These are HyperText
Applications and work only on Windows with a recent version of Internet
Explorer. Similar work could be done in Mozilla with the Python interpreter
embedded although not too many people have this set up.
 Pyker.hta displays the PythonCard resource file given as a command line
argument.
 PykerLaunch.hta displays a list of resource files in subdirectories and
clicking on one displays it using Pyker.hta.
 While I don't intent to takes these any further, they are reasonable
demonstrations of the ability of browsers to produce diverse user
interfaces. It may be possible to turn this code into a PythonCard player
that hosts PythonCard applications inside browsers in a similar manner to
the current wxPython based host.
> Perhaps it might be best for Neil to go into this subject more when he
gets
> time or the framework stabilizes to the point that someone can experiment
> with this without having to update the files with every API change.
 The API resource file hasn't changed since Pyker was first written so
still works.
 Neil

As the closest this group has to a secretary I've taken it upon myself 
to note the current development activity and to start a to do list.
I've added TODO.txt to the root directory in CVS. This enables the rest 
of us to keep up with what Kevin is doing and to make our own 
contributions known and shared with the rest of the team.
This is a only a first cut so please tell me where I have gone wrong, 
any items in progress that I've missed, or suggestions for a better 
layout. It is a text file rather than a web page so that it is easy to 
view and edit, as well as track the changes through CVS without format 
tags getting in the way.
I've tried to keep it simple but structured enough so that someone (I'll 
give it a go but don't hold your breath) can write a parser to turn it 
into a web page for posting on the site. Bear in mind though, that the 
text file will remain the definitive article and is likely to change 
quite a lot.
"""
PythonCard TODO
Item No. : 1
Title : Documentation
Responsible : All
Details : Documentation of current framework, especially the 
attributes and
 events of each widget. Plus PythonCard users guide, getting
 started tutorial and details of each of the sample 
applications.
Reference : None
Item No. : 2
Title : Fonts
Responsible : KA
Details : Add font support to the prototype. Add the ability to define
 font family, weight, size, etc to each widget. Assess the 
multi
 platform implications.
Reference : None
Item No. : 3
Title : Sizers
Responsible : KA
Details : Provide the ability to layout a background using sizers rather
 than the absolute position of widgets.
Reference : None
Item No. : 4
Title : Add CSV support
Responsible : Andy Todd
Details : Add the ability to import and export files in CSV format 
to the
 PythonCard framework.
Reference : SourceForge feature request #455008
Item No. : 5
Title : Support for persistent data
Responsible : Andy Todd
Details : Add support using shelve/pickle to the PythonCard 
framework. The
 functionality in the addresses sample will be used as the 
basis
 for this module
Reference : SourceForge feature request #442150
Item No. : 6
Title : Icon Packs
Responsible : Jeff Griffith
Details : Work on the ability to store icon files 'in line' in .py files
Reference : http://aspn.activestate.com/ASPN/Mail/Message/762295
"""
Regards,
Andy
-- 
-----------------------------------------------------------------------
 From the desk of Andrew J Todd esq.
"Shave my poodle!"

Thanks, Kevin. I will be quietly working on this in the background. Your pointers will be of help to me. Once I get a reasonable
facsimile of this running, I'll share it with the group.
And I'll probably have specific questions along the way.
Ron Stephens
----- Original Message -----
From: "Kevin Altis" <al...@se...>
To: <pyt...@li...>
Sent: Monday, September 03, 2001 9:04 PM
Subject: RE: [Pythoncard-users] Decision Analysis , a Python script to be re-coded in PythonCard
> The short answer is that you should be able to do this in PythonCard. When
> you run into specific problems related to PythonCard, just post the
> questions here. It sounds like a lot of your journey is going to be learning
> to design a non-modal visual interface for a program that was previously a
> linear series of steps. Off the top of my head I'm not sure what resources
> to point you towards, hopefully someone else on the list can provide some
> pointers.
>
> Validators:
> One thing that PythonCard definitely doesn't provide you with right now are
> 'validators' which are sort of like your 'get_number' function below. We'll
> probably have validators later, wxPython even provides a hook for them, but
> for now you'll probably want to make it more like an HTML form where the
> user enters input in a bunch of fields, and then presses a "Submit" or
> "Calculate" button and if one of the fields has invalid input you will
> present an error message and they can redo the input.
>
> You could also check the input with a 'loseFocus' handler and when we have a
> closeField messages being generated this will be even simpler; closeField
> means that not only did the field lose focus, but that the text changed too.
> Turn on the Message Watcher and uncheck 'Hide unused' to see these events
> occurring as you tab and click between fields.
>
> Anyway, in the short term what you can do is have a 'gainFocus' handler
> which saves the current value of the field in variable, then a 'loseFocus'
> handler which compares the original value to the current value and if they
> are different (text changed), then it will do your validation test and if
> the data isn't valid, you present an error dialog and then set the focus
> back to the field and select all the text. That is a very common user
> interface for text validation in GUIs. Other people on the list can probably
> suggest other methods.
>
> This is the kind of thing I'll try and add to one of the samples, unless
> someone beats me to it.
>
> ka
>
> > -----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.
> >
> > 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.
> >
> > I have previosuly tried to code a gui version of this in Tkinter,
> > but I became frustrated before I had a working version.
> >
> > 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?
> >
> > 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.
> >
> > I am thinking of using sliders for data entry, although I could
> > use other forms of data input, obviously.
> >
> > If any one has any comments, or general suggetions before I get
> > too far along on this project, please let me know.
> >
> > 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.
> >
> >
> > Ron Stephens
> >
> > #
> > # This is a decision analysis program that was my first real
> > Python program, based on weighted
> > # averages of scores on several criteria for various questions
> > that need to be decided.
> > # There is a general program for any kind of decision, allowing
> > user input of options
> > # to be decided amongst and criteria to use for decisions; and
> > then there are a few
> > # examples of specific options to be decided amongst with
> > pre-coded "values' or scores
> > # for the various options for various criteria.
> > # It is my goal to code this program using PythonCard.
> >
> >
> >
> > print "A General Decision Analysis Program."
> > print
> > print "Have You Ever Had to Make Up Your Mind?"
> > print
> >
> > import sys
> >
> > def get_number(prompt, lower=sys.maxint * -1, upper=sys.maxint):
> > """ get_number(prompt) -> float
> >
> > This function prompts for a number. If the user enters bad input, such as
> > 'cat' or '3l', it will prompt again.
> > Now checks for upper and lower bounds.
> > """
> > res = None
> > while res is None:
> > try:
> > res = float(raw_input(prompt))
> > try:
> > assert lower <= res <= upper
> > except AssertionError:
> > print "Value must be between", lower, \
> > "and", upper
> > res = None
> > except ValueError: pass
> >
> >
> > return res
> >
> >
> > def get_list(heading, prompt):
> >
> > print heading
> > print
> > print "(enter a blank line to end the list)"
> > ret = []
> > i = 1
> > while 1:
> > line = raw_input(prompt % i)
> > if not line:
> > break
> > ret.append(line)
> > i=i+1
> > print
> > return ret
> >
> > def get_user_rankings(criteria):
> > # Next, get the user to rank his criteria. I use a system
> > where higher
> > # is better, so that an undesirable characteristic can be
> > given a negative
> > # weight.
> > #
> > # {} is a dictionary, it can be indexed by (nearly) any expression,
> > # and we will index it with the names of the criteria.
> >
> > rankings = {}
> > print
> > print "Enter relative importance of criteria (higher is more
> > important)"
> > print
> > for c in criteria:
> > rankings[c] = get_number("Criterion %s: " % c)
> > return rankings
> >
> > def get_user_scores(options, criteria):
> > # Next, get the user to score each option on all the criteria.
> > # Scores are stored as a two-dimensional dictionary, like so:
> > # {'option1': {'criteria1': 100, 'criteria2': 10},
> > # 'option2': {'criteria1': 50, 'criteria2': 10}
> > # }
> > scores = {}
> > print
> > print "Enter score for each option on each criterion"
> > print
> > for o in options:
> > scores[o] = {}
> > print
> > print "Scores for option %s" % o
> > print
> > for c in criteria:
> > scores[o][c] = get_number("Criterion %s: " % c)
> > return scores
> >
> > def calculate_results(options, scores, rankings):
> > # Calculate the resulting score for each option. This equation
> > # is different from Rod Stephen's original program, because I
> > # make more important criteria have higher rankings, and even let
> > # bad criteria have negative rankings.
> >
> > # The "result" dictionary is indexed with the names of the options.
> > result = {}
> > # Criteria can be found automatically, doesn't need to be
> > # passed as an argument.
> > criteria = scores[options[0]].keys()
> > for o in options:
> > value = 0
> > for c in criteria:
> > # print o, c, rankings[c], scores[o][c]
> > value = value + rankings[c] * scores[o][c]
> > result[o] = value
> > return result
> >
> > def ranked_list(results):
> > # Now, I want to take the dictionary result, and turn it into
> > a ranked list
> >
> > results = results.items() # A list of tuples (key, value)
> > results.sort(lambda x, y: -cmp(x[1], y[1]))
> > # Sort the list using the reverse of the
> > # "value" of the entry, so that higher
> > # values come first
> > return results
> >
> >
> > def generic_decision_analyzer(options, criteria):
> > pass
> >
> > def decisionanalysis():
> > # This code is placed in the public domain
> > print
> > print "This is a general decision program, and you can define
> > your choices and criteria."
> > print
> > print "When prompted, please enter the options or choices
> > that you need to decide amongst."
> > print
> > print "Then, when prompted, enter the criteria for making
> > this decision."
> >
> >
> > # First, ask the user to enter the lists
> > options = get_list("Enter your options:", "Option %d: ")
> > criteria = get_list("Now, enter your criteria:", "Criterion %d: ")
> >
> > print "A program to help you make decisions."
> > rankings = get_user_rankings(criteria)
> > scores = get_user_scores(options, criteria)
> > results = ranked_list(calculate_results(options, scores, rankings))
> > print
> > print "Results, in order from highest to lowest score"
> > print
> > print "%5s\t%s" % ("Score", "Option")
> >
> > # Take the pairs out of results in order, and print them out
> > for option, result in results:
> > print "%5s\t%s" % (result, option)
> >
> >
> >
> > # Here's the scores used by the language-choice functions.
> > language_scores = {"Python": {"ease of learning":100,
> > "ease of use":100,
> > "speed of program execution":10,
> > "quality of available tools":70,
> > "popularity":50,
> > "power & expressiveness":100,
> > "cross platform?":100,
> > "cost":100},
> > "Perl": {"ease of learning":50,
> > "ease of use":60,
> > "speed of program execution":20,
> > "quality of available tools":50,
> > "popularity":85,
> > "power & expressiveness":70,
> > "cross platform?":100,
> > "cost":100},
> > "Ruby": { "ease of learning":50,
> > "ease of use":100,
> > "speed of program execution":20,
> > "quality of available tools":20,
> > "popularity":10,
> > "power & expressiveness":100,
> > "cross platform?":80,
> > "cost":100},
> > "Tcl": {"ease of learning":100,
> > "ease of use":100,
> > "speed of program execution":10,
> > "quality of available tools":50,
> > "popularity":40,
> > "power & expressiveness":10,
> > "cross platform?":100,
> > "cost":100},
> > "JavaScript": {"ease of learning":70,
> > "ease of use":75,
> > "speed of program execution":10,
> > "quality of available tools":50,
> > "popularity":100,
> > "power & expressiveness":40,
> > "cross platform?":50,
> > "cost":100},
> > "Visual Basic": {"ease of learning":50,
> > "ease of use":100,
> > "speed of program execution":20,
> > "quality of available tools":100,
> > "popularity":100,
> > "power & expressiveness":50,
> > "cross platform?":1,
> > "cost":1},
> > "Java": {"ease of learning":15,
> > "ease of use":50,
> > "speed of program execution":50,
> > "quality of available tools":100,
> > "popularity":90,
> > "power & expressiveness":100,
> > "cross platform?":100,
> > "cost":100},
> > "C++": {"ease of learning":10,
> > "ease of use":25,
> > "speed of program execution":90,
> > "quality of available tools":90,
> > "popularity":80,
> > "power & expressiveness":100,
> > "cross platform?":90,
> > "cost":100},
> > "C": {"ease of learning":15,
> > "ease of use":20,
> > "speed of program execution":100,
> > "quality of available tools":80,
> > "popularity":80,
> > "power & expressiveness":80,
> > "cross platform?":110,
> > "cost":100},
> > "Lisp": {"ease of learning":40,
> > "ease of use":50,
> > "speed of program execution":80,
> > "quality of available tools":60,
> > "popularity":25,
> > "power & expressiveness":110,
> > "cross platform?":80,
> > "cost":90},
> > "Delphi": {"ease of learning":50,
> > "ease of use":110,
> > "speed of program execution":85,
> > "quality of available tools":100,
> > "popularity":30,
> > "power & expressiveness":100,
> > "cross platform?":80,
> > "cost":10}
> > }
> >
> >
> >
> > def ProgramLanguageFinal():
> > print "This is a program to help give you an idea which
> > programming languages you should consider learning."
> > print "While there are any number of languages you might
> > consider, this program considers only 11 of the most popluar ones."
> > print
> > print "The program will ask you to input a ranking or
> > weighting for a number of criteria that may be of importance"
> > print "in choosing your next programming language."
> >
> > # First look up the criteria listed in the scores.
> > # To do that, we need a language name, which can also
> > # be looked up from the scores.
> > languages = language_scores.keys()
> > some_language = languages[0]
> > criteria = language_scores[some_language].keys()
> > rankings = get_user_rankings(criteria)
> > results = ranked_list(calculate_results(languages,
> > language_scores, rankings))
> > # Take the pairs out of results in order, and print them out
> > for option, result in results:
> > print "%5s\t%s" % (result, option)
> >
> >
> > def ProgramLanguageScript():
> > print
> > print "This is a program to help you choose a scripting language."
> > print
> > print "You will be asked to rank some important criteria as
> > to their relative importance to you."
> > print "These criteria are 'ease of learning', 'ease of use',
> > 'speed of program execution'"
> > "'quality of available tools', 'popularity', and 'power &
> > expressiveness'"
> > print
> > print "Please rank each of the criteria with a number from 1
> > to 100 when prompted."
> > print
> > print "100 means of highest relative importance, 1 means of
> > least importance."
> >
> > # This time we want a subset of languages, so I'm going to
> > specify them.
> > options = ["Python", "Perl", "Ruby", "Tcl", "JavaScript",
> > "Visual Basic"]
> > criteria = language_scores[options[0]].keys()
> > rankings = get_user_rankings(criteria)
> > results = ranked_list(calculate_results(options,
> > language_scores, rankings))
> > # Take the pairs out of results in order, and print them out
> > for option, result in results:
> > print "%5s %s" % (result, option)
> >
> >
> > def Basketball():
> > print "This is a program to help you decide which team will
> > win a basketball game"
> > print
> > print "When prompted, enter a number ranking each team on the
> > prompted team skill"
> > print "on a scale from 1 to 100, with 1 being terrible and
> > 100 being the best imaginable"
> > print
> > team_one = raw_input ("What is the name of team one: ")
> > team_two = raw_input ("What is the name of team two: ")
> > teams = (team_one, team_two)
> >
> > rankings = {"speed":100, "size":66, "jumping_ability":50,
> > "defense":60, "shooting":75, "ballhandling":50, "rebounding":50}
> > criteria = rankings.keys()
> > scores = {team_one: {},
> > team_two: {}}
> > for c in criteria:
> > for team in (team_one, team_two):
> > scores[team][c] = get_number("rank the team %s of %s
> > on a scale of 1 to 100: " % (c, team), 1, 100)
> >
> > results = calculate_results(teams, scores, rankings)
> > for team in teams:
> > print "%s has a power ranking of %d" % (team, results[team])
> > # Now, who won?
> > ranked_results = ranked_list(results)
> > # Compare the scores.
> > if ranked_results[0][1] == ranked_results[1][1]:
> > print "the two teams are a toss-up!!!"
> > else:
> > print "%s wins!!" % ranked_results[0][0]
> >
> >
> > def YesNo():
> > print "Program to help you make a Yes or No decision."
> > options = ["Yes", "No"]
> > criteria = get_list("Enter your criteria ...", "Criterion %d: ")
> >
> > rankings = get_user_rankings(criteria)
> > scores = get_user_scores(options, criteria )
> > print `scores`
> > results = ranked_list(calculate_results(options, scores, rankings))
> > print
> > print "The results are"
> > print
> > print "%5s %s" % ("Score", "Option")
> >
> > for option, result in results:
> > print "%5s %s" % (result, option)
> >
> > if results[0] > results[1]:
> > print "You should decide Yes!!!"
> >
> > else:
> > print
> > print "You should decide No!!!"
> > print
> >
> >
> > ###### MAIN LOOP ############
> >
> > while 1: # loop forever
> >
> > print "Please enter the number for the type of decision you
> > wish to analayze:"
> > print "1. General Decision Analysis, you choose the options,
> > criteria, etc."
> > print "2. Help in Choosing Programming Language amongst 11
> > popular languages"
> > print "3. Help in choosing scripting programming language
> > amongst 6 scripting languages"
> > print "4. Which Basketball Team will win the Game???"
> > print "5. Questions with Yes or No type answers"
> > choice = get_number("Please type in the number of the type of
> > decision-program you wish to run from above and hit enter:", 1, 5)
> >
> > if choice ==1:
> > decisionanalysis()
> > elif choice ==2:
> > ProgramLanguageFinal()
> > elif choice ==3:
> > ProgramLanguageScript()
> > elif choice ==4:
> > Basketball()
> > elif choice ==5:
> > YesNo()
> > elif choice =="quit":
> > break # exit from infinite loop
> > else:
> > print "Invalid operation"
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > Pythoncard-users mailing list
> > Pyt...@li...
> > https://lists.sourceforge.net/lists/listinfo/pythoncard-users
> >
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users

Just a reminder that you can add bugs and feature requests using the
SourceForge tracker at:
http://sourceforge.net/tracker/?group_id=19015
There are direct links under 'Development' on the PythonCard home page:
http://pythoncard.sourceforge.net/
It is very easy for an idea or discussion thread on the list to be forgotten
in a few days as new topics come up, so adding something to the tracker
guarantees that it won't be completely forgotten. Of course, the more
precise descriptions are, the better, so you can include URLs to a list
posting in the description of any request you make. For example, if Neil
added "live property editor" to the Feature Requests he could include the
URL of the original post:
http://aspn.activestate.com/ASPN/Mail/Message/PythonCard/765179
The ASPN archive is preferred for this type of reference because the
interface is more flexible than the SF archive.
We may need to add additional trackers to help organize the different
Feature Requests.
ka

> From: Andy Todd
>
> There was discussion a few weeks (months?) ago on the list of storing
> the code and resource description in an XML format but nothing has come
> of that. There is no reason we can't do it, just that no one has got
> round to attempting an implementation yet. For the reason above, I'm not
> sure this has legs either but I am happy to stand corrected.
I have to interject my standard XML mantra here which is that "XML should be
created and read by programs, but never seen or edited by humans". As long
as it is likely that we will have to hand edit any resources or source code
I will resist putting them into XML. You'll thank me later :) Among other
things, you can't process invalid XML and so you need an XML editor that can
identify the specific problem line(s), while our current dictionary/list
files can be checked by any standard Python-aware editor or IDE to make sure
they are valid. They are also much easier on the eyes than XML. I guess
nobody remembers that HTML was never intended to be seen or edited by humans
either, but gee look at the mess we got ourselves into.
> My personal vote would be to maintain the python module format for the
> 'program' portion of each stack because then we are still dealing with
> 'pure' Python and all of the benefits that brings. For instance, it is
> possible currently to import and test a PythonCard class without running
> it in the framework as, to Python, each module just contains a class.
Excellent points!
This is also a good time to point out that all the code doesn't have to go
into a single module file. The only code that has to be in the background
class are the handlers for the widget events and even those can just be the
def and then a line that calls a method in a different function or class in
a completely different module file. However, if you need to reference the
background self... it might be more convenient to stick the code in the
background.
Some of the samples use multiple modules and some of the samples use classes
other than the main background. Most of the time when I put "everything" in
the subclass of Background, I was coding rapidly and got a bit lazy. I have
spent very little time refactoring the various samples.
ka

> From: Neil Hodgson
>
> Something I like to see in user interfaces is live updating where
> attributes are changed as the user fiddles with them rather than requiring
> pressing an "Apply" button. To this end, the property editor can
> be changed
> to apply changes to the text areas and check boxes immediately by adding
> this just after the EVT_BUTTON section of debug.py:
I'll try playing with this tomorrow. In theory I like this idea, but the
poorly written code we have today (my bad) is too fragile. I would much
rather see the Property Editor rewritten with a better interface and a more
robust system before making it handle live updates. Are there particular
fields you really want live updates on more than others? The one thing I
really dislike about live updates is that it is too easy to mess something
up accidentally, which implies that we need Undo/Redo.
> A problem with this is that some settings such as the file names used
> within image controls will cause error messages with partially
> updated file
> names. Mostly, these should be changed to just silently handle failure or
Doesn't this happen for almost all of the text fields? A partial position,
size, foregroundColor, backgroundColor, file, or font are problematic,
right? So, are you saying that we eliminate being able to hand edit the text
field contents?
> perhaps have a status area indicator that the field is invalid. For file
> names, the file open dialog should ensure that only valid file names are
> applied and this has the advantage of being able to select files
> rather than
> just type their names.
Yes, not having a file selection dialog was an oversight. I also realized
yesterdy that I shouldn't be using eval() on the contents, since that means
if you use a valid class name... say as a 'label' you'll get an error.
> I haven't changed CVS as there may be other opinions and this change
> could be made an option instead of always being on.
Let's wait and see what other people say. Would it help if the "Update"
button was the default button?
ka

> From: Peter Cleaveland
>
> One thing I loved about HyperCard was the nice clean script encapsulation
> it provided. The samples seem to have all the code in one
> module - while
The one module usage right now is partly due to the limited requirements
document which we're slowly getting past, but the apps right now are still
mostly one background, one window, one module. As Andy brought up in an
earlier message, we probably should change the tight coupling between the
.rsrc.py and module, it is an artifact of the original loader. We'll
probably wait to do that until we are doing multiple backgrounds, multiple
possible layouts for a given background, cards, etc. This is a prototype, so
we get to experiment.
> that's often the best design, it's not as physically intuitive. Each
> HyperCard object had a script property, making an ideal place to store
> handlers applicable to that object, even if the objects name
> changed or it
> was copied to another stack. That was always more satisfying to me than
> the all-in-one approach that Visual Basic takes to handlers, where one
> change to the object name breaks every link. I wonder how hard
> it would be
> to implement script encapsulation in PythonCard.
On one hand, I can't tell you how many times I've held down the Control and
Alt keys and then tried to click on a button to edit its script in
PythonCard while the app is running. Of course, not only were they the wrong
keys, but I'm not even using HyperCard. While I loved being able to get
right at the script for a particular widget in HyperCard it had its own
problems, not the least of which is playing the "where is the script?" game.
A 'mouseDown' handler for a button might be in the card, background, stack,
Home, etc. layers and I don't think it was very intuitive once your code got
more complicated.
We have an issue similar to the VB name problem you mention above because
you have to keep your .rsrc.py component names and your handler names
synchronized. At some point, we should be able to provide some tools to help
identify mismatches, but as long as you can edit any files by hand it will
be a problem. This issue gets even worse once you are saving data that is
tied to the widget names/ids, especially if you're using an object storage
system like ZODB. Changing an id can break the whole app and cause you to
lose all your data. A complete environment can protect the user from that by
controlling all the objects, scripts, and data, but still support different
editing styles.
> Perhaps an object script could be stored as a dictionary of
> functions keyed
> by function name? Then the script could be a property of an object, in
> true HyperCard sense. Of course, that implies a built in script editor to
> manage the scripts - perhaps a subset of IDLE. Sigh - I can see it all
> gets rather complicated.
That is probably one approach we'll try. It is going to make life more
difficult, but I would like to always support creating apps using just a
text editor such as Emacs and not force the use of the complete environment
to build every app. Of course, we don't have a complete environment yet, so
right now you don't have a choice. ;-)
The framework has to make sense and work correctly regardless of the
environment we eventually create, so in the short term the scripts will
continue to look pretty much like they do today to the user/programmer.
ka

I'm channeling Kevin here, and will probably find that our responses 
will cross on the way to the list server, but;
Peter Cleaveland wrote:
> One thing I loved about HyperCard was the nice clean script 
> encapsulation it provided. The samples seem to have all the code in 
> one module - while that's often the best design, it's not as physically 
> intuitive. Each HyperCard object had a script property, making an ideal 
> place to store handlers applicable to that object, even if the objects 
> name changed or it was copied to another stack. That was always more 
> satisfying to me than the all-in-one approach that Visual Basic takes to 
> handlers, where one change to the object name breaks every link. I 
> wonder how hard it would be to implement script encapsulation in 
> PythonCard.
I'd say this is a great idea as well. It makes it incredibly obvious to 
the user exactly which object their code is tied to. However, PythonCard 
is currently a prototype and this kind of functionality will definitely 
have to wait until someone writes a specific IDE - unless you are 
volunteering? ;-)
The current set up is simple and efficient from a programming point of 
view though, you only need two files for each stack, a resource 
description and a standard python module to include the class that 
controls the stack.
So, if we are to provide an IDE to allow the editing of functions in 
place I would suggest that it would need to be clever enough to manage 
to read and write files in the current format (a bit like resourceEditor 
does for rsrc files). This would mean no changes to the file format so 
that us command line bigots can carry on as normal.
> 
> Perhaps an object script could be stored as a dictionary of functions 
> keyed by function name? Then the script could be a property of an 
> object, in true HyperCard sense. Of course, that implies a built in 
> script editor to manage the scripts - perhaps a subset of IDLE. Sigh - 
> I can see it all gets rather complicated.
There was discussion a few weeks (months?) ago on the list of storing 
the code and resource description in an XML format but nothing has come 
of that. There is no reason we can't do it, just that no one has got 
round to attempting an implementation yet. For the reason above, I'm not 
sure this has legs either but I am happy to stand corrected.
My personal vote would be to maintain the python module format for the 
'program' portion of each stack because then we are still dealing with 
'pure' Python and all of the benefits that brings. For instance, it is 
possible currently to import and test a PythonCard class without running 
it in the framework as, to Python, each module just contains a class.
> 
> Peter
> 
Regards,
Andy
-- 
-----------------------------------------------------------------------
 From the desk of Andrew J Todd esq.
"Shave my poodle!"

 Something I like to see in user interfaces is live updating where
attributes are changed as the user fiddles with them rather than requiring
pressing an "Apply" button. To this end, the property editor can be changed
to apply changes to the text areas and check boxes immediately by adding
this just after the EVT_BUTTON section of debug.py:
 EVT_TEXT(self, self.wTextArea.GetId(), self.onSelectUpdate)
 EVT_TEXT(self, self.wField.GetId(), self.onSelectUpdate)
 EVT_CHECKBOX(self, self.wChecked.GetId(), self.onSelectUpdate)
 To make the font and colour dialogs take immediate effect, add
 self.onSelectUpdate(event)
 as the last line of onSelectColor and onSelectFont inside the if
dlg.accepted() condition.
 A problem with this is that some settings such as the file names used
within image controls will cause error messages with partially updated file
names. Mostly, these should be changed to just silently handle failure or
perhaps have a status area indicator that the field is invalid. For file
names, the file open dialog should ensure that only valid file names are
applied and this has the advantage of being able to select files rather than
just type their names.
 I haven't changed CVS as there may be other opinions and this change
could be made an option instead of always being on.
 Neil

One thing I loved about HyperCard was the nice clean script encapsulation 
it provided. The samples seem to have all the code in one module - while 
that's often the best design, it's not as physically intuitive. Each 
HyperCard object had a script property, making an ideal place to store 
handlers applicable to that object, even if the objects name changed or it 
was copied to another stack. That was always more satisfying to me than 
the all-in-one approach that Visual Basic takes to handlers, where one 
change to the object name breaks every link. I wonder how hard it would be 
to implement script encapsulation in PythonCard.
Perhaps an object script could be stored as a dictionary of functions keyed 
by function name? Then the script could be a property of an object, in 
true HyperCard sense. Of course, that implies a built in script editor to 
manage the scripts - perhaps a subset of IDLE. Sigh - I can see it all 
gets rather complicated.
Peter

On Monday 03 September 2001 11:01 pm, Kevin Altis wrote:
> > From: Ron Johnson
> >
> > On Monday 03 September 2001 10:41 pm, Steven D. Arnold wrote:
> > > Hi all,
> > >
> > > Has any thought been given to a possible object component model?=20
> > > It
[snip]
Gnome & KDE are the competing Unix/Linux desktops, and they each
have their own component object models. Each is, of course, in-
compatable with MS COM.
--=20
Mon Sep 3 23:07:39 2001
Seq. Timestamp Uptime
---- ------------------------ ------------
 1: Mon Jul 16 16:28:17 2001 - 43 07:21:59 - 2.4.6-3mdk
 2: Thu May 17 01:44:04 2001 - 35 15:31:51 - 2.4.3-20mdk
 3: Thu Jun 21 17:33:18 2001 - 10 05:29:02 - 2.4.3-20mdk
 4: Sun Jul 1 23:03:05 2001 - 7 10:13:18 - 2.4.3-20mdk
 5: Wed Jul 11 15:11:11 2001 - 5 01:16:26 - 2.4.6-3mdk
11: Mon Sep 3 21:34:47 2001 - 0 01:32:52 - 2.4.9 <<--

> From: Ron Johnson
> 
> On Monday 03 September 2001 10:41 pm, Steven D. Arnold wrote:
> > Hi all,
> >
> > Has any thought been given to a possible object component model? It
> [snip]
> > Picking either of these would provide the added advantage of
> > compatibility with other software using that model....
> >
> > Comments?
> 
> But it would reduce (nay, eliminate) portability.
> 
> -- 
> Mon Sep 3 22:43:49 2001
> Seq. Timestamp Uptime
> ---- ------------------------ ------------
> 1: Mon Jul 16 16:28:17 2001 - 43 07:21:59 - 2.4.6-3mdk
> 2: Thu May 17 01:44:04 2001 - 35 15:31:51 - 2.4.3-20mdk
> 3: Thu Jun 21 17:33:18 2001 - 10 05:29:02 - 2.4.3-20mdk
> 4: Sun Jul 1 23:03:05 2001 - 7 10:13:18 - 2.4.3-20mdk
> 5: Wed Jul 11 15:11:11 2001 - 5 01:16:26 - 2.4.6-3mdk
> 12: Mon Sep 3 21:34:47 2001 - 0 01:09:02 - 2.4.9 <<--
I give up, what does this mean?
ka

> From: Steven D. Arnold
>
> Has any thought been given to a possible object component model? It
> seems we'd want to use one that was non-proprietary and open-source.
> The KOM/Kparts model seems nice, from what I've read. The only thing
> I might object to is, if it used Qt and that couldn't be easily
> removed, I wouldn't want to get into a situation where one couldn't
> build a PythonCard app without paying TrollTech.
>
> Another option is the GNOME object model. I don't know much about
> that, other than that it exists.
I know less than you about GNOME or KOM/Kparts. If your talking about
something like COM, so that we can have plug in components for PythonCard,
then about the only discussion we've had was about XPCOM. I can't get to
ASPN right now, so I can't point you to the Python XPCOM mailing list. I'm
hoping that will be a good system to piggyback on.
I think that it is unlikely we will use any Qt stuff. Does anything outside
of COM on Windows actually have many components available today? One thing
that makes COM slightly less important for us than say Visual Basic apps is
that it should be relatively easy to write custom widgets using Python and
possibly wrapping existing widgets to make compound widgets. That is an
experiment someone should try fairly soon.
ka

On Monday 03 September 2001 10:41 pm, Steven D. Arnold wrote:
> Hi all,
>
> Has any thought been given to a possible object component model? It
[snip]
> Picking either of these would provide the added advantage of
> compatibility with other software using that model....
>
> Comments?
But it would reduce (nay, eliminate) portability.
--=20
Mon Sep 3 22:43:49 2001
Seq. Timestamp Uptime
---- ------------------------ ------------
 1: Mon Jul 16 16:28:17 2001 - 43 07:21:59 - 2.4.6-3mdk
 2: Thu May 17 01:44:04 2001 - 35 15:31:51 - 2.4.3-20mdk
 3: Thu Jun 21 17:33:18 2001 - 10 05:29:02 - 2.4.3-20mdk
 4: Sun Jul 1 23:03:05 2001 - 7 10:13:18 - 2.4.3-20mdk
 5: Wed Jul 11 15:11:11 2001 - 5 01:16:26 - 2.4.6-3mdk
12: Mon Sep 3 21:34:47 2001 - 0 01:09:02 - 2.4.9 <<--

> From: Peter Cleaveland
>
> >After we are happy with our Font implementation I will be
> getting more into
> >sizers. I already have an idea how we might implement them so that their
> >description would be relatively easy to grasp.
>
> I just checked out the sizers demo that came with wxWindows and I'm very
> impressed - I wish I had that kind of control in the HTML world.
> I can see
> they would be a huge asset to PythonCard - if they could be made
> understandable and approachable. Seems to me an interactive,
> drag-and-drop
> sizer editor would make all the difference in the world. I'll
> probably get
> some ideas for an editor once my own stacks come far enough along to need
> sizers.
wxDesigner http://www.roebling.de/ is supposed to use sizers for layout, but
I have only looked at it briefly, so I don't know whether the interface is
intuitive or not. From what I've read so far, I'm sure I want to support the
full range of sizer controls in wxWindows, it just seems too complicated,
but I need to get a straw man implementation done and play with it before I
can say more.
> >There is actually quite a lot of work going into the wxHTML control for
> >wxWindows and even in the upcoming wxWindows/wxPython 2.3.2 it
> will be much
> >more capable than the one available today. We won't be able to do a GUI
> >layout editor that uses HTML, that is simply too complicated, but we will
> >probably be able to support the use of HTML with embedded widgets for
> >layouts sometime in the future if somebody wants to go that route.
Neil actually did a demo that uses the .rsrc.py files to make a web page
suitable for use in a browser, so the layout of PythonCard background can
sort of be used as HTML. I thought Neil was going to check the files into
cvs at:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pythoncard/proto/samples/
but I don't see the files (Neil can you check them in?). The original
message is:
http://groups.yahoo.com/group/pythoncard/message/397
You'll either need to check out the 'proto' cvs tree or I'll need to make
release 0.2.1 available for download again, since it is currently hidden to
avoid people downloading old versions. If you decide to check out from cvs,
0.2.1 is not a package and is significantly different from the current
release, so don't mix the two.
Perhaps it might be best for Neil to go into this subject more when he gets
time or the framework stabilizes to the point that someone can experiment
with this without having to update the files with every API change.
ka

Hi all,
Has any thought been given to a possible object component model? It
seems we'd want to use one that was non-proprietary and open-source.
The KOM/Kparts model seems nice, from what I've read. The only thing
I might object to is, if it used Qt and that couldn't be easily
removed, I wouldn't want to get into a situation where one couldn't
build a PythonCard app without paying TrollTech.
Another option is the GNOME object model. I don't know much about
that, other than that it exists.
Picking either of these would provide the added advantage of
compatibility with other software using that model....
Comments?
------------------------------------------------------------------------
Steven D. Arnold st...@ne...
AIM: abraxan ICQ: 73804392
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

> From: Peter Cleaveland
>
> I'm a big fan of a complete event model when I can get it. At
> first I was
> surprised to see the mouseMove() event, which was not present in
> HyperCard. But I assume it's there because wxWindows provides it, and I
> can see utility. In HC I used to do Drag handlers in a loop on
> mouseDown(), but it would be more natural to use mouseMove(), so
> as not to
> block the thread.
There is a 'mouseDrag' event which occurs instead of 'mouseMove' if the
mouse button is down. The resourceEditor sample uses it. The event system
underlying wxPython doesn't support the type of 'on mouseDown' loop used in
HyperCard for the reason you mentioned, which is that it blocks the thread,
so neither does PythonCard. The main difference is that you need to make
sure that you set up your initialization and cleanup code correctly and then
don't block during each 'mouseMove' or 'mouseDrag' event.
Another thing that is different is that 'mouseDrag', 'mouseEnter' and
'mouseLeave' behave a bit differently than you might expect when you're
doing a drag that takes the cursor outside the rect of the widget. There is
a bug in wxWindows/wxPython that causes mouseEnter/mouseLeave events to fire
repeatedly which each drag. There are some related bugs, but we'll have to
wait until wxPython 2.3.2 comes out to see how it works in the new version.
> I'm in favor of keeping KeyDown and KeyUp. Some applications (especially
> games) can't be done without these events. Of course, if they slow down
> the event loop too much, I might wish for a way to turn them off. If
> performance became as issue, perhaps a set of flags could enable/disable
> each event type, with less common events turned off by default.
IIRC, when Rowland and I initially discussed how this would work I was in
favor of binding all events, all the time, but Rowland only wanted to bind
the ones being used. So, in Rowland's system no events would be generated
unless there was a corresponding handler to respond to the event such as
'on_button1_mouseClick'. wxPython would still be doing some events behind
the scenes, but they wouldn't go through the overhead of our event system,
be reported in the Message Watcher, etc.
It turned out that it was much easier to implement the event system by
binding all the events, but only dispatching if there was a handler
available. If you're learning or debugging, it is very helpful to see all
the messages, even the 'unused' ones. In addition, the system we currently
have in place means that theoretically you should be able to create a new
handler when the program is running and have it bind correctly, but I
haven't got it working yet.
Anyway, we can probably support both systems so that no binding is ever done
unless a handler exists to support an event when the programmer wants a more
static, efficient event flow. We'll need to revisit that idea later on, I
don't think it is appropriate to refactor right now.
ka

At 06:38 PM 9/2/2001 -0700, pyt...@li... 
wrote:
>After we are happy with our Font implementation I will be getting more into
>sizers. I already have an idea how we might implement them so that their
>description would be relatively easy to grasp.
I just checked out the sizers demo that came with wxWindows and I'm very 
impressed - I wish I had that kind of control in the HTML world. I can see 
they would be a huge asset to PythonCard - if they could be made 
understandable and approachable. Seems to me an interactive, drag-and-drop 
sizer editor would make all the difference in the world. I'll probably get 
some ideas for an editor once my own stacks come far enough along to need 
sizers.
>There is actually quite a lot of work going into the wxHTML control for
>wxWindows and even in the upcoming wxWindows/wxPython 2.3.2 it will be much
>more capable than the one available today. We won't be able to do a GUI
>layout editor that uses HTML, that is simply too complicated, but we will
>probably be able to support the use of HTML with embedded widgets for
>layouts sometime in the future if somebody wants to go that route.
That's fantastic - I have been thinking all along that HTML would be a nice 
way to Python output, simply because it's familiar and has so many tools 
these days. But I assumed I would have to build it to emulate a web server 
(Ugh) and couple it to Internet Explorer (Double-Ugh). A wxHTML control 
with embedded widgets would be perfect, especially for generating dynamic 
interface elements at run-time. Perhaps it could use Action Sheets (as 
described in W3C NOTE-AS-19980619) as way to associate the 
handlers. <http://www.w3.org/TR/NOTE-AS> That would be a nice tidy 
package if you ask me.

At 06:05 PM 9/3/2001 -0700, pyt...@li... 
wrote:
>Just because we can support key down and up (and indeed mouse down and mouse
>up) do we actually need these events in PythonCard? In the spirit of
>KISS maybe we could leave them out. Or not, I'm just thinking out loud
>here so feel free to join in if you have an opinion.
I'm a big fan of a complete event model when I can get it. At first I was 
surprised to see the mouseMove() event, which was not present in 
HyperCard. But I assume it's there because wxWindows provides it, and I 
can see utility. In HC I used to do Drag handlers in a loop on 
mouseDown(), but it would be more natural to use mouseMove(), so as not to 
block the thread.
I'm in favor of keeping KeyDown and KeyUp. Some applications (especially 
games) can't be done without these events. Of course, if they slow down 
the event loop too much, I might wish for a way to turn them off. If 
performance became as issue, perhaps a set of flags could enable/disable 
each event type, with less common events turned off by default.

Kevin Altis wrote:
>>From: Andy Todd
>>
>>Perusing spec.py I noticed a small typo. The event name 'keyUp' was
>>incorrectly entered as 'keUp' in the events list for 'widget'. This
>>would stop any key up event handlers from working in current and
>>previous releases. This has now been fixed and updated in cvs and should
>>be included in the next release.
>>
>>There, we can all breathe a sigh of relief now ;-)
>>
>>Whilst I was looking at the event model I wondered if anyone has felt
>>the need to write a key down or key up event handler? I can't recall
>>ever doing so, key press is sufficient for most of my requirements. Just
>>because we can support key down and up (and indeed mouse down and mouse
>>up) do we actually need these events in PythonCard? In the spirit of
>>KISS maybe we could leave them out. Or not, I'm just thinking out loud
>>here so feel free to join in if you have an opinion.
>>
> 
> Events that you can ignore don't really make the system more complex. You
> can typically ignore mouseDown and mouseUp and just use mouseClick, but when
> you need them, they are really nice (see resourceEditor.py).
Just goes to prove that just because I don't use it doesn't mean that it 
isn't useful. Thanks for that Kevin, and now that I actually wind my 
brain into gear I can help but think this will be useful.
> 
> If you look at
> 
> class wxPython_TextFieldEventBinding
> 
> in wxPython_binding, you'll see that the only events bound right now are
> 'textUpdate' and 'textEnter'. I had written the code to do the other text
> events but it was before we got cvs going and while Rowland and I were
> emailing files back and forth the code got dropped. There may also have been
> some issues with calling Event.Skip() in wxPython, but I can't remember.
> Anyway, I need to get back into the event binding code, add the missing
> events, add closeField and/or exitField like I planned to a long time ago
> (well six weeks seems like a long time) and then verify that everything
> works as planned. I'll try and do that this week.
> 
> ka
> 
I guess our initial approach should be to cope with all of the events 
specified by wxPython and then review what is and isn't required later. 
I really should get round to reading the documentation then I may be 
able to comment intelligently.
In the medium(ish) term I can see the need to add events to PythonCard 
specific objects (like the ability to map mouse click to a background as 
show in tictactoe.py) and perhaps we should lend some thought to what is 
useful and practicable here as well. Of course, this will be brought 
into focus when (if?) we implement multiple cards on a background and/or 
multiple windows as we will then need to cope with a whole heap of 
navigation events.
Regards,
Andy
-- 
-----------------------------------------------------------------------
 From the desk of Andrew J Todd esq.
"Shave my poodle!"

The short answer is that you should be able to do this in PythonCard. When
you run into specific problems related to PythonCard, just post the
questions here. It sounds like a lot of your journey is going to be learning
to design a non-modal visual interface for a program that was previously a
linear series of steps. Off the top of my head I'm not sure what resources
to point you towards, hopefully someone else on the list can provide some
pointers.
Validators:
One thing that PythonCard definitely doesn't provide you with right now are
'validators' which are sort of like your 'get_number' function below. We'll
probably have validators later, wxPython even provides a hook for them, but
for now you'll probably want to make it more like an HTML form where the
user enters input in a bunch of fields, and then presses a "Submit" or
"Calculate" button and if one of the fields has invalid input you will
present an error message and they can redo the input.
You could also check the input with a 'loseFocus' handler and when we have a
closeField messages being generated this will be even simpler; closeField
means that not only did the field lose focus, but that the text changed too.
Turn on the Message Watcher and uncheck 'Hide unused' to see these events
occurring as you tab and click between fields.
Anyway, in the short term what you can do is have a 'gainFocus' handler
which saves the current value of the field in variable, then a 'loseFocus'
handler which compares the original value to the current value and if they
are different (text changed), then it will do your validation test and if
the data isn't valid, you present an error dialog and then set the focus
back to the field and select all the text. That is a very common user
interface for text validation in GUIs. Other people on the list can probably
suggest other methods.
This is the kind of thing I'll try and add to one of the samples, unless
someone beats me to it.
ka
> -----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.
>
> 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.
>
> I have previosuly tried to code a gui version of this in Tkinter,
> but I became frustrated before I had a working version.
>
> 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?
>
> 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.
>
> I am thinking of using sliders for data entry, although I could
> use other forms of data input, obviously.
>
> If any one has any comments, or general suggetions before I get
> too far along on this project, please let me know.
>
> 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.
>
>
> Ron Stephens
>
> #
> # This is a decision analysis program that was my first real
> Python program, based on weighted
> # averages of scores on several criteria for various questions
> that need to be decided.
> # There is a general program for any kind of decision, allowing
> user input of options
> # to be decided amongst and criteria to use for decisions; and
> then there are a few
> # examples of specific options to be decided amongst with
> pre-coded "values' or scores
> # for the various options for various criteria.
> # It is my goal to code this program using PythonCard.
>
>
>
> print "A General Decision Analysis Program."
> print
> print "Have You Ever Had to Make Up Your Mind?"
> print
>
> import sys
>
> def get_number(prompt, lower=sys.maxint * -1, upper=sys.maxint):
> """ get_number(prompt) -> float
>
> This function prompts for a number. If the user enters bad input, such as
> 'cat' or '3l', it will prompt again.
> Now checks for upper and lower bounds.
> """
> res = None
> while res is None:
> try:
> res = float(raw_input(prompt))
> try:
> assert lower <= res <= upper
> except AssertionError:
> print "Value must be between", lower, \
> "and", upper
> res = None
> except ValueError: pass
>
>
> return res
>
>
> def get_list(heading, prompt):
>
> print heading
> print
> print "(enter a blank line to end the list)"
> ret = []
> i = 1
> while 1:
> line = raw_input(prompt % i)
> if not line:
> break
> ret.append(line)
> i=i+1
> print
> return ret
>
> def get_user_rankings(criteria):
> # Next, get the user to rank his criteria. I use a system
> where higher
> # is better, so that an undesirable characteristic can be
> given a negative
> # weight.
> #
> # {} is a dictionary, it can be indexed by (nearly) any expression,
> # and we will index it with the names of the criteria.
>
> rankings = {}
> print
> print "Enter relative importance of criteria (higher is more
> important)"
> print
> for c in criteria:
> rankings[c] = get_number("Criterion %s: " % c)
> return rankings
>
> def get_user_scores(options, criteria):
> # Next, get the user to score each option on all the criteria.
> # Scores are stored as a two-dimensional dictionary, like so:
> # {'option1': {'criteria1': 100, 'criteria2': 10},
> # 'option2': {'criteria1': 50, 'criteria2': 10}
> # }
> scores = {}
> print
> print "Enter score for each option on each criterion"
> print
> for o in options:
> scores[o] = {}
> print
> print "Scores for option %s" % o
> print
> for c in criteria:
> scores[o][c] = get_number("Criterion %s: " % c)
> return scores
>
> def calculate_results(options, scores, rankings):
> # Calculate the resulting score for each option. This equation
> # is different from Rod Stephen's original program, because I
> # make more important criteria have higher rankings, and even let
> # bad criteria have negative rankings.
>
> # The "result" dictionary is indexed with the names of the options.
> result = {}
> # Criteria can be found automatically, doesn't need to be
> # passed as an argument.
> criteria = scores[options[0]].keys()
> for o in options:
> value = 0
> for c in criteria:
> # print o, c, rankings[c], scores[o][c]
> value = value + rankings[c] * scores[o][c]
> result[o] = value
> return result
>
> def ranked_list(results):
> # Now, I want to take the dictionary result, and turn it into
> a ranked list
>
> results = results.items() # A list of tuples (key, value)
> results.sort(lambda x, y: -cmp(x[1], y[1]))
> # Sort the list using the reverse of the
> # "value" of the entry, so that higher
> # values come first
> return results
>
>
> def generic_decision_analyzer(options, criteria):
> pass
>
> def decisionanalysis():
> # This code is placed in the public domain
> print
> print "This is a general decision program, and you can define
> your choices and criteria."
> print
> print "When prompted, please enter the options or choices
> that you need to decide amongst."
> print
> print "Then, when prompted, enter the criteria for making
> this decision."
>
>
> # First, ask the user to enter the lists
> options = get_list("Enter your options:", "Option %d: ")
> criteria = get_list("Now, enter your criteria:", "Criterion %d: ")
>
> print "A program to help you make decisions."
> rankings = get_user_rankings(criteria)
> scores = get_user_scores(options, criteria)
> results = ranked_list(calculate_results(options, scores, rankings))
> print
> print "Results, in order from highest to lowest score"
> print
> print "%5s\t%s" % ("Score", "Option")
>
> # Take the pairs out of results in order, and print them out
> for option, result in results:
> print "%5s\t%s" % (result, option)
>
>
>
> # Here's the scores used by the language-choice functions.
> language_scores = {"Python": {"ease of learning":100,
> "ease of use":100,
> "speed of program execution":10,
> "quality of available tools":70,
> "popularity":50,
> "power & expressiveness":100,
> "cross platform?":100,
> "cost":100},
> "Perl": {"ease of learning":50,
> "ease of use":60,
> "speed of program execution":20,
> "quality of available tools":50,
> "popularity":85,
> "power & expressiveness":70,
> "cross platform?":100,
> "cost":100},
> "Ruby": { "ease of learning":50,
> "ease of use":100,
> "speed of program execution":20,
> "quality of available tools":20,
> "popularity":10,
> "power & expressiveness":100,
> "cross platform?":80,
> "cost":100},
> "Tcl": {"ease of learning":100,
> "ease of use":100,
> "speed of program execution":10,
> "quality of available tools":50,
> "popularity":40,
> "power & expressiveness":10,
> "cross platform?":100,
> "cost":100},
> "JavaScript": {"ease of learning":70,
> "ease of use":75,
> "speed of program execution":10,
> "quality of available tools":50,
> "popularity":100,
> "power & expressiveness":40,
> "cross platform?":50,
> "cost":100},
> "Visual Basic": {"ease of learning":50,
> "ease of use":100,
> "speed of program execution":20,
> "quality of available tools":100,
> "popularity":100,
> "power & expressiveness":50,
> "cross platform?":1,
> "cost":1},
> "Java": {"ease of learning":15,
> "ease of use":50,
> "speed of program execution":50,
> "quality of available tools":100,
> "popularity":90,
> "power & expressiveness":100,
> "cross platform?":100,
> "cost":100},
> "C++": {"ease of learning":10,
> "ease of use":25,
> "speed of program execution":90,
> "quality of available tools":90,
> "popularity":80,
> "power & expressiveness":100,
> "cross platform?":90,
> "cost":100},
> "C": {"ease of learning":15,
> "ease of use":20,
> "speed of program execution":100,
> "quality of available tools":80,
> "popularity":80,
> "power & expressiveness":80,
> "cross platform?":110,
> "cost":100},
> "Lisp": {"ease of learning":40,
> "ease of use":50,
> "speed of program execution":80,
> "quality of available tools":60,
> "popularity":25,
> "power & expressiveness":110,
> "cross platform?":80,
> "cost":90},
> "Delphi": {"ease of learning":50,
> "ease of use":110,
> "speed of program execution":85,
> "quality of available tools":100,
> "popularity":30,
> "power & expressiveness":100,
> "cross platform?":80,
> "cost":10}
> }
>
>
>
> def ProgramLanguageFinal():
> print "This is a program to help give you an idea which
> programming languages you should consider learning."
> print "While there are any number of languages you might
> consider, this program considers only 11 of the most popluar ones."
> print
> print "The program will ask you to input a ranking or
> weighting for a number of criteria that may be of importance"
> print "in choosing your next programming language."
>
> # First look up the criteria listed in the scores.
> # To do that, we need a language name, which can also
> # be looked up from the scores.
> languages = language_scores.keys()
> some_language = languages[0]
> criteria = language_scores[some_language].keys()
> rankings = get_user_rankings(criteria)
> results = ranked_list(calculate_results(languages,
> language_scores, rankings))
> # Take the pairs out of results in order, and print them out
> for option, result in results:
> print "%5s\t%s" % (result, option)
>
>
> def ProgramLanguageScript():
> print
> print "This is a program to help you choose a scripting language."
> print
> print "You will be asked to rank some important criteria as
> to their relative importance to you."
> print "These criteria are 'ease of learning', 'ease of use',
> 'speed of program execution'"
> "'quality of available tools', 'popularity', and 'power &
> expressiveness'"
> print
> print "Please rank each of the criteria with a number from 1
> to 100 when prompted."
> print
> print "100 means of highest relative importance, 1 means of
> least importance."
>
> # This time we want a subset of languages, so I'm going to
> specify them.
> options = ["Python", "Perl", "Ruby", "Tcl", "JavaScript",
> "Visual Basic"]
> criteria = language_scores[options[0]].keys()
> rankings = get_user_rankings(criteria)
> results = ranked_list(calculate_results(options,
> language_scores, rankings))
> # Take the pairs out of results in order, and print them out
> for option, result in results:
> print "%5s %s" % (result, option)
>
>
> def Basketball():
> print "This is a program to help you decide which team will
> win a basketball game"
> print
> print "When prompted, enter a number ranking each team on the
> prompted team skill"
> print "on a scale from 1 to 100, with 1 being terrible and
> 100 being the best imaginable"
> print
> team_one = raw_input ("What is the name of team one: ")
> team_two = raw_input ("What is the name of team two: ")
> teams = (team_one, team_two)
>
> rankings = {"speed":100, "size":66, "jumping_ability":50,
> "defense":60, "shooting":75, "ballhandling":50, "rebounding":50}
> criteria = rankings.keys()
> scores = {team_one: {},
> team_two: {}}
> for c in criteria:
> for team in (team_one, team_two):
> scores[team][c] = get_number("rank the team %s of %s
> on a scale of 1 to 100: " % (c, team), 1, 100)
>
> results = calculate_results(teams, scores, rankings)
> for team in teams:
> print "%s has a power ranking of %d" % (team, results[team])
> # Now, who won?
> ranked_results = ranked_list(results)
> # Compare the scores.
> if ranked_results[0][1] == ranked_results[1][1]:
> print "the two teams are a toss-up!!!"
> else:
> print "%s wins!!" % ranked_results[0][0]
>
>
> def YesNo():
> print "Program to help you make a Yes or No decision."
> options = ["Yes", "No"]
> criteria = get_list("Enter your criteria ...", "Criterion %d: ")
>
> rankings = get_user_rankings(criteria)
> scores = get_user_scores(options, criteria )
> print `scores`
> results = ranked_list(calculate_results(options, scores, rankings))
> print
> print "The results are"
> print
> print "%5s %s" % ("Score", "Option")
>
> for option, result in results:
> print "%5s %s" % (result, option)
>
> if results[0] > results[1]:
> print "You should decide Yes!!!"
>
> else:
> print
> print "You should decide No!!!"
> print
>
>
> ###### MAIN LOOP ############
>
> while 1: # loop forever
>
> print "Please enter the number for the type of decision you
> wish to analayze:"
> print "1. General Decision Analysis, you choose the options,
> criteria, etc."
> print "2. Help in Choosing Programming Language amongst 11
> popular languages"
> print "3. Help in choosing scripting programming language
> amongst 6 scripting languages"
> print "4. Which Basketball Team will win the Game???"
> print "5. Questions with Yes or No type answers"
> choice = get_number("Please type in the number of the type of
> decision-program you wish to run from above and hit enter:", 1, 5)
>
> if choice ==1:
> decisionanalysis()
> elif choice ==2:
> ProgramLanguageFinal()
> elif choice ==3:
> ProgramLanguageScript()
> elif choice ==4:
> Basketball()
> elif choice ==5:
> YesNo()
> elif choice =="quit":
> break # exit from infinite loop
> else:
> print "Invalid operation"
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>

> From: Andy Todd
>
> Perusing spec.py I noticed a small typo. The event name 'keyUp' was
> incorrectly entered as 'keUp' in the events list for 'widget'. This
> would stop any key up event handlers from working in current and
> previous releases. This has now been fixed and updated in cvs and should
> be included in the next release.
>
> There, we can all breathe a sigh of relief now ;-)
>
> Whilst I was looking at the event model I wondered if anyone has felt
> the need to write a key down or key up event handler? I can't recall
> ever doing so, key press is sufficient for most of my requirements. Just
> because we can support key down and up (and indeed mouse down and mouse
> up) do we actually need these events in PythonCard? In the spirit of
> KISS maybe we could leave them out. Or not, I'm just thinking out loud
> here so feel free to join in if you have an opinion.
Events that you can ignore don't really make the system more complex. You
can typically ignore mouseDown and mouseUp and just use mouseClick, but when
you need them, they are really nice (see resourceEditor.py).
If you look at
class wxPython_TextFieldEventBinding
in wxPython_binding, you'll see that the only events bound right now are
'textUpdate' and 'textEnter'. I had written the code to do the other text
events but it was before we got cvs going and while Rowland and I were
emailing files back and forth the code got dropped. There may also have been
some issues with calling Event.Skip() in wxPython, but I can't remember.
Anyway, I need to get back into the event binding code, add the missing
events, add closeField and/or exitField like I planned to a long time ago
(well six weeks seems like a long time) and then verify that everything
works as planned. I'll try and do that this week.
ka

Perusing spec.py I noticed a small typo. The event name 'keyUp' was 
incorrectly entered as 'keUp' in the events list for 'widget'. This 
would stop any key up event handlers from working in current and 
previous releases. This has now been fixed and updated in cvs and should 
be included in the next release.
There, we can all breathe a sigh of relief now ;-)
Whilst I was looking at the event model I wondered if anyone has felt 
the need to write a key down or key up event handler? I can't recall 
ever doing so, key press is sufficient for most of my requirements. Just 
because we can support key down and up (and indeed mouse down and mouse 
up) do we actually need these events in PythonCard? In the spirit of 
KISS maybe we could leave them out. Or not, I'm just thinking out loud 
here so feel free to join in if you have an opinion.
Regards,
Andy
-- 
-----------------------------------------------------------------------
 From the desk of Andrew J Todd esq.
"Shave my poodle!"

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.
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.
I have previosuly tried to code a gui version of this in Tkinter, but I became frustrated before I had a working version.
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?
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.
I am thinking of using sliders for data entry, although I could use other forms of data input, obviously.
If any one has any comments, or general suggetions before I get too far along on this project, please let me know.
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.
Ron Stephens
#
# This is a decision analysis program that was my first real Python program, based on weighted
# averages of scores on several criteria for various questions that need to be decided.
# There is a general program for any kind of decision, allowing user input of options
# to be decided amongst and criteria to use for decisions; and then there are a few
# examples of specific options to be decided amongst with pre-coded "values' or scores
# for the various options for various criteria.
# It is my goal to code this program using PythonCard.
print "A General Decision Analysis Program."
print
print "Have You Ever Had to Make Up Your Mind?"
print
import sys
def get_number(prompt, lower=sys.maxint * -1, upper=sys.maxint):
 """ get_number(prompt) -> float
This function prompts for a number. If the user enters bad input, such as
'cat' or '3l', it will prompt again.
Now checks for upper and lower bounds.
"""
 res = None
 while res is None:
 try:
 res = float(raw_input(prompt))
 try:
 assert lower <= res <= upper
 except AssertionError:
 print "Value must be between", lower, \
 "and", upper
 res = None
 except ValueError: pass
 return res
def get_list(heading, prompt):
 print heading
 print
 print "(enter a blank line to end the list)"
 ret = []
 i = 1
 while 1:
 line = raw_input(prompt % i)
 if not line:
 break
 ret.append(line)
 i=i+1
 print
 return ret
def get_user_rankings(criteria):
 # Next, get the user to rank his criteria. I use a system where higher
 # is better, so that an undesirable characteristic can be given a negative
 # weight.
 #
 # {} is a dictionary, it can be indexed by (nearly) any expression,
 # and we will index it with the names of the criteria.
 rankings = {}
 print
 print "Enter relative importance of criteria (higher is more important)"
 print
 for c in criteria:
 rankings[c] = get_number("Criterion %s: " % c)
 return rankings
def get_user_scores(options, criteria):
 # Next, get the user to score each option on all the criteria.
 # Scores are stored as a two-dimensional dictionary, like so:
 # {'option1': {'criteria1': 100, 'criteria2': 10},
 # 'option2': {'criteria1': 50, 'criteria2': 10}
 # }
 scores = {}
 print
 print "Enter score for each option on each criterion"
 print
 for o in options:
 scores[o] = {}
 print
 print "Scores for option %s" % o
 print
 for c in criteria:
 scores[o][c] = get_number("Criterion %s: " % c)
 return scores
def calculate_results(options, scores, rankings):
 # Calculate the resulting score for each option. This equation
 # is different from Rod Stephen's original program, because I
 # make more important criteria have higher rankings, and even let
 # bad criteria have negative rankings.
 # The "result" dictionary is indexed with the names of the options.
 result = {}
 # Criteria can be found automatically, doesn't need to be
 # passed as an argument.
 criteria = scores[options[0]].keys()
 for o in options:
 value = 0
 for c in criteria:
 # print o, c, rankings[c], scores[o][c]
 value = value + rankings[c] * scores[o][c]
 result[o] = value
 return result
def ranked_list(results):
 # Now, I want to take the dictionary result, and turn it into a ranked list
 results = results.items() # A list of tuples (key, value)
 results.sort(lambda x, y: -cmp(x[1], y[1]))
 # Sort the list using the reverse of the
 # "value" of the entry, so that higher
 # values come first
 return results
def generic_decision_analyzer(options, criteria):
 pass
def decisionanalysis():
 # This code is placed in the public domain
 print
 print "This is a general decision program, and you can define your choices and criteria."
 print
 print "When prompted, please enter the options or choices that you need to decide amongst."
 print
 print "Then, when prompted, enter the criteria for making this decision."
 # First, ask the user to enter the lists
 options = get_list("Enter your options:", "Option %d: ")
 criteria = get_list("Now, enter your criteria:", "Criterion %d: ")
 print "A program to help you make decisions."
 rankings = get_user_rankings(criteria)
 scores = get_user_scores(options, criteria)
 results = ranked_list(calculate_results(options, scores, rankings))
 print
 print "Results, in order from highest to lowest score"
 print
 print "%5s\t%s" % ("Score", "Option")
 # Take the pairs out of results in order, and print them out
 for option, result in results:
 print "%5s\t%s" % (result, option)
# Here's the scores used by the language-choice functions.
language_scores = {"Python": {"ease of learning":100,
 "ease of use":100,
 "speed of program execution":10,
 "quality of available tools":70,
 "popularity":50,
 "power & expressiveness":100,
 "cross platform?":100,
 "cost":100},
 "Perl": {"ease of learning":50,
 "ease of use":60,
 "speed of program execution":20,
 "quality of available tools":50,
 "popularity":85,
 "power & expressiveness":70,
 "cross platform?":100,
 "cost":100},
 "Ruby": { "ease of learning":50,
 "ease of use":100,
 "speed of program execution":20,
 "quality of available tools":20,
 "popularity":10,
 "power & expressiveness":100,
 "cross platform?":80,
 "cost":100},
 "Tcl": {"ease of learning":100,
 "ease of use":100,
 "speed of program execution":10,
 "quality of available tools":50,
 "popularity":40,
 "power & expressiveness":10,
 "cross platform?":100,
 "cost":100},
 "JavaScript": {"ease of learning":70,
 "ease of use":75,
 "speed of program execution":10,
 "quality of available tools":50,
 "popularity":100,
 "power & expressiveness":40,
 "cross platform?":50,
 "cost":100},
 "Visual Basic": {"ease of learning":50,
 "ease of use":100,
 "speed of program execution":20,
 "quality of available tools":100,
 "popularity":100,
 "power & expressiveness":50,
 "cross platform?":1,
 "cost":1},
 "Java": {"ease of learning":15,
 "ease of use":50,
 "speed of program execution":50,
 "quality of available tools":100,
 "popularity":90,
 "power & expressiveness":100,
 "cross platform?":100,
 "cost":100},
 "C++": {"ease of learning":10,
 "ease of use":25,
 "speed of program execution":90,
 "quality of available tools":90,
 "popularity":80,
 "power & expressiveness":100,
 "cross platform?":90,
 "cost":100},
 "C": {"ease of learning":15,
 "ease of use":20,
 "speed of program execution":100,
 "quality of available tools":80,
 "popularity":80,
 "power & expressiveness":80,
 "cross platform?":110,
 "cost":100},
 "Lisp": {"ease of learning":40,
 "ease of use":50,
 "speed of program execution":80,
 "quality of available tools":60,
 "popularity":25,
 "power & expressiveness":110,
 "cross platform?":80,
 "cost":90},
 "Delphi": {"ease of learning":50,
 "ease of use":110,
 "speed of program execution":85,
 "quality of available tools":100,
 "popularity":30,
 "power & expressiveness":100,
 "cross platform?":80,
 "cost":10}
 }
def ProgramLanguageFinal():
 print "This is a program to help give you an idea which programming languages you should consider learning."
 print "While there are any number of languages you might consider, this program considers only 11 of the most popluar ones."
 print
 print "The program will ask you to input a ranking or weighting for a number of criteria that may be of importance"
 print "in choosing your next programming language."
 # First look up the criteria listed in the scores.
 # To do that, we need a language name, which can also
 # be looked up from the scores.
 languages = language_scores.keys()
 some_language = languages[0]
 criteria = language_scores[some_language].keys()
 rankings = get_user_rankings(criteria)
 results = ranked_list(calculate_results(languages, language_scores, rankings))
 # Take the pairs out of results in order, and print them out
 for option, result in results:
 print "%5s\t%s" % (result, option)
def ProgramLanguageScript():
 print
 print "This is a program to help you choose a scripting language."
 print
 print "You will be asked to rank some important criteria as to their relative importance to you."
 print "These criteria are 'ease of learning', 'ease of use', 'speed of program execution'"
 "'quality of available tools', 'popularity', and 'power & expressiveness'"
 print
 print "Please rank each of the criteria with a number from 1 to 100 when prompted."
 print
 print "100 means of highest relative importance, 1 means of least importance."
 # This time we want a subset of languages, so I'm going to specify them.
 options = ["Python", "Perl", "Ruby", "Tcl", "JavaScript", "Visual Basic"]
 criteria = language_scores[options[0]].keys()
 rankings = get_user_rankings(criteria)
 results = ranked_list(calculate_results(options, language_scores, rankings))
 # Take the pairs out of results in order, and print them out
 for option, result in results:
 print "%5s %s" % (result, option)
def Basketball():
 print "This is a program to help you decide which team will win a basketball game"
 print
 print "When prompted, enter a number ranking each team on the prompted team skill"
 print "on a scale from 1 to 100, with 1 being terrible and 100 being the best imaginable"
 print
 team_one = raw_input ("What is the name of team one: ")
 team_two = raw_input ("What is the name of team two: ")
 teams = (team_one, team_two)
 rankings = {"speed":100, "size":66, "jumping_ability":50, "defense":60, "shooting":75, "ballhandling":50, "rebounding":50}
 criteria = rankings.keys()
 scores = {team_one: {},
 team_two: {}}
 for c in criteria:
 for team in (team_one, team_two):
 scores[team][c] = get_number("rank the team %s of %s on a scale of 1 to 100: " % (c, team), 1, 100)
 results = calculate_results(teams, scores, rankings)
 for team in teams:
 print "%s has a power ranking of %d" % (team, results[team])
 # Now, who won?
 ranked_results = ranked_list(results)
 # Compare the scores.
 if ranked_results[0][1] == ranked_results[1][1]:
 print "the two teams are a toss-up!!!"
 else:
 print "%s wins!!" % ranked_results[0][0]
def YesNo():
 print "Program to help you make a Yes or No decision."
 options = ["Yes", "No"]
 criteria = get_list("Enter your criteria ...", "Criterion %d: ")
 rankings = get_user_rankings(criteria)
 scores = get_user_scores(options, criteria )
 print `scores`
 results = ranked_list(calculate_results(options, scores, rankings))
 print
 print "The results are"
 print
 print "%5s %s" % ("Score", "Option")
 for option, result in results:
 print "%5s %s" % (result, option)
 if results[0] > results[1]:
 print "You should decide Yes!!!"
 else:
 print
 print "You should decide No!!!"
 print
###### MAIN LOOP ############
while 1: # loop forever
 print "Please enter the number for the type of decision you wish to analayze:"
 print "1. General Decision Analysis, you choose the options, criteria, etc."
 print "2. Help in Choosing Programming Language amongst 11 popular languages"
 print "3. Help in choosing scripting programming language amongst 6 scripting languages"
 print "4. Which Basketball Team will win the Game???"
 print "5. Questions with Yes or No type answers"
 choice = get_number("Please type in the number of the type of decision-program you wish to run from above and hit enter:", 1, 5)
 if choice ==1:
 decisionanalysis()
 elif choice ==2:
 ProgramLanguageFinal()
 elif choice ==3:
 ProgramLanguageScript()
 elif choice ==4:
 Basketball()
 elif choice ==5:
 YesNo()
 elif choice =="quit":
 break # exit from infinite loop
 else:
 print "Invalid operation"