[gtk-list] Re: Repeat: Clicking on widgets - consistency question

[andrew cogent ca]

Havoc Pennington writes:
 > On Wed, 2 Jun 1999 andrew@cogent.ca wrote:
 > > 
 > > Type 1:  On a type 1 widget, the widget gets the button press, and my
 > > callback runs normally.  No other widget gets the press event.  Example:
 > > GtkButton with a GtkFixed parent.
 > 
 > GtkButton "handles" the event by returning TRUE from its handler so the
 > event isn't propagated to the parent.
 >  
 > > Type 2:  The widget gets the button press event, but so does the
 > > widget's parent.  This is not affected by stacking, as I can stack two
 > > type 2 widgets as siblings, and only the clicked widget and its parent
 > > get the event.  Example: GtkEntry with a GtkFixed parent.
 > 
 > GtkEntry returns FALSE, indicating that its parent should also get the
 > event.
 > 
 > > Type 3:  No widget gets the button press.  It is ignored by all widgets,
 > > even if the widget's parent is the same parent that got the event in the
 > > Type 2 case.  Example: GtkCheckButton with a GtkFixed parent.
 > 
 > GtkCheckButton should emit button press, I can't think of what's going on.
 > Otherwise the same as GtkButton above.
 > 
 > > I believe that all widgets should be Type 1 widgets.  Is there a
 > > compelling reason why they are not?
 > 
 > Often you don't want the same button press to do multiple things, for
 > efficiency and UI reasons.

Two problems here:

1) Signals and events are orthogonal.  Signals happen to be created by
   events, but this is implementational.  The events should happen
   before the signals, logically, and are associated with any
   GtkObject that has an event-trapping interface (in X-Windows, a
   Window).  The behaviour of a GtkWidget in the creation of signals
   should be irrelevant to its event behaviour.  Therefore:
     > GtkButton "handles" the event by returning TRUE from its
     > handler so the event isn't propagated to the parent.
   breaks the model, and even it if it was defined to *be* the model,
     > GtkEntry returns FALSE, indicating that its parent should also
     > get the event.
   is inconsistent.  Worse,
     > GtkCheckButton should emit button press, I can't think of
     > what's going on.
   suggests that widget writers have no clear idea what they ought to
   be doing with the events they receive.

2) GTK+ is a pseudo-OO system, and IMHO that implies that it should
   exhibit consistent behaviour across all GtkObjects or subsets
   thereof.  The absence in consistent treatment of events, which
   widgets should *never* handle (meaning halt delivery), makes it
   essentially impossible to take advantage of the otherwise carefully
   considered OO implementation in any but the most trivial ways.  As
   a simple example: I want to write a program where the widgets
   behave normally to press/release etc.  Now I want to make ALL
   widgets respond to ALT-press by popping up a type-dependent
   configuration dialog.  This is quite simply impossible without
   consistent, defined, enforced event behaviour.

I want to write commercial quality code with GTK+, and I have
employees whose job it is to do that.  It is not just academic
curiosity that drives my questions.

I propose that before this situation degenerates further that the GTK+
core team come up with a statement of intent with regard to event
handling, and then ask widget creators to stick to it.  The goal
should be to create a 100% consistent framework for widget creation
that allows the easy extension of the widget set without breaking some
of the fundamental assumptions on which extensible programs are based.
I am perfectly willing to put corporate staff on fixing the currently
broken widgets, but I cannot do it without a policy statement from the
GTK+ maintainers.

I would also be more than happy to assist in the development of the
policy statement.

Any takers?

Andrew