On Fri, Oct 30, 2009 at 9:43 AM, Brendan <mailingl...@endosquid.com> wrote:
> On Thursday 29 October 2009, you wrote:
>> On Thu, Oct 29, 2009 at 2:07 PM, Brendan <mailingl...@endosquid.com> wrote:
>> >> All the above comprise a significant factor in why forks are regarded,
>> >> at best, as a necessary evil. All forks dilute branding, which
>> >> introduces user confusion and repels potential users.
>> >
>> > I think it's incorrect to say it repels potential users and leave it at
>> > that. It will also just as likely ATTRACT new users who were put off by
>> > the lame name.
>> That's speculative. We know from past software history that what I
> The extent is speculative, the same as you. I know an entire office who said
> they would use it if it changed the name, so it's not nearly as speculative as
> you think.
Fair enough.

>> > Call it the Gnu IMP.
>> This has to be facetiousness, doesn't it?
> Most of what I say is at least slightly facetious. If they simplify it
> themselves, that's their problem, and not something that is super-obvious.

If we look at the way the photoshop family of products are abbreviated
by people(PS7/CE4/Elements),and GNU projects (bc, bash, tar, Octave,
etc), just plain IMP is reasonably likely. (in fact, GIMP is an oddity
in that the GNU is actually included in the acronym..
if it were more canonical, people would already be calling it Gnu IMP
or IMP). That's fair enough.. IMP *is* a better name (and people who
object to it on religious grounds probably are terminally humorless),
we just should expect it to still manage to be taken as objectionable.

Actually, I'm in favor of your proposition now, you've convinced me.
Gnu IMP is 'backwards compatible' as you say, more in line with other
GNU projects' naming, and could result
in image* improvement in the future.

As long as it's not a fork -- that is, the renaming would need to be official.

* The kind that doesn't have pixels in it :) but, well, the other kind
too I suppose :)

A list of files that would need modification:

[a few utility scripts like gimp-zip]
[most files with 'gimp' in the filename would need renaming. that is
>1686 files to rename]
[All enumerations which include 'GIMP' in them]
[.gimp-2.x would need to be migrated to .imp-2.x .. and then symlink
.gimp-2.x to that]
[On Linux, create a symlink 'gimp' pointing at 'imp' (or something like that)]
[We'd need to deliberately avoid changing the XCF and rcfiles format,
which refer to such object types as 'gimp-image-grid',
'GimpDeviceInfo', 'gimp-channel-list'.
Note: some rcfiles include 'gimp' in the names of objects, others do
not. I don't fully understand why.]
[themes would need to be updated to refer to 'imp-*' widget classes
rather than 'gimp-*' widget classes]

All active/'pending' branches would need to be updated to match (this
would be mostly trivial, I expect situations where new enumerations or
files were introduced to be more involved)

This would be quite time-sensitive in order to maintain a functional
GIT repository -- it would need to compile successfully again within 3
days. So it might take a small team just to complete this. Then the
documentation would need to be synchronized with the change
(screenshots, textual references to 'GIMP') fairly promptly after that
-- which is IMO quite hairy due to I18N concerns.

All *gimp* pdb functions would have to be deprecated in preference to
*imp* versions.

.po files would all need to be updated, however this would not need to
be done all in a lump but could be spread over time.

All the above would be best done at the beginning of a development
cycle (eg. when 2.8 has just been released). It would be relatively
free of the potential for invisible bugs -- most problems would show
up as compilation errors.

I believe the above is the minimum required to seriously do that
change. Though of course we could begin with the user-visible things
(binary names, and strings) and progress to the developer side
(filenames and  enumerations).. it would still be vital for it's
success to quickly do the migration on the developer side, which is
the majority of the work involved.

I can see why GIMP developers would want to avoid such a thing. I do
believe that the migration wouldn't require more than a very basic
understanding of the GIMP code base. What it would really need is a) a
great deal of organization and b) an active and moderately large team.
(doing only the user-visible side is a possibility.. but this may
result in confusion where eg. a PDB function is named gimp-* where the
program says it is 'IMP')

PS. 'The GIMP' is anachronistic AFAIK -- GIMP (no 'the') is canonical currently.
PPS. I believe (haven't tested, my GIMP GIT clone is not in working
order currently), that the
option '--program-transform-name=s/gimp/imp/g' to configure would
result in appropriately named binaries (imp-2.7 etc)
Gimp-developer mailing list

Reply via email to