On 6/26/06, Michael Ekstrand <[EMAIL PROTECTED]> wrote:
> On Sun, Jun 25, 2006 at 10:12:13AM -0700, Joe Van Dyk wrote:
> > Say a user clicks a checkbox in a menu that affects three other parts
> > of the application.  Would a signal be the best way to communicate
> > that change to the rest of the application?  How would that work?
> > Would I create a custom signal or slot?  How would the other parts of
> > the application listen to that signal?  Would I create the slot and
> > then pass that slot to the other parts of the application (i.e. in a
> > constructor)?
>
> What exactly you do to accomplish depends on what you're doing,
> obviously.  However, signals and slots are frequently a decent way to do
> this kind of thing.  For example, in my application, I have a singleton
> class that manages application settings.  My preferences dialog sets
> configuration items in this config class when its checkboxes, etc. are
> manipulated.  Other parts of the application can then connect to signals
> the configuration engine fires when config keys are changed.  So when
> you check the "always show tabs" checkbox, it sets the "tabalways"
> configuration key to True in the config engine.  The config engine then
> fires the signal connected to the "tabalways" key, so any listening
> application component knows that the "tabalways" option has changed, and
> can adjust itself appropriately.  It provides a very flexible, and
> somewhat centralized, wah of disseminating such events.

How do the various application components listen to the signal?

> > Sorry for the basic questions, but signals and slots and functors are
> > still confusing to me.
>
> As to me, with regards to their innards at least.  Dressed up in more
> template stuff than I'll probably ever know.  But they aren't near as
> confusing as they look, as long as you don't try to understand exactly
> how the C++ compiler will make everything work.  The libsigc++ tutorial
> docs provide everything needed to effectively use signals and slots,
> perhaps with the augmentation of a good STL reference such as the one on
> SGI's website.  The reference manual is usually more confusing than
> benificial - I'd really advise you to ignore it if you're trying to
> learn libsigc++.
>
> (No offence intended to those who prepared the reference docs.  It's
> just that all the template stuff, while excellent for completeness and
> documenting implementation and limits, obscures what's actually going on
> from a library user perspective.)

I've gone through the tutorial for libsigc++ and it's still terribly
confusing to me.
http://libsigc.sourceforge.net/libsigc2/docs/manual/html/ch02s02.html
says "Handily it derives from sigc::trackable already".  I have no
idea why that's handy.  First time sigc::trackable is referenced in
the document.

Any chance someone would like to update that tutorial to make it a bit
more clear?  And possibly also introduce functors in it?

Thanks,
Joe
_______________________________________________
gtkmm-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gtkmm-list

Reply via email to