Hi,
David Odin wrote:
> Most of the functions of gimpmiscui.h are related to the
> GimpFixmePreview stuff. This part looks pretty useful to me, and the API
> is clean enough to be kept imho. The only bad point I see here is that
> this code use the deprecated widget GtkPreview, but this could be easily
> fixed by using some GtkDrawingArea/GdkRgb stuff.
What do you propose, exactly?
> gimpmiscui.h also defines the gimp_plug_in_get_path() function which is
> only used by the FractalExplorer, gfig, and gflare plug-ins. This
> function doesn't look really useful, since it is only a wrapper for
> gimp_gimprc_query(), with some error-checking. I would vote to remove
> it. Anyway, even if we keep it, it should at least be moved to
> libgimp/gimppaths_pdb.c.
Removal sounds good.
> All the functions in libgimp/gimpmisc.h are related to regions or pixels
> fetchers or iterators. I'll investigate more to see if they should be
> kept, moved in a better place, or removed.
A pixel iterator that transparently does tile management would be
very useful, so some of these functions should probably stay
around. The API needs some work, though - looks like most of the
functions could be delegated to the plug-ins somewhat, once we
kept a PixelFetcher and an Iterator (perhaps with a slightly
modified API?).
I think that the GimpPixelFetcher API is pretty usable and
transparently does tile stuff... perhaps we should be using this
more consistently? For example, in plug-ins/common/edge.c the
pixelfetcher is used only for the edge cases where the pixels aren't
all in the same tile, which kind of defeats the purpose of
transparent tile handling.
The current API just feels a little awkward, but I'm not sure how
to improve it apart from perhaps changing the names of the
functions ending with 2 ... perhaps just splitting out into
gimppixelfetcher.[ch] and gimprgniterator.[ch], and refining the API
would be enough here?
Cheers,
Dave.
--
David Neary,
Lyon, France
E-Mail: bolsh@xxxxxxxx
