I'm trying to give a sound structure to a PyQt application that implements a card game. So far I have the following classes:

  • Ui_Game: this describes the ui of course and is responsible of reacting to the events emitted by my CardWidget instances

  • MainController: this is responsible for managing the whole application: setup and all the subsequent states of the application (like starting a new hand, displaying the notification of state changes on the ui or ending the game)

  • GameEngine: this is a set of classes that implement the whole game logic

Now, the way I concretely coded this in Python is the following:

class CardWidget(QtGui.QLabel):
    def __init__(self, filename, *args, **kwargs):
        QtGui.QLabel.__init__(self, *args, **kwargs)
        self.setPixmap(QtGui.QPixmap(':/res/res/' + filename))

    def mouseReleaseEvent(self, ev):
        self.emit(QtCore.SIGNAL('card_clicked'), self)

class Ui_Game(QtGui.QWidget):
    def __init__(self, window, *args, **kwargs):
        QtGui.QWidget.__init__(self, *args, **kwargs)
        self.controller = None

    def place_card(self, card):
        cards_on_table = self.played_cards.count() + 1
        print cards_on_table

        if cards_on_table <= 2:
            if cards_on_table == 2:

class MainController(object):
    def __init__(self):
        self.app = QtGui.QApplication(sys.argv)
        self.window = QtGui.QMainWindow()
        self.ui = Ui_Game(self.window)
        self.ui.controller = self

Is there a better way other than injecting the controller into the Ui_Game class in the Ui_Game.controller? Or am I totally off-road?

1 Answer 1


I would say you should do the contrary, a good design would be for your application to be able to run whatever its context is. That's why for every application I code, I create a CLI tool that implements the logic, and then I implement a GUI. Where am I heading to ?

You're creating a MainController object that holds the world, and then modifies the Ui_Game object to give back a reference to itself. That's not elegant, and given your context that's not the best way.

If you really want to go this way you should instead do the following:

class Ui_Game(QtGui.QWidget):
    def __init__(self, controller, *args, **kwargs):
        QtGui.QWidget.__init__(self, *args, **kwargs)
        self.controller = controller



That's for the elegancy.

But for your context, I'd advise you to totally separate the game logic from the UI logic, and thus have some start or main function that initializes all your objects, and bind them together. Also, you create a widget that seems to populate itself inside the window, whereas the widget shall not know where it will be used. So here something close to what I'd do:

class GameGUI:
    def __init__(self, game):
        # so you can give all your UI elements a game to play with
        self.game = game 
        # start and populate the Ui_Game stuff
        self.app = QtGui.QApplication(sys.argv)

    def main_loop(self):
        # wait for the UI to cease
        return self.app._exec()

def start():
    # here you can argparse your CLI arguments, so you can choose
    # your interface (readline, ncurses, Qt, web, whatever...?)
    # and setup your application (logfile, port to bind to, look 
    # of the GUI...)
    game = MyGame()
    return GameGUI(game).main_loop()

import sys
if __name__ == "__main__":

So, now the flow is more limpid:

  • you start in the start() function, which will prepare the environment for your application to run correctly
    • check arguments if any,
    • initializes the Game,
    • give it to the GUI,
    • build the GUI (through GameGUI that will create the windows and the widgets)
    • run the GUI (through main_loop())

Always remember that OOP is all about decoupling.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.