[PyQT] Model View Video Tutorial Series (Part 01)



I’m working on part 4 as we speak! I’ve been busy again, can hardly find time to work on private projects nowdays =/

Anyhow I hope to have it up within the next 2 days, promise :slight_smile:


Just wanna say thanks for these, finally got round to watching the first two, presented very well, nice and clear information and not dull at all, which it could have quite easily been.

Goob job.

Any update on the following videos in the series?


Hey, I’ve been away for quite some time.

Anyway I’m back and continuing the series. I just finished Part 04 about Tree Views and Tree Models. You can find the tutorials either in my blog or on the first post of this thread!

I’ve also uploaded all the source code for each part and placed them right below the video tutorials :slight_smile:

Working on part 5 now!

Best regards Yaz!


Hello hello :slight_smile:

To compensate for the time I’ve been gone, I decided to finish Part 05 asap, and took me a day to do that :slight_smile:

So PART 05 IS UP! Can find it on the first page or in my blog :slight_smile:

Working on Part 06 now :slight_smile:

Best regards and hope you like it!


[QUOTE=LoneWolf;10314]Hello hello :slight_smile:

To compensate for the time I’ve been gone, I decided to finish Part 05 asap, and took me a day to do that :slight_smile:

So PART 05 IS UP! Can find it on the first page or in my blog :slight_smile:

Working on Part 06 now :slight_smile:

Best regards and hope you like it![/QUOTE]

Dude! Excellent stuff. My guys are eating it up and have fallen in love with MVVM.

Just one crit:

You need to throw up a donation page to get some money for a better microphone setup =)


Hahaha thanks :D, I can’t find words to express myself with :D, maybe the microphone will help me finding them =} I’ll take your crit and put it up tomorow ^^

I will also try expanding to the QT / PyQT community when I have part 06 up by posting on the QT forums and the PyQT mailinglist, hopefully will bump the watched count which I believe is quite low atm :confused:

Glad your boys like them =} Part 06 will be up tomorow ^^


I’ll definitely be watching the rest of these next week, sadly got an exam this week so gotta deal with that first.

I spent the last two weeks working with model view stuff in pyqt so will be good to see if I approached things correctly.



a 50+ minutes long tutorial is incomming :slight_smile: Rendering it out as we speak, this is gonna take some time :smiley:

Best regards!


06 is up and found in my blog or at the first page! :slight_smile:



Okay I decided what the next part will be about.

Split the project into different files such as Data.py, Models.py, Controllers.py, Views/(insert ui files) etc.
Then, refactor our code abit so that our model is alot cleaner.
Once this is done, skim through selection models.
Serialize our tree model into an Xml.
Read back the Xml and construct the tree model

I think that this will be better than going to QItemDelegate and QStyledItemDelegate classes :slight_smile: Those will be covered in part 08!

Also I’m pacing back to my original speed (1 video per week) :slight_smile:

Best regards!


Part 07 is done recording. Just need to comp it, will do it tomorow night after intern / work.

Topics covered:

Proper project setup (Controllers.py, Models.py, Data.py AND Views/[files].ui)
Refactoring the code so it’s alot simplier, cleaner, extendible, dynamic in terms of properties setting and getting.
Dynamic solution for data, setData methods of our model
Dynamic solution for properties / attributes
Dynamic XML generation using QtXml module and some python tricks to get a list of all properties from self and entire heirarchy of super classes
Realtime update of XML viewer by property editing
Using my XML Highlighter for PyQt4 found on my Blog
Enum attributes with comboboxes

All of this in Model View programming pattern :slight_smile:

PS: I was in hurry with the last tutorial, so that’s why I moved the refactoring into this tutorial :slight_smile:

image of result:


Part 07 is up and on the first page :slight_smile: Enjoy!


I’ve been following these since you started. Great information man and thanks for putting it out there. I made a playlist of the entire series thus far cause I saw you didn’t have one. http://www.youtube.com/view_play_list?p=8B63F2091D787896


