Re: [gtk-list] Re: Repeat: Clicking on widgets - consistencyquestion

[Havoc Pennington <rhp zirx pair com>]

On Wed, 2 Jun 1999 andrew@cogent.ca wrote:
> 
> 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:


I think you don't fully understand how it works. Events are only
delievered to the Gtk layer in signal form; widgets never deal with an
event except in signal handlers. Widgets have no "event behavior" separate
from signals.

Only GtkWidget and subclasses have an "event-trapping" interface; no
X window is a GtkObject.

>      > 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,

It isn't inconsistent; the rule is that an event from the Gdk layer causes
a signal emission on the widget owning the event window; if that emission
returns FALSE then a signal is emitted on the widget's parent; if that
returns FALSE then things continue, etc.

>      > 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.
> 

It simply means that I'm not familiar with how that particular widget
behaves. I'm sure the designers of said widget can tell you exactly what's
going on. 

I would think that the button press event would be emitted on the check
button, but apparently your test program doesn't do that. It could be a
bug in your program, or in Gtk, or some subtlety I don't understand.
You're concluding a bit much from this.

> 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

You never actually explain why this is the only sensible behavior... 

Also, widgets only prevent propagation; the signal corresponding to the
event is always emitted on at least one widget.

>    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.
> 

This is nonsense. OO design does not mean that all objects behave the same
way. Different objects are, well, different. They do share some interface;
but you have to justify why eaach interface should be shared. There is no
a priori reason why this one should be.

However, the interface *is* shared - they all do behave the same way *if
the interface is invoked*. The "inconsistent" behavior you are seeing is
the same "inconsistency" caused by clicking on one widget and not another
- i.e. the interface is invoked in one case and not another. This has
nothing whatsoever to do with the object hierarchy; in fact it's
implemented by the main loop, in gtkmain.c.

It so happpens that it is possible to get the effect you want, because you
can connect to signals and override the default behavior. You can also
stop signal emissions, or install emission hooks to monitor all emissions
of a given signal.

In fact the feature you're griping about makes it possible to do what you
want - if you just connected to all button press signals and threw up a
dialog, you'd throw up ten dialogs, some describing invisible widgets, for
every button press. Which would be brain damaged. What you want to do is
respond to leaf widgets only.

If you do want the 10 dialogs, just walk up the widget tree from the leaf
- yet another way to implement what you're describing. 

> 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.
> 

Many of us are also writing professional code with Gtk.

> 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.
> 

I think you should take the time to understand Gtk's current design before
you recommend sweeping backward-incompatible changes. Otherwise no one is
going to listen to you. A good way to become more familiar with the design
is to try actually implementing some of the things you're talking about
(either the event model changes or the ALT-button-press behavior).

That said there are many rough edges in the toolkit, and lots of them
would be very worthwhile to work on. I hope you will choose to do that. 
Perhaps event handling can be improved, even - but you will need more
concrete reasons, tied to the actual code and its behavior.

IMHO only and I am not one of the Gtk maintainers.

Havoc