Hi,

Stephan Menzel writes:

as promised, I kept looking for the problem in porting refocus to the Gimp 2. It seems like the gimptool was indeed the main issue, but I got it running without switching to pkg-config as Sven suggested. Thought it might be easier since I really dislike automake.

pkg-config isn't related to automake. At least not more than gimptool.

Sven

Hi,

Stephan Menzel writes:

pkg-config isn't related to automake. At least not more than gimptool.

I know. But adjusting Makefile.am to use pkg-config would require be much more knowledge of automake than simply changing it to use gimptool-2.0. Sorry for the misunderstanding.

Not really. Let me give you some examples...

The standard way of using gimptool-2.0 from configure.in is to use

AM_PATH_GIMP_2_0(2.0.1)

The pkg-config way of doing this is:

PKG_CHECK_MODULES(GIMP, gimp-2.0 gimpui-2.0 >= 2.0.1)

Both macros do a version check and fill in the variables GIMP_CFLAGS and GIMP_LIBS.

Additional info can be gathered by calling gimptool-2.0 directly, for example:

CFLAGS=`gimptool-2.0 --cflags-noui`

The pkg-config way of doing this is to use:

CFLAGS=`pkg-config --cflags gimp-2.0`

The advantage of using pkg-config is that it's not a GIMP specific solution. You need to learn the syntax just once and can use it for all those libraries that install .pc files.

Don't get me wrong, there's nothing bad about using gimptool. Just wanted to point out the advantages of using pkg-config.

Sven

Hi,

Stephan Menzel writes:

Do you think there's a chance to include refocus in the gimp release at all?

I think that it should be included with every gimp installation but I don't think that the only way to make this happen is to include a plug-in in the gimp source tree. If we put the tarball up on ftp.gimp.org the plug-in would very soon be included as a standard gimp plug-in by all distributions and binary installers.

I don't follow refocus development closely but if is actively maintained and developed outside the GIMP source tree I'd prefer to keep it that way. Simply for the sake of keeping the GIMP source tree somewhat managable.

Sven

On 05/21/04 01:35:49, Sven Neumann wrote:

Stephan Menzel writes:

Do you think there's a chance to include refocus in the gimp release at all?

I don't follow refocus development closely but if is actively maintained and developed outside the GIMP source tree I'd prefer to keep it that way. Simply for the sake of keeping the GIMP source tree somewhat managable.

Perhaps a feasible idea is to create a set of extra plug-ins that are in a separate CVS module, similarly to what already happened to GAP, gimp-perl, gimp-help and most notably gimp-data-extras. This can make room for plug-ins that can be considered as very interesting or almost essential and can be included in distributions as a single package.

Pedro Gimeno

Hi,

Pedro Gimeno Fortea writes:

Perhaps a feasible idea is to create a set of extra plug-ins that are in a separate CVS module, similarly to what already happened to GAP, gimp-perl, gimp-help and most notably gimp-data-extras. This can make room for plug-ins that can be considered as very interesting or almost essential and can be included in distributions as a single package.

How is that different from keeping the plug-in in the GIMP CVS tree? The idea is to keep plug-ins that are maintained outside the GIMP tree outside the GIMP tree. Now if you move them into a gimp-plug-ins module, that's essentially the same as moving them into the gimp module. It makes it more difficult for the plug-in maintainer to continue to work on his/her plug-in and puts more work on the GIMP development team.

Of course, if a plug-in developer wants to use CVS or Bugzilla we should offer our help. And of course we should be willing to out packages up on ftp.gimp.org and announce releases on www.gimp.org.

Sven