Re: RFC: Model-View-Controller

[Michael Natterer <mitch gimp org>]

Hi Benjamin,

I am sorry but this sounds like a lot of things, but not like
a plan.

- are our widgets a more-or-less huge mess? yes.
- do we need to do something about it? yes
- is MVC a well tested way to improve things? yes
- does it always work? NO

Sorry, but you are actually stating the obvious here, but fail
to provide *any* example, outline, not even a simple diagram.

Without any small example-ish thing to see what you mean
here, this is pretty much hot air :( But I surely don't
want to sound discouraging, please give a small example.

Regards,
--Mitch

On Wed, 2011-11-09 at 19:12 +0100, Benjamin Otte wrote:
> 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
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list