in need of some help...

[Alex Norton]

On Wednesday, 1 May 2013 13:15:28 UTC+1, Jens Thoms Toerring  wrote:
> Alex Norton <ayjayn1101 at gmail.com> wrote:
> 
> > thanks... ill take a look at the Qt event handling
> 
> 
> 
> It's rather simple: instead of the program running through a
> 
> sequence of steps, the program normally is basically doing
> 
> nothing. It just reacts to events that normally come from
> 
> the user, i.e. the user clicks on some icon or widget, or
> 
> (s)he enters something via the keyboard. You etermine which
> 
> of all the possible events to which widget are relevant to
> 
> you, write handler functions for them and tell the widget
> 
> to call some function when an event happens. The simplest
> 
> case is a button: you want to react to it, so you write a
> 
> function for what's to be done when it's clicked on and
> 
> then tell Qt to call that function once it gets clicked
> 
> (there are different events even for a simple push button,
> 
> it can be clicked, just pushed, released etc.). And if you
> 
> have set up everything for that you tell Qt to start waiting
> 
> for events.
> 
> 
> 
> So the steps are:
> 
> 
> 
>   1. Tell Qt that this is a program using it
> 
> 
> 
>      app = QtGui.QApplication( sys.argv )
> 
> 
> 
>   2. Create your graphical interface (what you seem to
> 
>      have done more or less)
> 
> 
> 
>   3. Connect desired events (what's called "signals" in
> 
>      Qt lingo) for a certain widget to the function to be
> 
>      called with something like
> 
> 
> 
>      your_widget.clicked.connect( your_function )
> 
> 
> 
>      (replace 'clicked' with e.g. 'pushed' or 'released'
> 
>      when interested in a push or release signal instead)
> 
> 
> 
>   4. Start the event loop (i.e. have Qt wait for the user
> 
>      to do something and call one of your functions if the
> 
>      user did something you're interested in) with
> 
> 
> 
>      app.exec_( )
> 
> 
> 
>      When this returns the game is over.
> 
> 
> 
> So you don't wait for keyboard input with input() like in
> 
> your original program but instead tell Qt to do the waiting
> 
> for you and call the appropriate function you defined when
> 
> something interesting happens.
> 
> 
> 
> What you probably will have to change about the graphical
> 
> interface is that instead of using QLabel widgets for 'Air',
> 
> 'Earth', 'Fire', 'Water' to use e.g. QPushButtons since
> 
> QLabels are rather static objects - they don't receive any
> 
> "click" events and it's rather likely some kind of event
> 
> like this is what you're going to want to react to. And for
> 
> that QPushButtons seem to be the simplest choice to start
> 
> with.
> 
> 
> 
> So have an 'Air' button (let's call it 'bAir' and then do
> 
> 
> 
>    bAir.clicked.connect( air_clicked )
> 
> 
> 
> after defining a function air_clicked() in which you deal
> 
> with that case. that might be as simple as
> 
> 
> 
> def air_clicked( ) :
> 
> 	# Randomly pick one of 'air', 'fire', 'water' or 'earth'
> 
> 
> 
>     z = [ 'air', 'fire', 'water', earth' ][ random.randrange( 4 ) ]
> 
> 
> 
> 	if z == 'air' :
> 
>         print( 'Stalemate' )
> 
>     elif z == 'water' :
> 
>         print( 'Air removes Water, you win!' )
> 
>     ...
> 
> 
> 
> Now, when during the game the 'Air' button is clicked this
> 
> function will get called.
> 
> 
> 
> Of course, it might be nicer to have a "result" label some-
> 
> where in the graphical interface which you set to the text
> 
> instead of printing it out to the console. And you also will
> 
> probably add some "Quit" button to end the game.
> 
> 
> 
>                               Regards, Jens
> 
> -- 
> 
>   \   Jens Thoms Toerring  ___      jt at toerring.de
> 
>    \__________________________      http://toerring.de

how would i go about adding print outcomes of all options  to a label ?