I'll go ahead and make the SettingsObserver and stubs for the App signals
to be moved later.  I wont be able to write it until later tonight so I'll
have all day to think about it.

And actually I think the specialized settings classes (pen, selection,
etc.) will have the observer interfaces, so IPenSettingsObserver, etc and a
IGlobalSettings for stuff that doesn't fit in the categorized settings.

I just have to get my brain out of python mode and all the clever dynamic
programming tricks for doing this kind of thing :-)

On Nov 25, 2013 9:58 AM, "David Capello" <notifications@github.com> wrote:
>
> In src/app/settings/settings.h:
>
> > @@ -62,6 +67,9 @@
> >      virtual IToolSettings* getToolSettings(tools::Tool* tool) = 0;
> >
> >      virtual IColorSwatchesStore* getColorSwatchesStore() = 0;
> > +
> > +    // Signals
> > +    Signal1<void, const app::Color&> ChangeMoveTransparentColor;
>
> It's ok. We can leave this signal here (it's the first signal on
ISettings). Anyway I'm trying to avoid them (or use them only on widgets).
I remember that I've used them on app::App class, but now I think that an
AppObserver class would be much better. In this case, an SettingsObserver
could be better (also a lot of signals in App class should be overridable
member functions in SettingsObserver, e.g. PenSize/AngleBefore/AfterChange,
CurrentToolChange).
>
> It is up to you. If you have time to create an SettingsObserver you can
go for it. If not, we can merge the pull request as it's.
>
> —
> Reply to this email directly or view it on GitHub.