Re: Second draft (was Re: defs files)

[Karl Nelson <kenelson ece ucdavis edu>]

> On Thu, 20 Jan 2000, Karl Nelson wrote:
> 
> > 
> > > I agree. Whether a particular signal has an emit function or not is
> > > not really the business of the language binding.
> > 
> > The business of the language wrapper is should it provide a 
> > function to be equivalent to gtk_signal_emit_by_name(o,"foo",blah)
> > or is there already one.  
> > 
> > Please don't tell me that all signals are private.  I 
> > translated the gtk+ tutorial and have looked over testgtk+.  Every
> > time we have assumed that some signal shouldn't be emitted directly
> > from application code we find another case where it is.  
> 
> i told you on the GObject thread already. the only signals that language
> bindings or widget users are allowed to emit are GTK_RUN_ACTION signals.
> if you see code emitting a signal that is not GTK_RUN_ACTION, there are
> two possibilities

Okay, but still we are discussing what should be in the spec.  Since
GTK_RUN_ACTION is not in the defs file, requiring looking in the
code would mean the defs were useless for wrappers.

Just to audit one widget, only clicked is GTK_RUN_ACTION, yet
pressed, released, clicked, enter, and leave are all callable and
have emit functions.  Therefore, the rule is so inconsistently
applied (at least for that widget) that the wrapper will not know what
how to wrap and relate the signal functions to the emitting 
functions.

So should  (pressed, released, enter, leave) all be GTK_RUN_ACTION
and are improperly marked?  Or does run action mean something 
other than what info that I need to know to establish the 
wrapper binding?   

(To properly bind them, I require the name of a function for
all signals that can be emitted by the user, or a flag to
indicate that my wrapper can make the emit call itself.

Remember that all those cases where gtk+ can take a signal
by name like menu items also have to be emittable by a function
for a signal system wrapper to work. )
 
--Karl