RE: [gtk-list] Re: Signal and event management.

["Enric J." <rayder iname com>]

----------
> De: Karl Nelson <kenelson@ece.ucdavis.edu>
> Asunto: [gtk-list] Re: Signal and event management.
> Fecha: jueves 3 de diciembre de 1998 21:59
> 
> Regarding Gtk--:
> 
> Gtk-- just uses templates to wrap the gtk+ signal connections.  The
> reason for this is to allow typesafty of C++.  Basically, they
> do nothing but provide a call and connect function while giving
> the compiler a template to match arguments with so that type mismatches
> are disallowed.
> (templates are located in gtk--/src/build_sources)
> 
> The interactions of connections are described both ways.  
> The gtk+ system can call a C++ function
> through the proxy or a C++ function can call a gtk+ function.
> When a signal is emitted from C++, it is dispatched to a C++ function,
that
> either calls a list of C and C++ functions (our signal system) or
> calls the lower gtk+ signal model.  If a signal is emitted from gtk+ C
> level, it will call a static function that calls into our layer.  All
> of the Proxy code that you see there is to name the static functions
> and proxies to gtk+ equivelents.  That is why the gensig preprocessor
> builds the source of Gtk--.   
> 
> All of this is done at connect time...  We implement a new
> connect that we use to decide whether it connects to the lower level
> or stays in our C++ system.  We do not interrupt any of the calls of
> gtk+ normally, other than to call the impl function.  See VDK if
> you want to see a system that is more envasive to the signal system.
> You may also want to look at WxGtk (I think), as theirs is a wrapper
> that changes the hierachy.

Yes VDK is closer to my needs, btw Gtk-- is dificult to implement in
pascal.

I've read a lot of code lately, I have WxGtk and I will look at it, I'm
sure that I'm going to find a good solution with all your help.
 
> Basically, ours is the opposite of your model where you wish to capture
> all events and signals.   We capture nothing unless the user instructs a
> connection to be made.  To do what you are describing, you may 
> want instead take over the event loop and then channel the 
> events to your signal dispatch system.  That why you get to 
> initate the events to the gtk+ system.  You can then
> reemit them to gtk+ for those events your system does not handle.  Then
> you would also have to describe the interactions of your system with
> signals emitted from gtk+ (such as button pressed).  (It is still 
> a lot of work!)

This is the first thing I thinked, but, IT A BIG JOB, so I started looking
other places for an easy one :-)
 
> I hope this helps.

Yes, it helped me to understand Gtk--.

Gtk-- is right, and somewhat complex, by your explanation of how it works
is clearly a way to follow, but by its C++ inheritance I think is not well
suited to my needs, I'm going to look at VDK and Gtk-- for a solution, and
I will keep you informed of any advances I could do.

Thanks for your aswer and your time.

Bye.... for now...

Enric
----------------------------------------------------
Microsoft does have a Year 2000 problem. We're it.