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