On Monday 03 July 2006 21:48, Paul Pogonyshev wrote: > Chris Vine wrote: [snip] > > You refer to Gtk, so are you confusing libsigc with the glib event loop? > > Firstly, libsigc of itself knows nothing of Gtk/Gdk events: it is just a > > callback mechanism. Secondly, gtkmm classes already have signals > > (implemented with libsigc) which you can connect to, which indicate > > whether the state of a widget has changed. For example, classes derived > > from Gtk::Widget emit state events if a widget is maximised or iconised, > > as well as visibility, style and size events (and many others). As you > > refer to a "check_box", Gtk::CheckButton emits activate, clicked and > > toggle events. > > I'm not confusing anything. If there is no condition class, Gtkmm cannot > return conditions. They have to be implemented first and I think sigc++ is > a better place for it than Glibmm since they are not wrappers over Glib. > > I'm not controlling neither sigc++ nor Gtkmm development, but I think that > it is very good to eventually have first to implement `condition' class and > second to return a set of ``standard'' conditions. E.g. a condition that > an entry is not empty or a check button is selected. The user (of the > libraries) can then combine conditions as they wish to produce ``advanced > conditions'', combinations of simple ones.
libsigc++ couldn't possibly have "standard" conditions relating to whether an entry widget is empty or a check button is selected. It is relevant to a particular GUI implementation. libsigc++ could have a generic "observed" class which I now see that Ulrich Eckhardt has mentioned, which is a templated version of the accessor/mutator class I mentioned. He is the maintainer so it is up to him whether that it is included in libsigc++ (it seems a bit trivial to me), but it will not do what you want. gtkmm could implement your proposal, but first it does not require any changes to libsigc++, and secondly it seems pointless since you can aggregate gtkmm signals yourself if you want. > Currently this is typically done (AFAIK) by calculating condition ``by > hands'' and tracking its state. It is done through glibmm signal proxies via the gobject signal/slot mechanism. Gtk+ tracks the state. > For a complicated condition you need to > watch the state of several widgets (say, two entries and a check button) > manually. If you forget just one of those, you get errors where a widget > is erroneously sensitized/desensitized or shown/hidden. Besides, there > is a separate case of initial state which, ideally, should be computed > using the same rules. > > Currently all is done separately. I propose to aggregate everything in > one object of type `sigc::condition'. See above. [snip] Chris _______________________________________________ libsigc-list mailing list libsigc-list@gnome.org http://mail.gnome.org/mailman/listinfo/libsigc-list
