On Sun, 2006-07-09 at 11:38 +0200, Murray Cumming wrote: > On Sat, 2006-07-08 at 19:54 +0300, Paul Pogonyshev wrote: > > Murray Cumming wrote: > > > I suggest that you try to distribute this in a separate library for now. > > > I'm not sure that people will consider it worthwhile to introduce the > > > extra concept into their code, but let's see if they like it. > > > > It's pointless. I will never convince Gtkmm people to use another library > > and conditions only make sense when they are built-in in the GUI classes. > > It sounds like you are suggesting a huge addition of API. For instance, > several new objects for every property. That's certainly not worth the > small gain. > > If you can't make this generic then it doesn't seem worthwhile. If you > can make it generic then you can put it in a separate library, and > that's the best way to keep it generic and allow it to mature. > > > The only alternative I can see is to build low-level functionality in > > Glibmm instead of sigc, but sigc is a more logical place since conditions > > only depend on signals presence. > > > > Is your decision final? > > I'm not sure what you would like to put in glibmm or libsigc++. You've > just said that it must be in gtkmm. But feel free to try to persuade me > with a patch. Also, I'm not the only libsigc++ maintainer.
i am with murray on this one. for every 2 cases where the API that has been outlined would be useful, i can come up with 1 case where the "condition" would be too complex to be usefully expressed with the API. so is it useful? yes. is it worth adding a lot of stuff to an already substantial API to support this particular subset of cases? i don't think so. --p _______________________________________________ libsigc-list mailing list libsigc-list@gnome.org http://mail.gnome.org/mailman/listinfo/libsigc-list
