Model View Architecture

The Model View Architecture is designed to be an abstraction layer on top of Qt's model view delegate architecture. Its main purpose is to provide a simpler interface for viewing models, handling events, filtering models, etc. A basic example of the Model View Widget (MVW) can be seen below, where we can see it has two modes, tree, and list.

As we can see from the basic example, there is not much gain here, except for a simple flag to determine if we want to use a list or tree view. This starts to get more interesting when we start to look at some of the event handlings that have been implemented.

The MVW handles events by using a setter to provide a function to be run when an event has been triggered. The events that can have a handler provided for them are:

Drag Start • Drop • Enable / Disable • Select • Delete • Text Changed

However, the convenience functions of the events system continue by adding implementing a system that allows arbitrary delegate widgets to be added that can interact with the MVW. There are times that you want an input widget to drive the creation and/or filtering of items, or do some other arbitrary task on the model. Since the MVW is actually a Shoji Layout, this delegate system is implemented by adding widgets to the layout. These delegate widgets can be easily added with a simple function call and can either be shown on user key input or be persistent. Note here, that the term delegate is overloaded, and does not refer to the individual items delegates that are displayed during editing.

Below we can see an example of this delegate system in action where a persistent delegate adds a new item.

However, simply setting up these events is not enough, and the MVW provides functionality that allows it to easily enable/disable specific event types either for a specific item or the entire MVW.

Now that we have a better idea of the functionality of the MVW, we can start to talk about its underlying model. At its core, by default is a QAbstractItemModel which drives everything. However, this by itself does not support any form of filtering, which is why the MVW allows you to enable filtering with a simple call, which will set a custom QSortFilterProxyModel as the model, which has its source of the original model.

A custom QSortFilterProxyModel is added here, as it allows functionality to be provided to easily add multiple filters to the MVW by simply supplying a QRegExp, and an optional data type filter. If all conditions for filtering are met, then the items will be visible.

Below we can see an example of this in action in Katana, where we have a list of all of the nodes in the scene, and we can easily filter that list by either the node name and/or the node type.