Organization of GUIs

Discussion in 'Python' started by Michael Mossey, Dec 3, 2009.

  1. 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
     
    Michael Mossey, Dec 3, 2009
    #1
    1. Advertising

  2. Michael Mossey

    Lie Ryan Guest

    On 12/4/2009 12:44 AM, Michael Mossey wrote:
    > 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
     
    Lie Ryan, Dec 3, 2009
    #2
    1. Advertising

  3. On Dec 3, 6:38 am, Lie Ryan <> wrote:
    > On 12/4/2009 12:44 AM, Michael Mossey wrote:
    >
    > > 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


    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.
     
    Michael Mossey, Dec 3, 2009
    #3
  4. Michael Mossey schrieb:
    > 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:
    >>> filename = "c:\\test.dat"
    >>> self.menu.file.open( filename=filename )
    >>> # or self.menu.file.open() to let the user select a file
    >>> # or model = ModelModule.open( filename )
    >>> if model.filename!=filename: raise ValueError, "test failed"
    >>> new_filename = "c:\\output.dat"
    >>> model.filename = new_filename
    >>> presenter.notify("AttributeChanged", "filename", new_filename)
    >>> # or presenter.set_filename( new_filename )
    >>> # or presenter() as shortcut for presenter.notify("Changed", model)
    >>> # or presenter.save( new_filename )


    Also, it's possible to automatically test dialogs...


    Regards,

    Dietmar
     
    Dietmar Schwertberger, Dec 3, 2009
    #4
  5. Lie Ryan wrote:
    > On 12/4/2009 12:44 AM, Michael Mossey wrote:
    >> 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


    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
     
    Michael Torrie, Dec 3, 2009
    #5
  6. On Thu, Dec 3, 2009 at 9:59 AM, Michael Mossey <> wrote:
    > On Dec 3, 6:38 am, Lie Ryan <> wrote:
    >> On 12/4/2009 12:44 AM, Michael Mossey wrote:
    >>
    >> > 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

    >
    > 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.

    > In other words, you can easily make a complete mess of MVC.
    > --
    > http://mail.python.org/mailman/listinfo/python-list
    >
     
    Benjamin Kaplan, Dec 4, 2009
    #6
  7. Michael Mossey

    Lie Ryan Guest

    On 12/4/2009 10:40 AM, Michael Torrie wrote:
    > Lie Ryan wrote:
    >> On 12/4/2009 12:44 AM, Michael Mossey wrote:
    >>> 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

    >
    > 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.
     
    Lie Ryan, Dec 4, 2009
    #7
  8. Michael Mossey

    denis Guest

    On Dec 3, 2:44 pm, Michael Mossey <> wrote:
    > 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
     
    denis, Dec 4, 2009
    #8
  9. Michael Mossey

    zeph Guest

    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
     
    zeph, Dec 6, 2009
    #9
  10. Michael Mossey

    Michael Guest

    On Dec 5, 11:50 pm, zeph <> wrote:
    > 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
     
    Michael, Dec 6, 2009
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ramon F Herrera

    Can Java do fancy GUIs?

    Ramon F Herrera, Apr 16, 2005, in forum: Java
    Replies:
    56
    Views:
    1,676
    Thomas G. Marshall
    Apr 23, 2005
  2. Replies:
    2
    Views:
    351
  3. Berlin  Brown

    Testing Swing GUIs

    Berlin Brown, Jul 19, 2005, in forum: Java
    Replies:
    4
    Views:
    546
    Thomas Hawtin
    Jul 19, 2005
  4. Stewart
    Replies:
    1
    Views:
    577
    John Harrison
    Sep 16, 2004
  5. V e X y N

    GUIs and Compilers.. <help>

    V e X y N, Aug 22, 2003, in forum: C Programming
    Replies:
    2
    Views:
    393
    Greg P.
    Aug 22, 2003
Loading...

Share This Page