Re: GTK architecture
- From: Havoc Pennington <hp redhat com>
- To: Ernst De Ridder <hnridder informatik uni-rostock de>, gtk-devel-list gnome org
- Subject: Re: GTK architecture
- Date: Fri, 14 Feb 2003 17:29:59 -0500
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
> 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.
] [Thread Prev