Hi,
following up to myself ...
> Nathan, you didn't answer to our mails but I'd like to continue this
> discussion until a decision has been made. I don't like the idea of
> having unused code in CVS, so we should get to a point about
> gimptoolgui.[ch].
I'm still waiting for an answer here. My
Hi,
Nathan, you didn't answer to our mails but I'd like to continue this
discussion until a decision has been made. I don't like the idea of
having unused code in CVS, so we should get to a point about
gimptoolgui.[ch]. I'll try to pick up the decision where it was left
abandoned:
> > It's more a
Hi,
> It's more a tool_options redesign. GimpToolOptions will be derived
> from GimpContext and not have a GimpContext. So it will inherit
> all (de)serialization stuff. All option values will be GObject
> properties so the tool options GUI can be created from gimppropwidgets.c
> (which will be ex
Nathan Carl Summers <[EMAIL PROTECTED]> writes:
> On 30 Jan 2003, Sven Neumann wrote:
>
> > Hi Nathan,
> >
> > when I updated my gimp tree this morning I was surprised to see this
> > commit:
> >
> > 2003-01-30 Nathan Summers <[EMAIL PROTECTED]>
> >
> > * app/tools/gimptoolgui.[ch]: Gim
On 30 Jan 2003, Sven Neumann wrote:
> Hi Nathan,
>
> when I updated my gimp tree this morning I was surprised to see this
> commit:
>
> 2003-01-30 Nathan Summers <[EMAIL PROTECTED]>
>
> * app/tools/gimptoolgui.[ch]: GimpToolGui, a new class descended
> from GimpObject to be used
Hi Nathan,
when I updated my gimp tree this morning I was surprised to see this
commit:
2003-01-30 Nathan Summers <[EMAIL PROTECTED]>
* app/tools/gimptoolgui.[ch]: GimpToolGui, a new class descended
from GimpObject to be used to separate GUI from logic. Heavily
inspir
