Re: [gtk-list] Re: announce: yet another gtk+ C++ wrapper

[Mario Motta <mmotta guest net>]

On Thu, 17 Sep 1998, Karl Nelson wrote:
>What exactly do you need in gtk-- signal frame that isn't 
>there?  What API front end are you hoping from a signal frame? 
>
excuse me if a willl a bit long, but is necessary to clarify some things:
- since VDK is planned to evolve into a RAD we should lay the foundation for
some requirements:
- clear distinction between interface and application
- property browser
- in line two ways editor,means that changing properties visually will change
the code and viceversa, i'm hard waiting for Mailund syntax higlighting
widget:-)
 - automatic self managed signal dispatching system, user does'nt care about
signals, only response methods are under his responsibility. 
from such requirements comes that all signals should be "connected" by default
and a "broadcast" strategy should be implemented. For broadcast i mean that a
signal originated to a low-level widget (Gtk+ level) should be catched by
wrapping object and dispatched with a such type of logic:
1.goes to class wich object belong, if not treated goes up to object hierarchy
until someone treats it or reach object root class 
2. goes to object parent class, if not treated goes up to parent class
hierachy until someone treats it or reach parent root class.
3, if not treated signal is lost.
A signal is considered "treated" if and only if a response method willl
return true after receiving a signal (in VDK response are declared as:
bool Someclass::(VDKObject* sender);
A parent is a container of object (like box or tables or window as well)
This strategy permits to inherit response functions along the hierarchy and is
a requirements for component writers, the ones that reuse objects to make others
composite objects.
As you see is a so different approach that  only gtk-- connect  method have
been useful for me although could be possible reuse it to construct such
dispatching system but i should have to modify it.

 >I was one of the people who most recently rewrotepart of gtk-- signal
 >frame, and I would love to find some feature that would be useful to

 >the users.  I have proposed a number of extentions to it, but

 >most were deemed not necessary

 >
- could be useful a signal_emit  that recurses among object hierarchy.
- also a value returning callbacks should be useful
- also callbacks with different args list should be useful (i don't remember
if already implemented in gtk--) i did'nt implement yet too.

>--Karl
>
friendly
Mario Motta
===========
AI Research Group - Rimini
mmotta@guest.net
http://www.guest.net/homepages/mmotta/index.htm