Re: RFC: Model-View-Controller

[Benjamin Otte <otte gnome org>]

On Fri, Nov 11, 2011 at 2:47 PM, Michael Natterer <mitch gimp org> wrote:
> Hi Benjamin,
>
> [snip typical German ecouragement talk]
>
> please give a small example.
>
(disclaimer: just to illustrate the idea, might change a lot)

So, a GtkButton is kinda complex from the input perspective, but
simple for drawing. It would have these "Views":
- Background
- Child
It would inherit those from GtkBin, so it wouldn't have any drawing code at all.
And it'd have those "Controllers":
(- Hover)
- Click
- Activate
(- Focus)
- KeyPress/Release
Not sure if hover and focus should be default or separate controllers.
What they'd do is toggle the :focus and :hover state on the widget and
nothing else. The click controller would capture mouse presses, take a
grab, and on release it'd make the button emit "clicked". Same as the
KeyPress/Release controller (which would only capture space, return
and whatever else activates a button). And the Activate controller
would respond to gtk_widget_activate().

A GtkLabel would have these "Views":
- Background (or not - it'd have it in GTK4, maybe not in GTK3, where
labels have no background)
- Text
and it'd have probably these "Controllers":
- "Rubberband"
- Click
- DoubleClick
- Drag
- KeyPress/Release
I wanted to call "Rubberband" "Drag", but that'd confuse people with
DND. What I mean is pressing the mouse, holding it and releasing it
elsewhere. Consider the name a work in process.
All of them would only be active if the label was selectable.
Rubberband would be used to do a selection, drag would allow DND'ing
the selected text. The KeyPress/Release controller(s) would be used
for the general selection handling in text, as would the Click and
DoubleClick ones. (I suppose we would have one that'd be shared
between all the text-handling widgets that ensured all our keybindings
were identical and the selection behavior consistent - try
double-clicking between words in different widgets for some fun.)

Now for some fun widget, the notebook. We'd have these views:
- Background
- Child (for the active widget)
- per action and arrow button:
  - Background
  - Icon
per tab:
  - Background
  - Child

And these actions:
- Drop (for tabs maybe?)
- per action and arrow button:
  - Click
  - Focus
  - Hover
  - KeyPress/Release
- per tab:
  - Click
  - Focus
  - Hover
  - KeyPress/Release
  - Drag (to drag tabs elsewhere)
  - Drop (for tabs)
  - Activate (for keybindings)
  - per close button on the tab:
    - Click
    - Focus
    - Hover
    - KeyPress/Release
You would probably be able to limit actions to certain areas/views of
the widget, so the hover/focus actions would be setup to only apply to
the ones they are about. It'd at least solve all our bugs with focus,
hover and whatnot not working properly on notebooks that get filed and
fixed regularly. Or we would make the notebook have real buttons, at
which point the actions would be setup by the button. Then we'd just
have to solve attaching the DND actions to the button.
But with such an approach, the notebook code would look less scary
(apart from the setup code...). We'd just move some views around in
size_allocate and connect some signals and that'd be that.

I'm not even going to try to imagine the setup for the treeview here...

That said, you can see that the number of different views and
controllers is quite small. It's just that we duplicate their
functionality over and over and over again. And you can maybe start to
imagine what would happen when people started adding gestures etc to
the notebook code...

Benjamin