RFC: Model-View-Controller

[Benjamin Otte <otte gnome org>]

Hey,

so I've been thinking about this for a bit, and I think it's a good
idea, but I wanted to see if other people have an opinion about it.
And I wanted to get it into people's minds before we sit down for a
hackfest.

So this idea is a result of the mainly the following things:
- Clutter integration
Clutter has the concepts in some form or another. It doesn't use the
definitions I'm about to use, but it has the objects I want.
- 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
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.
- functionality duplication
A lot of widgets duplicate functionality. Treeview and iconview have
rubberbanding. Entries have progress bars and icons. Notebooks,
treeviews, expanders and whatnot have buttons. We do not only
duplicate the code here, but also behavior and policies. So if we
decide to change the states on buttons or the way rubberbanding does
autoscroll, we need to fix all of the widgets individually. And as we
are currently in a process of reinventing large parts of the toolkit -
both for UI design and for form factor reasons, we need to be able to
change these things quickly. And currently we can't even get rid of
underallocations.

So what am I actually talking about?

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.

The first thing I want to do is to create "View" objects. So instead
of having a huge draw() function, the widget would create a bunch of
View objects. We would provide a few common ones (probably one per
gtk_render_foo() function we currently have) and widgets would put
them where they belong in the size_allocate() function. After that,
they would take care of drawing themselves and all the stuff
associated with looking cool based on CSS and their surroundings. In
Clutter terms this is what ClutterActor is. Of course, they would
probably provide other information, too, like sizing or the actual
layout of text.
And once we have that, we can attach additional information to these
objects, like animation state, effects, caches and so on without the
widgets having to care.

The second thing I want to is create "Controller" objects. So instead
of having input events handled on the widget, we add a bunch of
controllers to the widget that take care of handling events and
emitting signals for when the user did interact with the widget. These
would go from very simple things like click, doubleclick or scroll
controllers to more complex things like rubberband or dnd controllers.
The Clutter equivalent here is ClutterAction. Of course, the actions
will probably require a bunch of properties and will also emit quite
some signals that widgets will use, but they can do things like
keeping track of the device they're interacting with and things like
that.
And once we have that, we can attach lots of new controllers, like
gesture controllers, or even switch controllers based on input method
used. And of course, we have less place where we can control things
like dnd threshold, double-click time, rubberband and dnd scrolling
speed and gesture definitions.

That leaves the widget itself as the "Model" (I think the correct term
would be "Application" in the MVC context here, but bear with me, this
makes it sound cooler). So the widget's job moves further away from
GDK (or Cairo, Clutter or whatever the backend is) and more into the
realm of being the manager between the application and the person in
front of the screen. It has an often simple "model" (for GtkEntry or
GtkLabel this is a string), some additional information about the
model (word-wrap, editability, etc) and manages how people in front of
the screen, developers and possibly IPC interact with it.

Sounds like a plan?

Benjamin


1: http://en.wikipedia.org/wiki/Cyclomatic_complexity
2: http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller