Re: RFC: Model-View-Controller

[Kristian Rietveld <kris loopnest org>]

Hi,

I share the concerns Mitch has raised.  It is obvious that a redesign would help the organization of widget code and several people have thought about ways this can be done (e.g. Rapicorn and I also vaguely recall somebody trying to do pure MVC with GTK+).  Some more comments and thoughts below.


On Nov 9, 2011, at 7:12 PM, Benjamin Otte wrote:
> - widget complexity
> Our widgets - even the simple ones - are hellishly complex objects.
> Without reorganization of the code they'll get unwieldable. Here's the
> 5-digit source files in the gtk sources:
> 10464 gtkfilechooserdefault.c
> 10482 gtkentry.c
> (10947 gdkwindow.c)
> 13857 gtkwidget.c
> 16439 gtktreeview.c

Of the widgets you list I don't think GtkFileChooserDefault belongs there, because it is a composite widget where the others are not.

> We need a way to make that code readable again. Also, those files
> generally have lots of interactions and a high cyclomatic
> complexity[1], which makes it hard to understand what they do. This in
> turn leads to people being afraid of touching them. And that starts a
> vicious cycle.

About the interactions, does the MVC approach proposed really solve this and doesn't it lead to people being afraid to touch the class hierarchies and interactions between the different views and controllers?  In the simple examples in your other e-mail, there are already quite some connections between objects involved.

> I'm proposing a Model-View-Controller split for widgets.[2]
> 
> I want to split the source code for widgets into three parts. This is
> mostly an internal cleanup and should not affect applications that use
> widgets. It would however change the way widgets are coded. So this is
> mostly relevant for our own gtk/ directory, but would also be
> interesting for other widgets ike the evo calendar, EMap, the
> WebKitWebView, GtkSourceView, you name it.

So if I understand correctly, you want to re-do the implementation of widgets without changing the outside interface?  But you also want to expose the MVC objects to the outside to be used in third-party widget implementations.  I am wondering whether this won't get very confusing/messy.


The reasons why objects are currently so large are:

  1) View and Controller are combined in the same class, as has already been pointed out.
  2) Objects are often too specific to allow re-use; granularity is wrong.

If I would apply pure MVC to GtkTreeView, then we will still end up with a huge view and a huge controller class.  We already have the model class.  To achieve the desired simplification GtkTreeView will have to be split up into pieces, pieces which can be better re-used.  I see this transformation as a separate one from the transition to MVC.

So what you are actually proposing is both introducing MVC and splitting up the objects (albeit in an API compatible fashion).  I would argue that with just introducing the splitting and not doing MVC, we can already gain the majority of the code clean up.  I explicitly say majority, not all, because your approach, if feasible, would further increase code re-use. You might indeed want to split out "rubberbanding" into a separate class to not have to re-implement it in both an item container and somewhere else.  Whether we should then call this a rubberbanding "Controller" is something I am unsure about.

For GtkTreeView a start was made by pushing code into GtkCellArea, but much more is necessary.  In an earlier thread, I have once sketched plans to have a generic "item container" which would implement click handling, rubberbanding, drag and drop, keyboard handling, etc, etc.  Subclasses can then plug in specific layouting algorithms which make them a GtkTreeView or GtkIconView.

The other point to make here is that the above sketch for GtkTreeView is one possible way to do it.  The main problem with point 2) is picking the right granularity, there are multiple thoughts about this (e.g. the micro widget approach from Rapicorn) and making this decision can turn out to not be that easy.

> Sounds like a plan?

My feeling is that in order to come up with a solid plan, prototyping has to be done to figure out whether this is feasible and how things will look like.

regards,

-kris.