|
From: Mathew R. <ma...@op...> - 2002-08-19 04:31:08
|
Hi, I think you missed the whole point about FOX... > 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 1. FOX applications are (generally) more portable than libsigc apps, since Jereon and others have made portability a prime requirement. 2. Do you mean libsigc or libsigc++? SigC is reasonably complicated for doing object orientation; ie using C (rather than C++) for OO. It is generally accepted that OO is a more useful metaphore for application development. > 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 3. signal/slot mechanism requires more code (not less) than the message-system, for any non-trivial application (ie more than hello world, for example, PathFinder) 4. '... small number of errors...' -huh? > 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). > > 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. It would be a quite a large amount of work to convert FOX to signal/slot. I would first look at wrapping every important FOX class (like FXObject, FXWindow, etc) with the equivalent wrapping mechanism, ie convert all the FXMAPFUNC(..) instances to xxx.connect(..) calls. As an aside: you could argue that FOX is already signal/slot, except that more data is passed to each callback, so that when an event is fired, the callback, can call back into the source of the event. Mathew |