Organization of GUIs

[Michael Mossey]

I have a question about typical organization of GUIs. I will be using
PyQt.

I have mostly used Python and C++ in my professional life, but I just
took an 8 month detour into using a functional programming language
called Haskell. Haskell is "pure" meaning that for the most part data
is not mutable, or if it is mutable, access to it is controlled very
carefully. This got me thinking about how mutable data can make
program behavior complicated and difficult to understood/prove-
correct. I am returning to Python and PyQt for my next project, but I
come away inspired to do things a little differently.

For example, in GUIs I've written in the past, typically there are a
lot of GUI objects (windows, data repositories, etc.) that "talk" to
each other. One object might send messages about a change in its state
to other objects that are watching it.

I am now wondering if I should write a GUI so that everything is in a
true hierarchy, rather than a tangle of objects with democratic
relationships---and more specifically, that messages (which may cause
state to be changed in the receiver of the message) should first go up
the hierarchy until they reach the right level, and then down to the
ultimate receiver of the message. This way a parent object in the
hierarchy has complete visibility and control of messages passing
between its children, leading to the possibility of consolidating the
code and documentation about the children's mutability in one place
(the parent).

But honestly, I have never really studied how good existing GUI
programs are organized. Always flew by the seat of my pants. So I'm
interested in someone has thoughts about this, maybe can point me to a
good book, etc.
Thanks,
Mike

 

[Lie Ryan]

I have a question about typical organization of GUIs. I will be using
PyQt.

Model-View-Controller (MVC) pattern.

Model - all the business logic lives in the model.
View - your GUI
Controller - Takes input

Controller notifies Model if there is user input; Model notifies View if
there is an update in the model; View "notifies" user if there is an
update in the model; User "notifies" controller of the changes wanted.

http://en.wikipedia.org/wiki/Model–view–controller

 

[Michael Mossey]

Model-View-Controller (MVC) pattern.

Model - all the business logic lives in the model.
View - your GUI
Controller - Takes input

Controller notifies Model if there is user input; Model notifies View if
there is an update in the model; View "notifies" user if there is an
update in the model; User "notifies" controller of the changes wanted.

http://en.wikipedia.org/wiki/Model–view–controller

I'm aware of Model-View-Controller, but my question is broader than
that for a couple reasons:

View can be fine-grained. Often the View consists of a number of GUI
objects. Some people write this in a democratic arrangement---they all
talk to each other. This can make analyzing system behavior
complicated. Hence my proposal for a hierarchy.

Also, often different parts of the Model talk to different parts of
the View. The question, then, is whether both the Model and View
should be structured hierarchically so that all messages pass through
a "master" or "root" object before going to the other Model/View, and
messages within a Model or View should only move along the hierarchy.

In other words, you can easily make a complete mess of MVC.

 

[Dietmar Schwertberger]

View can be fine-grained. Often the View consists of a number of GUI
objects. Some people write this in a democratic arrangement---they all
talk to each other. This can make analyzing system behavior
complicated. Hence my proposal for a hierarchy.

Yes, the democratic arrangement is only for very simple applications.

Also, often different parts of the Model talk to different parts of
the View. The question, then, is whether both the Model and View
should be structured hierarchically so that all messages pass through
a "master" or "root" object before going to the other Model/View, and
messages within a Model or View should only move along the hierarchy.

In other words, you can easily make a complete mess of MVC.

I made good experiences with this setup in a very complex application
(inspired by MVC/MVP, but slightly different):
- Model is completely independent of any GUI; in fact it's written
to be used not only with a GUI, but also by scripts and an
application server
- Controller/Presenter holds the model instance and serves as
message dispatcher; also it holds view-only data (e.g. cursor
position, cell selections, file modified?)
- Views/Controls
- subscribe to the messages to update themselves
- either modify data and send update message via the dispatcher
- or tell Controller to modify the data, which then generates
the update message

With this architecture, you have the choice whether to plug the
Views/Controls directly to the Controller/Presenter or organize
them hierarchically. I doubt that you'll have many hierarchy levels
between Presenter and Controls. Probably only one...

