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



On Thu, 17 Sep 1998, Tero Pulkkinen wrote:
>Mario Motta <mmotta@guest.net> writes:
>I've been thinking of adding "visitor pattern" implementation to
>Gtk--.  This would basically allow people add new virtual metthods to
>Gtk_Objects and have algorithms (like object tree traversal) to call
>them, just like normal virtual functions. (They can do about the same
>now, but the algo is required to test if the object supports certain
>interface using dynamic cast => its not reasonable) Then users can
>call those virtual functions and have their widgets override the
>calls. -- for objects which does not support the method, some default
>behavior could be invoked.
>
i implemented this with recursive virtual function that recurses something like
this (using macro also)
#define DEFINE_SIGNAL_MAP(class,ancestor) \
bool DerivedClass::Handler(signal)\
{\
/* binding here class member offset with obj ... */\
/* and calling low level callback*/\
/* recursion stops if signal was answered*/\
/* or at root level */\
 if(SignalTreated(signal))\
	return 1;\
else return ancestor::Handler(signal);\
}

 >(though, I dont see any reason why this should be any way connected to
the
 >signal system...)

for seek of simplicity
>
>> - also a value returning callbacks should be useful
>
>There exists those. Gtk uses then for Gtk_Widget::*_event signals. 
>Similarly user defined signals can be defined that returns value.
>
>Signal1_r<rettype, firstargtype> sig1;
>
>what we still might need to add is different kind of handlers for that return
>type, so that people can override the function that goes trough the list.
>
>> - also callbacks with different args list should be useful (i don't remember
>> if already implemented in gtk--) i did'nt implement yet too.
>
>what you mean different arg list? You can make
>  Signal2<int,int> sig; 
>  and then connect
>  void f(int,int);   (or void f(int,int,T), where T is any type)
>  to it.
>
>(I'm not sure if you did mean exactly this, but if not, let me know what
>you were thinking about.)

i'm look for don't let the user decide between Signal1<arg>, Signal2<arg,arg>,
different callbacks should be autonomously called based on event , for
instance an key press callbacks should have an extra arg regarding key type,
status flag, or button press an extra arg regarding wich mouse button and
status flag. I dont know how achieve this, i made some test with static class
functions that scans event structure field <type> with no success
I know that's possible however.
>
>-- Tero Pulkkinen -- terop@modeemi.cs.tut.fi --
>
>-- 
>To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null
--
Mario Motta
===========
AI Research Group - Rimini
mmotta@guest.net
http://www.guest.net/homepages/mmotta/index.htm



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]