views:

520

answers:

3

hi there,

please, help me with designing MVC-pattern with PyQt. i want to split all program at 3 parts: 1. some class that is abstracted from all Qt classes(model) 2. some class that provides data from model to qt-app(controller) 3. Qt-app itself with defined method SignalsToSlots that connect signals with controller.

is it optimally and what scheme do use in PyQt development?

ps: sorry for my english =)

A: 

Sounds like a good starting point. You will of course encounter numerous problems when you start with it (but that's true for any approach), so give it a try and don't hesitate to ask for any further issues you will run into.

Aaron Digulla
thank you for the advice.
aluuu
What sounds like a good starting point?
sims
+5  A: 

One of the first things you should do is use Qt4 designer to design your gui and use pyuic4 to generate your python GUI. This will be your view, you NEVER edit these python files by hand. Always make changes using designer, this ensures your View is separate from your model and control.

For the control element, create a central class that inherits from your base gui widget such as QMainWindow. This object will then contain a member ui that is your view object you just generated.

here is an example from a tutorial

import sys
from PyQt4 import QtCore, QtGui
from edytor import Ui_notepad

class StartQT4(QtGui.QMainWindow):
    def __init__(self, parent=None):
        QtGui.QWidget.__init__(self, parent)
        self.ui = Ui_notepad()
        self.ui.setupUi(self)


if __name__ == "__main__":
    app = QtGui.QApplication(sys.argv)
    myapp = StartQT4()
    myapp.show()
    sys.exit(app.exec_())

The key point in the above example is the controller contains the ui and doesn't inherit it directly. The controller will be responsible for managing signal slots connections for your gui and providing an interface to you data model.

To describe the model part we need an example, lets assume your project is to create a movie collection database. The model would include the internal objects that represent individual movies, along with objects that represent lists of movies. You control would take the data entered from the view and catch the signals, then validate them before asking the model to update itself. That part is crucial, the controller shouldn't directly access the model if at all possible, it should ask the model to access itself.

Here is a small example of this interaction(untested, may be some typos):

class Movie():
    def __init__(self,title=None,year=None,genre=None):
        self.title=title
        self.year=year
        self.genre=genre
    def update(self,title=None,year=None,genre=None):
        self.title=title
        self.year=year
        self.genre=genre
    def to_xml(self,title=None,date=None,genre=None):
        pass #not implementing this for an example!

#when the controller tries to update it should use update function
movie1.update("Manos Hands Of Fate",1966,"Awesome")
#don't set by direct access, your controller shouldn't get that deep
movie1.title="Bad Idea" #do not want!

It is also important in MVC to centralize access, say the user can change the title by double clicking it on the screen, or by click edit next to the title field, both of those interfaces should end up using the same method for the change. And by this I don't mean each one calls movie.update_title(title). I mean that both signals should use the same method in the controller.

Try as much as possible to make all relationships between the View and the controller many to 1. Meaning, that is you have 5 ways to change something in the gui, have 1 method in the controller to handle this. If the slots aren't all compatible than create methods for each of the methods that then call one single method. If you solve the problem 5 times for 5 view styles then there really isn't and reason to separate the view from the control. Also since you now have only one way to do something in the controller you ahve a nice 1 to 1 relationship between control and model.

As far as having your model completely separate from Qt, that isn't really necessary and may actually make life harder for you. Using things like QStrings in you model can be convenient, and if in another application you don't want the overhead of a Gui but want the models just import QtCore only. Hopefully this helps!

kramthegram
+1, `don't set by direct access, your controller shouldn't get that deep`: why not mention the possibility of `self._title=title; self._year=year; ...`?
mlvljr
+2  A: 

Yes, PyQt uses Model/View concept (officially without the "Controller" part), but may be you have a somewhat distorted picture what does it mean in PyQt.

There are two parts:

  1. Models, subclassed from appropriate PyQt base abstract model classes (QAbstractItemModel, QAbstractTableModel, QAbstractListModel, etc.). These models can talk to your data sources directly (files, databases), or proxy your own PyQt-agnostic models which were written before.
  2. Views, which are implemented in Qt library, and often do not require any modifications (examples: QTreeView, QTableView and others). Even some simpler controls, like QComboBox can act as a view for a PyQt model.

All other parts of you application, which react to signals, etc. may be considered as "Controller".

PyQt also provides a set of predefined "universal" models which can be subclassed or used directly if you need only simple functionality from the model, like QStringListModel, QStandardItemModel, etc. And there are also models which can talk to databases directly, like QSqlTableModel.

abbot