One way we did it is MCS (for modular configuration system), it's similar to GConf basically, and there are 2 important things concerning your problem:
MCS GTKmm "bindings": By binding, i don't mean lnaguage binding, but you can do stuff like Mcs::Bind::range_float (Gtk::Range *, std::string const& domain, std::string const& key) (as you see our configuration system is only 1 level deep specifying a domain and a key inside it (no paths allowed), but it's enough for our app and should be theoretically easily extensible, or e.g. Mcs::Bind::entry (Gtk::Entry *, ...), which will 'bind' the state of a widget directly to a value stored in the configuration. Then there is the "subscription" part, it also works similar to gconf albeit without all the deps etc, typedef boost::variant<bool, int, double, std::string> KeyVariant; typedef sigc::slot<void, std::string const& /*domain*/ ,std::string const& /*key*/, KeyVariant const& /*value*/> SubscriberNotify; Mcs::subscribe (std::string const& subscriber_name, std::string const& domain, std::string const& key, SubscriberNotify notify); This i will call the given slot whenever the specified value changes, and it works very well for exactly those tasks you've described, and with a little proxying also well over D-Bus. You can find MCS as an svn module in our SVN: svn co http://svn.beep-media-player.org/mcs/trunk/mcs mcs http://websvn.beep-media-player.org/listing.php?repname=mcs&path=%2Ftrunk%2Fmcs%2F#_trunk_mcs_ Milosz On 3/15/07, Paul Davis <[EMAIL PROTECTED]> wrote:
List, I've never been able to keep a good MVC design split with gtkmm (or any gui toolkit for that matter). My basic concern is having multiple copies of some values that are displayed in a gui. For instance, imagine we have a double value stored in some user object. This value gets mapped onto an HScale in the GUI. There are effectively two copies of this value (one in the user object, one in the hscale) that need to be kept in sync. I'm mostly interested in what other people have done to get around this and similar types of problems from a design stand point. The only promising answer I can come up with is to create my core app logic with some sort of its own call back system, then have a GUI toolkit specific layer that sits between my custom app code and the toolkit of choice. Anyway, if anyone has any pointers, I'd be glad to hear them. Paul Davis _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
_______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
