On Thursday 06 July 2006 21:07, Paul Pogonyshev wrote: > Chris Vine wrote: > > There are a few minor points of implementation about the code which are > > not a criticism (your code was just to convey the idea) - Glib::RefPtr is > > not used correctly > > Why (though it is not important for conditions)?
Glib::RefPtr is designed to reference objects derived from GObject (sorry, I can't remember their glibmm class designation, probably Glib::Object) but not from GtkObject (Gtk::Object). Classes derived from Gtk::Object are owned by the container in which they are placed, if you provide they are to be managed (as you did). If you assign them to a Glib::RefPtr you will need to increment the reference count when doing so in order to pass ownership to the Glib::RefPtr smart pointer. If you don't have them as managed objects, you don't need to increment the reference count (but you may have to call gtk_object_sink() on them to eliminate the floating reference - I am not sure whether you need to do this in gtkmm because I either use the raw C objects or, with gtkmm, have them managed by the container). > > and conjuction::update(condition, condition) calls a non-existent > > method (conjunction::set_state()), > > This method is defined in `condition_impl' and `conjunction' inherits that > class. So it is not non-existent. Yes I missed that. > > but the intention is clear enough and the > > absent conjuction::set_state() method was probably just a result of a > > cut-and-paste - I can see what it would do. > > > > However, your code does the updating of the Gtk::Button twice, which > > illustrates what would have been my point. > > No, it doesn't. Maybe I should have used different variables, but one > window's button is only condition-driven, while the other's is > `traditional'. You can make sure by deleting the second window from the > code. Only conditions are left and the first button is still working. OK, I see - I was misled by the fact that you had the window pointer as a class member, when it is only local to the constructor and used twice (and the same with the other members, other than the pointer to the Gtk::Button object). I had missed on reading through the code that you had done everything twice with two equivalent windows implemented in the two different ways. > > It does it once via > > Windows::controller (a SensitivityController object) employing the > > condition object approach which you propose. It does it again the > > "normal" gtkmm/libsigc++ way, via the following lines in > > Windows::Windows(): > > > > entry->signal_changed ().connect (sigc::mem_fun (*this, > > &Windows::update_sensitivity)); > > check_button->signal_toggled ().connect (sigc::mem_fun (*this, > > &Windows::update_sensitivity)); > > > > The Windows::update_sensitivity() slot just does this: > > > > button->set_sensitive (entry->get_text_length () > 0 && > > check_button->get_active ()); > > As I mentioned above, different methods of sensivity controlling are > applied to different buttons in different windows. > > > This slot tests and employs the state information retained by the gtkmm > > object, rather than by the SensitivityController object. In other words, > > all your code for condition objects can be replaced by these lines of > > "traditional" code. > > I'm not sure I understand you, but will try to answer. Yes, conditions are > nothing new. They are merely wrappings around currently possible code, > which make life easier. More code is moved to the libraries and less is > left for you to write. Instead of writing new callback, connecting it and > maybe setting the initial state you are done with combining standard > conditions and creating Gtk::SensibilityController (or calling > Gtk::Widget::set_sensitive (sigc::condition) if that is implemented.) > > > In its place, to implement the condition feature it is > > necessary to write implementation classes for each condition on a > > case-by-case basis (in this case, the ToggleButtonActiveCondition and > > EntryNotEmptyCondition classes). > > Yes, but this should be done in the library. All this classes should > belong to Gtkmm and you don't write them yourselves. Tracking sensitivity > or visibility is a common task and any non-trivial application does that. > Why not transfer this common task to the GUI library (Gtkmm)? > > > I do therefore wonder if it is worth it. > > Not really if they are not implemented in the libraries, because then > implementing conditions costs more than they save. If, however, conditions > are implemented in the libraries, I'm sure it is worth it, saves coding for > library users and makes error probability smaller. My comments assumed it was implemented in the library. The choice is between three lines of code and, as I said and you agree, writing implementation classes for each condition derived from condition_impl. > > Your approach is also rather inflexible - it can only synthesise from two > > states. > > Yes, conditions cannot solve all problems. If you need some advanced > checking, you should use traditional scheme, which doesn't go away. > However, I'm sure that 75% of appropriate tasks are solvable with > `standard' conditions. With a certain sense of deja vu, this would be relevant to gtkmm rather than the libsigc++ library (yes, I know you want the substructure in libsigc++, but I am talking about the condition implementation classes here, which is what is relevant to any "standard" conditions you propose). Furthermore, in my opinion (I accept not in yours) I doubt that there are sufficient synthesised conditions not already in gtkmm which are suitable as a standard. Chris _______________________________________________ libsigc-list mailing list libsigc-list@gnome.org http://mail.gnome.org/mailman/listinfo/libsigc-list
