Re: New 'GObject' as base for GtkObject?

[Karl Nelson <kenelson ece ucdavis edu>]

> > In effect this is the opposite of Qt.  In Qt the vfunc is provided
> > by the language and then calls the signal from the vfunc.  This allows
> > you the freedom to chose to call the signal or not, and to chose
> > the order of calling without all those flags.
> 
> But the "vfunc" in gtk+ is *also* provided by the language,
> in the form of a function pointer in the class object.

Right, there you have introduced one of the 5 combinations of
vfuncs that the C++ crew is fighting against.  Some gtk+
widgets just have function pointers that they use as virtual
functions.  Others are declared as part of the signal and so
forth.

> Internally there is no problem calling these functions directly...
> indeed derivers *must* do this to chain... 

I see little chaining except by direct calling of the function name.
This means that it isn't using teh vfunc table of the early class
but instead having the user hand wire it.

> So I don't really see why for once the c++ camp wants to make
> things more verbose and less automatic.

I certainly don't want more verbose or less automatic.  I merely
want a defined number of peices to work with.  I don't
like having to deal with signal with many varients and then
with virtual function table directly because the code writer
didn't think it worthy of a signal or just felt like using 
the C methods instead of gtk+ ones.

It is not more verbose to get rid of all that offset stuff.  
It removes a lot of logic from the signal system, at the
cost that every vfunc must be defined.  And it provides 2 distinct
features to wrap instead of 1 with many varients.  

How does simply defined concepts that can be used in flexible
ways worse than one concept that contains large numbers of
varients to provide flexablity?

> Furthermore it takes away a convenient invariant:  if you connect a handler
> to a signal, then emit the signal, the handler will be invoked.
> Unintuitive I think.

The question of what is the handler comes to mind.  Is the signal
handler for that widget, or are the signals
merely to inform external handlers (others)?  And shouldn't
widget decide what it wants to inform.

For example, a widget has an internal field F.  The user asks
to change F.  Should the signal be emitted if F decides not
to change it.  If signals are the handlers that there was no
choice.  If the vfunc is the handler then there is one. 
(and there is no need for RUN_FIRST/RUN_LAST, nor would
there need to be checking if there is a function offset. 
These are more varients that we constantly encounter.)

  gtk: User calls Signal calls VFunc  /* signal is handler */
verse
  Qt: User calls VFunc calls Signal  /* vfunc is handler, signal to inform */

I can see advantages to both forms.  (invarents and all)  
I do think we ended up with the more complex system.  More
complex generally means harder on the developer, not that
I would advocate changing.  (This is about the developer after
who cares about the wrapper writer.  They are already insane
for wanting a different language.  ;-)

Does that make the distinction more clear?

--Karl