Re: GTK architecture

[Havoc Pennington <hp redhat com>]

On Fri, Feb 14, 2003 at 10:56:35PM +0100, Ernst De Ridder wrote: 
> Example: gtkspinbutton.c, function gtk_spin_button_button_press
> It checks the position of the mouse, to determine which arrow the mouse is
> on. And then:
> 
>      if (event->button == 1)
>        start_spinning (spin, GTK_ARROW_UP, spin->adjustment->step_increment);
>      else if (event->button == 2)
>        start_spinning (spin, GTK_ARROW_UP, spin->adjustment->page_increment);
> 
> I have no problems with this function checking the position of the mouse. 
> After all, only the drawing function knows precisely where everything is 
> drawn. But I would not like it to decide how to react to this event, because 
> hardwiring the control into the view makes it too difficult to change the 
> control (e.g. for accessibility reasons, or to experiment with new user 
> interfaces). I would like the view to pass the event to a controller, 
> together with information on where the event occured, e.g. 'this event on
> arrow-up'. The controller checks the event (say left-click) and signals the
> model (GtkAdjustment) 'step-decrement', the model handles this and updates the
> view.
> 
> What do you think?

Generally speaking, I think some of the complex event handling such as
GtkMenu and GtkTextView are already extremely hard to get right - 
genericizing them would make it almost impossible to get them right,
and also means that changing event handling behavior breaks API/ABI.

Letting each app experiment with variations on standard widgets isn't
generally a GTK goal. GTK provides standard, consistent, predictable
widgets, not a widget construction kit. This maximizes flexibility for
changing UI and making accessibility work *within* GTK, thus fixing
all apps at once.

Havoc