|
From: Bryan W. H. <bwh...@ea...> - 2002-08-18 18:59:10
|
Ivica Loncar wrote: > Lothar Scholz <ll...@we...> writes: > > >>Are you sure you read the section in the FAQ that explains why this >>message passing algorithm was choosen ? > > > Aha and as unexpirienced in that area I don't think: > > Templates are instantiated at compile time. This means it's going > to be difficult to hook up objects which are only known at run time > [like e.g. loading a custom control from a DLL]. > > To connect a message source and a target, you actually construct a > connector object that is parameterized by the target; you can not do > this unless you know the type of the target [This is because > pointer-to-member-of-class types can only be downcast!]. > > Hard to serialize, because a pointer-to-member-of-class contains a > function-pointer when the member is not a virtual. > > are good reasons for not using signal/slot mechanism from libsigc (I > would appreciate more examples since I would like to write portable > applications but I'm stuck on FreeBSD and Linux). Signal/slot idea is > tempting from my point of view (easy to accept, less user code, small > number off errors), and some Qt users I talked to said they would be > very tempted to use GUI library that doesn't require some kind of moc > and acts as gtkmm (other reasons to switch were: good documentation, > lgpl, very few dependencies, active development). Biggest problem that I see with void*'s is that you are promoting typesafety through obscurity of the event handler. To give you an example, I'm working at DlgEdit, a GUI editor for FOX written by Martin Welch that was abandoned. In one of the callbacks, an object is expected to be passed by the handler. The code is in transition; a bool is passed instead, and causes as soon as the void* is deferenced. What do you do? Something I was thinking of was Boost::Any (from the Boost Libraries; www.boost.org). You get an "any" container that has an object/type of whatever you are passing through. As it's wrapped with an accessor method, you can do static_cast<>'s on it and get controllable runtime errors (which you won't get the opportunity to do casting from a void*). You can use rtti and see what was actually passed to you, if you'd like. DlgEdit looks like it might be nice. Problem is, I'm not deep enough into it's design to know what Martin was doing at the time (and he doesn't recall). In a pinch, I use Glade, have it spit out C++ source, and then transcribe the call patterns to Fox. Because, while I used to be able to write dialog panels without a layout editor, that was back in the Open Look toolkit days (heh. I used to write assembler programs in ddt, too. No more!) > > Now, I'm not trying to say what Jeroen is doing is wrong and I'm not > trying to do something about it. I'm just asking would it be hard (how > hard) to convert FOX to use signal/slot mechanism and where should I > be careful when (possibly) doing that conversion as hobby project. I > hope that's not off topic on this list. > > Btw. Are there any usable GUI builders for FOX? > > > > ------------------------------------------------------- > This sf.net email is sponsored by: OSDN - Tired of that same old > cell phone? Get a new here for FREE! > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 > _______________________________________________ > Foxgui-users mailing list > Fox...@li... > https://lists.sourceforge.net/lists/listinfo/foxgui-users > -- ____ .:. ____ Bryan W. Headley - bwh...@ea... |