Examples for the messages:
- "Changed", model
(anything may have changed)
- "AttributeChanged", attname, value
- "DataChanged", index, new_value
- "Saved", filename
- "Modified", modified
- "IndexChanged", new_index
- "ViewChanged", view_names
(I'm using a tabbed interface and some views react to messages
only when they're active.)
- "ConfigRead", key, value, persistent
Some messages are automatically issued by the Presenter in response
to other messages. E.g. for a "Saved" message, the Presenter
automatically generates a ("Modified",False) message afterwards.

In my case, the model is hierarchical and so I have "Changed" messages
for many different aspects / levels. The total number of message types
is around 60. I could live with much less, but the finer the messages,
the less performance overhead.

As there are messages related to the model (e.g. Changed) as well as
messages related to the views (e.g. IndexChanged) and to general
functionality (e.g. ConfigRead) it's very easy to couple all
controls and components via the Presenter.

The app is built with wxPython and includes a shell window which exposes
some objects including the app itself and the model.
In this shell you may manipulate the model interactively or by loading
a Python script. For the GUI to catch up you need to issue a "Changed"
message afterwards.
It would be possible to follow e.g. the original MVP and do all
modifications (GUI and shell) via the Presenter to avoid the requirement
of issuing this message, but that would require wrapping of much
functionality and usage would be less elegant.

As the app, including all menu items, is available from the shell, this
can also be used for automatic testing.
E.g. shell input or script may look like that:
Also, it's possible to automatically test dialogs...


Regards,

Dietmar

 

[Michael Torrie]

Model-View-Controller (MVC) pattern.

Model - all the business logic lives in the model.
View - your GUI
Controller - Takes input

No, you've got it wrong:

Model - Your data or database, some rules to enforce integrity
Controller - your business logic
View - Your gui, takes input

 

[Benjamin Kaplan]

I'm aware of Model-View-Controller, but my question is broader than
that for a couple reasons:

View can be fine-grained. Often the View consists of a number of GUI
objects. Some people write this in a democratic arrangement---they all
talk to each other. This can make analyzing system behavior
complicated. Hence my proposal for a hierarchy.

Ideally, the controller should be the top of that hierarchy.

Also, often different parts of the Model talk to different parts of
the View. The question, then, is whether both the Model and View
should be structured hierarchically so that all messages pass through
a "master" or "root" object before going to the other Model/View, and
messages within a Model or View should only move along the hierarchy.

The model should never ever talk directly to the view. The whole point
in using MVC is that the model parses the data, but doesn't care what
you do with it. The controller takes the data from the model and
processes it but doesn't care how the data is obtained, stored, or
displayed. The controller then sends data to the view, which doesn't
care how you got it or what you did with it. All it knows is that it's
given data and it knows how to display it. Then, when the user
interacts with the view, it sends the new data back to the controller
which either passes it along to the model or tells the view (or
another part of the view) to do something else.

 

[Lie Ryan]

No, you've got it wrong:

Model - Your data or database, some rules to enforce integrity
Controller - your business logic
View - Your gui, takes input

perhaps you meant MVP:
"""
* The model is an interface defining the data to be displayed or
otherwise acted upon in the user interface.

* The view is an interface that displays data (the model) and routes
user commands (events) to the presenter to act upon that data.

* The presenter acts upon the model and the view. It retrieves data from
repositories (the model), persists it, and formats it for display in the
view.
"""



MVC:

"""
Model
Is the domain-specific representation of the data upon which the
application operates. Domain logic adds meaning to raw data (for
example, calculating whether today is the user's birthday, or the
totals, taxes, and shipping charges for shopping cart items). When a
model changes its state, it notifies its associated views so they can
refresh.
Many applications use a persistent storage mechanism (such as a
database) to store data. MVC does not specifically mention the data
access layer because it is understood to be underneath or encapsulated
by the model. Models are not data access objects; however, in very
simple apps that have little domain logic there is no real distinction
to be made. Also, the ActiveRecord is an accepted design pattern which
merges domain logic and data access code - a model which knows how to
persist itself.

View
Renders the model into a form suitable for interaction, typically a
user interface element. Multiple views can exist for a single model for
different purposes.

Controller
Receives input and initiates a response by making calls on model
objects.
"""


[*] all source taken from wikipedia.

 

[denis]

complete VISIBILITY and control of messages ...

is most important: being able to SEE messages (filtered on from,
to, ...)
in a running system really helps to understand it.
Hierarchy does help structure messages coarse/fine,
but visibility is orthogonal to structure
(you can have visible democracy, blind hierarchy, in real life too.)

Visibility has to be built in from the beginning --
wrap all connect() s in a visconnect() that can trace.

Dietmar's shell sounds Right; anyone know of such in PyQt ?

cheers
-- denis

 

[zeph]

I highly recommend reading the Cocoa documentation, which has volumes
on all sorts of things like this. Here's a link that talks about
views in that context, and should give you more ideas about well-
designed GUI layouts: http://bit.ly/6b8PYh

 

[Michael]

I highly recommend reading the Cocoa documentation, which has volumes
on all sorts of things like this.  Here's a link that talks about
views in that context, and should give you more ideas about well-
designed GUI layouts:http://bit.ly/6b8PYh

Cool link. Thanks!
-Mike