On Tuesday 04 July 2006 19:10, Paul Pogonyshev wrote: > I wrote: > > > This is getting pretty pointless. Lets end it here, as an ounce of > > > code is worth a pound of words. > > > > OK. I'll try to write something. > > Here is `something'.
Okay. Let me try to summarise what you wrote there, just to make sure I got it right. Apart from what everybody (well, at least me) understood the first time, that you want an observed boolean value (like some languages/toolkits provide), there are two other important aspects to your code: 1. handle/body separation The class 'condition' is split into an interface and a pointer to a refcounted implementation class. This means that the condition is copyable(!) in pretty much the sense that a Java or Python reference is copyable. The copy is not a distinct object but all copies refer to the same underlying implementation. This makes it possible to create a 'condition' somewhere and pass it on to other places with ease. A simple observed<bool> like I described would be copyable but loose all information about connected slots, i.e. it would only copy the underlying value, not the rest. I'd probably disallow copying altogether for that since it makes little sense. 2. boolean operations These combine two 'conditions' and yield another condition. This automagically combines both the boolean values and the emitted signals of the original 'conditions'. This is achieved by a set of utility classes for the various operations (and, or, not, xor) and factory functions (in the example code it is an overloaded operator+ which combines two conditions). The suggestion then is that a widget would have such a 'condition' for e.g. its visibility, which the user could then combine from whatever other conditions should be met to make that widget visible. So far, so good, I'd be interested in how it would be to program with this (you never know if an API is good until you have really used it). I think it would not be necessary to touch libsigC++ for now - rather, such a library could be implemented on top of it. It might even be better as part of GTKmm, since the use of a single boolean is rather special. On the other hand I could also imagine other types being handled in that way, e.g. tri-states or other values. In any case I'd present this to the GTKmm people! One thing I noticed while reading your code: there are two classes that only serve to adapt/mediate between a condition and a widget. A simple function might have been enough, using bind() to set the parameters. BTW: someone called me a maintainer of libsigC++, but that is only partially true. I indeed 'maintain' (if there is anything to) the 1.x ports for MS Visual C++ and also a private (i.e. not part of mainstream) port for MS embedded Visual C++ (used as cross-compilation environment for Windows CE devices). Other than that, I haven't even touched libsigC++ 2, exactly because I still have to maintain code for older compilers that aren't even close to compiling 2.x. cheers Uli **************************************************** Visit our website at <http://www.domino-printing.com/> **************************************************** This Email and any files transmitted with it are intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any reading, redistribution, disclosure or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient please contact the sender immediately and delete the material from your computer. E-mail may be susceptible to data corruption, interception, viruses and unauthorised amendment and Domino UK Limited does not accept liability for any such corruption, interception, viruses or amendment or their consequences. **************************************************** _______________________________________________ libsigc-list mailing list libsigc-list@gnome.org http://mail.gnome.org/mailman/listinfo/libsigc-list