GNOME Bugzilla – Bug 310565
wanted: a link to gimptool named by version
Last modified: 2005-08-13 23:24:32 UTC
Respectfully requesting that gimp-2.x install gimptool-2.x in addition to
installing gimptool-2.0. (Presumably one would be a link to the other.)
I have GIMP 2.0, 2.2, and 2.3 on my system.
Each one of them includes a program called gimptool-2.0.
These three programs with the same name do different things (install to
~/.gimp-2.0, -2.2, and -2.3 respectively). It's impossible to install a plug-in
to all three of these, or to one specific one if it's not first in the path,
without knowing the full path to each one.
In my C plug-in's Makefile. I want to make it easy for users to install to any
or all of their gimp versions (either with one command or with several). But
currently, there's no way for gimptool to install to any version besides the one
that happens to be first in $path, since the others are hidden from it.
What would be perfect is if GIMP installed a gimptool-2 and a gimptool-2.x, but
I suppose it's probably too late for that since 2.2 has already shipped with a
gimptool-2.0 even though it's not 2.0.
I am hoping, though, that even in 2.2 versions it'll be possible to add this
link, so 2.2 doesn't hide 2.3/2.4 or vice versa as far as plugin installation goes.
This is an enhancement.
There isn't much point in keeping different versions of GIMP 2.x installed. I
don't see why we should add support for this. There is always exactly one
gimptool binary in the PATH and your Makefile should assume that this is the
only gimp-2.x installation.
The fact that gimptool has the 2.0 version number is intentional. gimp-2.2 is
source and binary compatible to gimp-2.0. The API version is 2.0 and that's what
gimptool is all about. Closing as WONTFIX.
I have found this confusing as well. Would it do any harm to rename the command
gimptool-2 instead of gimptool-2.0?
Of course it would do harm. The name of the executable is part of the API and
renaming it would break scripts and Makefiles and thus would break backward
compatibility. There is also a good reason why it is called gimptool-2.0 and not
gimptool-2. After all the API version is 2.0 and not 2.
I should mention that I filed this at yosh's request after some discussion on
bugzilla. Reopening for yosh's comment.
I'd also like to stress that I did not ask for the existing name to be removed.
I do think it's misleading, but I understand that it's too late to change that.
This bug is asking for a link to a clearer file name, not a replacement of the
But the filename isn't misleading and there's absolutely no point in changing it
or providing an alternative. I don't understand the reason behind your request.
The handful of people who actually have different versions of GIMP installed on
their system know very well what they are doing and should be able to handle
plug-in installation w/o the need to introduce the ugliness of another gimptool
binary with a completely wrong name.
*strongly disagree*. The plugin api is backwards but not forwards compatable.
There really is a difference between linking against 2.0 and 2.2, because 2.2
provides symbols 2.0 does not. To express this simply:
2.0 API != 2.2 API
2.0 API < 2.2 API
The subset symbol would be more appropriate, but < is good enough.
A plugin written to the 2.2 API is not necessarily written to the 2.0 API; if it
avoids deprecated parts of the API, this is even more likely. A script or
Makefile that calls gimptool-2.0 is buggy if the plugin contains even one 2.2+
function. The user will get a bewildering linker or compiler error which gives
no indication about how to fix it. It's easy to figure out if your plugin can't
compile because "gimptool-2.4 not found" and you only have gimp 2.2 on your
system what the problem is and how to fix it.
That aside, I also find your comment about gimptool being an end-user tool
puzzling; supporting developers has always been an important, nay, primary
aspect of this tool. In real life, developers have multiple versions of gimp
installed, and there are very legitimate reasons to want to link against a
particular version; it it arrogant to assume you know what is best for them.
Core developers are not the only ones that find gimptool useful, either. Any
plugin developer that wants to test their code against or use the new features
of the developer version of gimp can use this tool. It's especially important to
have a version of gimptool for the unstable version since the prefered method of
installing developer gimp requires on linux the use of rpath linker options, and
remembering this kind of trivia is exactly what gimptool was designed to do.
You find a binary called gimptool-2.2 ugly. I find compiling a plugin that does
not work for the binary called gimp-2.0 with a program called gimptool-2.0 ugly.
There is no accounting for taste.
As a personal suggestion, writing there is no reason for something in response
to several reasons given for it, even if they are reasons you for some reason
dislike, is a much uglier behavior than version numbering adminstrivia.
Respecting other's opinions is an essential skill for working on an open-source
project, especially one as large as GIMP.
Well, going for gimptool-2.2 would not only deviate from what other projects are
doing but also from the version numbering scheme that we decided on for
gimp-2.x. I don't see any reason to do that change. None of the arguments given
here hold up. If you have multiple versions of gimp-2.x on your disk (which is
rather unlikely), than you have them in different paths anyway and can easily
distinguish the gimptool binaries that way.
Plug-in authors are best advised to use pkg-config to check for the GIMP version
and also to compile their plug-ins. The only remaining use of gimptool nowadays
is to install scripts and plug-ins to the user's gimp directory. Anything else
can be better done using pkg-config. Probably the best thing we can do is to
finally deprecate gimptool.
Hm, when we initially discussed this on IRC, I thought it would be ok, but
thinking it through now I don't think this is such a good idea. Having multiple
2.x versions installed has enough caveats already, adding one more source of
confusion doesn't seem wise. As it stands, you can't reliably have out-of-tree
compiled plug-ins working in with a GIMP using non-system libraries, without
doing LD_LIBRARY_PATH tricks.
Perhaps there should be a ~/.gimp-2-plugins dir searched too.