Haha awesome man thanks, great that you like it :slight_smile: I’ll put the playlist up in the first post =}
Last part has been uploaded btw :slight_smile:


Rock on! I saw it and I added it. Got the email about the reply here and the upload at the same time. :wink: Threw it out on Twitter too.


These are great videos! Awesome job!


Great stuff as always.

One thing I do not agree on however are the data, setData methods in the node.

They are now tightly coupled to a specific column index. It breaks the fundamental paradigm of separating the view from the data.

IMHO, that is the role of the viewModel to map those to the columns.

Otherwise! very good information on something that is still voodoo for PyQT.


Hey! Thanks for your kind words ^^

Not sure if I agree about that. Nothing has changed at the concept level when I moved them into the node class itself. The models job is to act like an interface for the view so it can reach the data, and that’s what it is doing right now :slight_smile: Nothing is tightly coupled to the view, it’s all separate!

Usually, Tree Nodes have a LIST of data REPRESETING the columns like so: 0, 1, 2…n right?
Instead of a list, I went with properties. So the data method in the NODE class you talk about is acting like a list, really, since it recieves the same column number the LIST would have recieved :slight_smile:
What’s the difference when the model asks for an item like this: node.data[column] and with our method node.data(column) :)… Qt itself uses the first variant where data is hold in lists. I used a method instead, so I could provide properties, which are then used during Xml generation :slight_smile:

So the Model View rules in Qt are not broken =} It’s just using a method to return the data, instead of a list holding the data (again, because I wanted to go with properties)


Nothing is really coupled there to the view as far as I can tell, it’s all separate. Besides, our view isn’t displaying column 1 and above because we use them for Xml purposes :o They are only used in the data widget mapper[/QUOTE]

I suppose I should have said indirectly coupled.

Technically, instead of asking the “node” for data like … node.name, or node.type, it is now typing the view to a column in the node.

Here is where I see a potential issue:

If I make a ModelView and use column 1 in the node for the name and column 2 in the node for the type, everything works great.

Then someone else comes along and makes a ModelView and wants to use the name in column 2 and the type in column 1.

Since the Node’s internal “data” function is tightly bound to column 1 = name and column 2 = type… broken.

Rather, the ModelView itself should just ask “data?” and in its representation for column 1 appropriately use whatever you want displayed.

Binding it at the Node level means all instances, ever, have to use the name for column index 1 and the type for column index 2.

Personally I like to keep the level of data and presentation layer as completely separated. Only the View should want to present the data in the columns, not the node itself.

Could just be a preferential thing.



Binding it at the Node level means all instances, ever, have to use the name for column index 1 and the type for column index 2.

Could just be a preferential thing.[/QUOTE]

Normally, you keep the data in a chosen order and stick with it. Think of an application where you have customers subscribed to your “tv-channel” and the data is contained in a class called “Customer” which has data such as Name, Adress and Telephone number.

How often would you reorder this data so one MODEL uses:
Adress, Telephone Number and Name while other uses this way:
Name, Telephone Number and Adress.

Not very often. That’s also the reason I did it the way I did it =}

But as you say, you are right that it’s the models job to do that. Writing a different Model would mean being forced to follow the order I defined in the Node class, which again, since i knew that I wouldn’t make 2 models or more, I sticked with this method! It was a preference thing I did and keeping in mind that a scenegraph is a very specialized view and it’s purposes well defined, I simplified the entire thing for myself doing it the way I did it =}.

I guess I’ll need to think about this since the audience of the tutorial can and will write models representing the same data across different views in different orders where one might not map to the other =}

So I Understand your point completely when you lay it out like that, but again, the intention of the model and it’s purposes made me go the other route :slight_smile:

Imo satisfying every possible situation will only make the code more complex and more time consuming! The tradeoff I made for not being able to have stuff in arbitrary order, is a very GOOD trade off imo for this situation.

Thanks for your insight however! ^^