Hans Breuer <[EMAIL PROTECTED]> writes:
> At 04:13 05.02.01 +0000, Nick Lamb wrote:
> >On Mon, Feb 05, 2001 at 02:26:23AM +0100, Hans Breuer wrote:
> >> The windoze version of gimpwidgefts can't include two symbols for
> >> different implementation of the same function. There is only one
> >> version of the dll in memory, even if loaded by another process.
> >> The code is shared across process boundaries while the data is
> >> not.
> >Try making two copies of the DLLs with different filenames, and link
> >plug-ins to one while gimp.exe links the other, that should fix it
> Yepp, but I was serching for a better way. Most of the stuff in gimpwidgets
> appears to be useful for other apps as well, but the whole lib won't be
> reusable, if there is a Gimp dependency. (I especially like the simplified
> method to construct option menus.)
The option menu stuff is so gimp specific that it is in libgimpui (not
libgimpwidgets) which may only be linked from gimp plug-ins anyway.
> Maybe the widgets, which are using Gimp internals should be split from
> gimpwidgets and linked into gimpui.dll (for plug-ins) or gimp.exe ?
Almost done :) The only ugly dependency from libgimpwidgets into
libgimp will be the GimpUnit stuff. The plan is to hack a very small
"libgimpglue" library which will swallow this dependency. To use
libgimpwidgets in an other application, it will be enough to strip the
PDB dependency from the libgimpglue source code and you're done (of
course there will be no user-defined units any more unless the "other"
application provides an implementation of this functionality).
Coming back to your real problem: before we started to restructure the
libgimp stuff, those widgets were linked statically into the GIMP, so
it's probably the best idea to continue to do so for Win32. Maybe you
can do some Makefile voodoo and send a patch ?