On 23 Feb 2001, Michael Natterer wrote:
> > That lessens but does not solve the problem that the code is more
> > complicated because of the destruction of tools due to state changes.
>
> I'm quite a bit biassed about wether we should destroy tools after use
> or not, but IMHO a tool should simply be able to handle both. Of course
> it has to handle it's destruction :) and being able to change displays
> will enable features we may not think of currently. Also, there would
> be no need to decide now if we want to destroy the tools or not.
Good point. It doesn't really matter from the object's point of view when
it gets destroyed. But the tools should be able to handle changes of
display. And of course, we need to deal with the case where there is no
display more cleanly than the hacks that are in now.
> > > IMO the GimpToolInfo object Mitch just introduced to resurrect the tool
> > > system is the right way to go. GimpToolInfo objects stay around so Gimp
> > > knows what tools are available, can display icons, etc., the real GimpTool
> > > only exists when needed.
> >
> > I really like what Mitch has done with the tool code. He read my mind
> > when it came to renaming the gimp_tool_emit_* functions to more standard
> > names. The GimpToolInfo objects are elegant.
> >
> > Mitch: if you haven't yet written the code to get rid of the items marked
> > as needing to go away in the GimpTool class structure, let me know so
> > that I can write it and you can spend your time on less trivial code.
>
> Yeah, I went through the code when I re-integrated the tool stuff
> with the context and could not resist to apply some coding style
> paranoia. Most of the fields are already removed, I suggest to leave
> the remaining two (pdb string and cursors) there until there are
> some more tools back.
>
> The pdb_string could become a virtual function which returns the string,
> I'll care about making something real out of the cursor code when there
> are some more tools.
Fair enough. I was thinking about just putting them in GimpToolInfo like
the others, but that might be a more elegant solution.
> > I also wonder what happened to standard_control_func. I know it was
> > misnamed, but it contained code that all of the current tools use and was
> > fit for inheritance. In general, it should be ran before the tool's
> > specialized control code.
>
> The function is now in the context manager because it's a wrapper around
> the active tool's "control" method.
Just wanted to make sure it didn't disappear.
> > > > Problem: Some tools, such as iscissors, keep around a lot of cached data
> > > > generated from the image they are attached to. Changing the image they
> > > > are working on clears this cache. This can be slow when working on
> > > > multiple images or layers.
>
> <discussion snipped>
>
> Hm, I'd rather vote for making the tool system stable again with all
> tools in their proper places in the tool hierarchy before we start
> adding fancy stuff like caches.
That was the idea. Get it to work, then get it to work better. (if
nothing else, it's hard to debug code that doesn't work ;)
> And BTW, GLib already provides a cache mechanism which produces the
> requested data on the fly.
I haven't poked around in the glib header files in a while. I guess I
should since new useful functions keep on piling in there.
> > It is. I just think of the Gimp part as a namespace. Besides, after
> > typing GimpPaintingTool way too many times (yes, I found the macro command
> > in my editor...) I'm kind of sick of typing that big, long name. ;)
> >
> > (btw, why the "ing" ??).
>
> Please make it GimpPaintTool, you just talked about long names above :)
[snip]
> Well, I guess we should rather save some "ing" and add "Tool" all
> over the place to get a consistent namespace:
>
>
> GtkObject
> |
> GimpObject
> |
> GimpTool
> | \
> | GimpTextTool
> | \
> | GimpDynamicTextTool?
> |
> GimpDrawTool
> | | \
> | | GimpColorPickerTool
> | |
> | GimpPaintTool
> | \
> | GimpPaintbrushTool
> |
> GimpTransformTool
> | |
> GimpRotateTool GimpPerspectiveTool
It is nice and consistant. One problem: TransformCore and TransformTool
will both turn into GimpTransformTool under this system. (the transform
tool is sorta a hack anyway, so maybe this problem will go away...)
> Also, the policy is to name files exactly as the objects they contain,
> e.g. gimptool.[ch], gimpcolorpickertool.[ch].
>
> This may look a bit overly picky but a consistent file namespace is
> important in such a large codebase.
True. Yosh: should we rename them ourselves? (cvs remove, cvs add) or do
you want to rename the files on the server?
> > I'd like all the tools that don't take a specific point as input to be
> > turned into something else. My definition of a tool is something that you
> > click on the image with. They should also use the image view directly (as
> > should plugins).
> >
> > For example, by color select would count as a tool, but
> > contrast/brightness wouldn't.
>
> Of course the brightness/contrast stuff should be a tool, derived
> from GimpColorMapTool, how else do you want to get the display events
> there?
We'll deal with that after we get all of the tools (including the colormap
tools) working.
> > It will take some effort to do, of course, but it's worth it in simplicity
> > and user understanding. (Why do some things that work like filters not
> > respond to repeat last filter?, etc.)
>
> The "repeat last filter" stuff is just a bad hack due to the fact that
> not all gimp operations go through the PDB and can thus be repeated.
>
> While browsing through the code with this fact in mind i noticed that it
> cannot be _that_ hard to achieve this goal: once all main objects we can
> perform operations on (image, drawable, ...) are proper objects and
> live in their subdirs, we can redirect most commands.c callbacks and
> most stuff tools do to e.g. app/drawable/gimpdrawable-commands.[ch]
> where the respective PDB functions will be called.
>
> Looks like a bit of work, but if we want to hack GIMP 1.4's interface
> in a way that we can use it for 2.0, the way to go is to separate it
> cleanly from the core.
I like this method, because it allows for the possiblity of arbitrary
things like macro recorders. But just mentioning that opens the huge can
of worms of objectifying the PDB <shudder>
Rockwalrus
_______________________________________________
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
