On Fri, Oct 30, 2009 at 9:43 AM, Brendan <mailinglist@xxxxxxxxxxxxx> wrote: > On Thursday 29 October 2009, you wrote: >> On Thu, Oct 29, 2009 at 2:07 PM, Brendan <mailinglist@xxxxxxxxxxxxx> 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: HACKING NEWS gimpui.pc.in [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 Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
