Gimp Traffic #12 For 4 Feb 2000

By Alex Harford

Table Of Contents


Marc Lehmann announced to the list that a new plug-ins tree is available:

The gimp-plug-ins project on sourceforge is an experiment to give plug-in authors their own cvs, their own webpages, their own mailing-lists and more, while having a good time with the other plug-in authors, all at the same place.

Mailing List Stats For This Week

We looked at 286 posts in 868K.

There were 63 different contributors. 35 posted more than once. 35 posted last week too.

The top posters of the week were:

1. A Separate CVS For Plug-Ins

24 Jan 2000 - 27 Jan 2000 (15 posts) Archive Link: "Speaking of additional plug-ins"

People: Michael TaylorMarc LehmannGarry R. OsgoodDean JohnsonRobert KrawitzSven NeumannSven Neumann

Michael Taylor wrote the list one day saying, "I have a couple of image format plug-ins available for the GIMP one is included with the GIMP (pix) and one of them (formerly tdi, now MayaIFF) has been in the unstable tree since before 1.0 was released. The latest version, as always, is in the plug-in registry."

He continued to explain that it would be easiest if he could get his plug-in into the main tree, since most people who need this plug-in do not have access to a compiler.

Marc Lehmann had some suggestions:

I think the issue is independent of the type of the plug-in.

However, I don't believe in the "we accept no more useful plug-ins, since we already have so many useless ones in the tree" argument.

Falks: what about that "secondary cvs server for plug-ins"-idea? I only remember a few posotive responses, but no really negative ones. Is it only that nobody has the time to set one up?

Garry R. Osgood also had some ideas:

For the record, I think a plug-in CVS tree independent of Gimp is a good idea. At the time this was discussed, the office of a "plugin-maintainer" was also posed, the person who whould keep the CVS plugin tree well-pruned. The two ideas go hand-in-hand.

The issue is: who has the time? Without people, good ideas remain abstract.

Marc replied that he could set up a CVS server for plug-ins only, and take care of merges between this one and the main Gimp tree.

Dean Johnson had a better idea: "This has SourceForge written all over it! Its easy an convenient to start projects and manage stuff. I heartily endorse it!"

Robert Krawitz agreed, saying that "I've been using SourceForge for about a week for the Print plugin (the gimp-print project), and it's really good. It takes some time to learn, though."

Marc thought that this sounded like a good idea.

My idea is to copy the full cvs tree of gimp to (lets call it gimpforge) and give any intersted plug-in author write access.

Updates from the gimp-cvs-tree/{libgimp,app,tools...} to gimpforge should be automatic and regular, while updates in the other direction should be enabled for specific files (plug-ins/common/snoise.c) or subdirectories (e.g. plug-ins/perl).

That will effectively implement some kind of access-model, and it will (hopefully) make it possible to *select* a fileset for distribution.

Sven Neumann added some words of caution:

This all sounds nice, but I hope you are aware that once gimp-1.2 is out there will unlikely be another stable release (despite bug-fix releases of course) before gimp-2.0 and the plug-in interface for 2.0 will certainly be incompatible with what he have now.

I don't want to say that plugin development should stall until the new interface has settled, but it would probably be a good idea to take this into account from the beginning and split the tree from ground up. This means having two branches (stable and devel) on the plugin CVS. That way we could throw all plug-ins out when work on 2.0 starts and include them later out of the 2.0 compatible plug-in branch. However I haven't thought much about this yet, is it a good idea ...?

I also want to point out that IMHO setting up a CVS server will not be enough. Ideally, this project should completely replace the registry. A web interface to the repository together with tips for installation will be essential. Plug-ins should be released on a regulary basis, since working with stuff out of CVS is not what our users want to do and it always buries the risk of checking stuff out that just doesn't work at the moment.

Marc Lehmann explained how he will run gimp-plug-ins on SourceForge:

I suggest that I first create the project, add the mirroring (so the cvs is functional) and then gather _existing_ plug-in maintainers without cvs access to find out wether they want an account on ther sourceforge net.

After that, some files (i.e. the "externally managed" plug-ins) are read-only in the main cvs tree, and writable in the plug-in cvs tree, and all the rest is read-only in the plug-in cvs, and read-write in the main gimp directory.

This is the only solution that makes it possible to do automatic merges back into the main tree. It also complicates things for the main developers, so it should be given thought (in any case, the mirror script that I have allows to specify "file in original server", "file in copied/plug-in server" and "file is not getting mirrored" (i.e. it's part of gimp-plug-in-cvs but NOT part of the main gimp tree).

2. Error In growfont Subroutine

27 Jan 2000 - 31 Jan 2000 (3 posts) Archive Link: "Bug report #5523 - Image/Render/Fittext plug-in"

People: Michele GherloneMarc Lehmann

Michele Gherlone wrote the list to say that he had found a bug:


Looking at bug report #5523, I saw the following:

>The script crashes reproducable when called with the standard settings.
>I have checked that the selected font is installed. The problems seems to
>be located in text_fontname_invoker (), so the problem migth be a bug in
>the gimp core.

Having experimented the same problem with fit-text, I dived deep into the code. I thus discovered that the subroutine growfont has an error in the syntax, albeit the syntax is correct and gets accepted by perl:

sub growfont {
        ($fontname, $plussize) = @_;
        @fontdesc = split /-/, $fontname;
        $fontdesc[8] eq "*" ?
                $fontdesc[7] += $plussize/72 : # if in pixels
                $fontdesc[8] += $plussize;     # if in points
        $outname = join "-", @fontdesc;
        print ("!!!${fontdesc[8]}-${fondesc[9]}!!!\n");
        $calls ++;
        return $outname;

This will never do what was intented by the author: $fontdesc[7] won't get the correct value, if font size is in pixels. For example, with the default helvetica@34 setting, $fontdesc[7] should be: 34 + (288/72) = 38. But the first time the subroutine is called, the seventh fontdescriptor gets a value of 326!!, and at the end of the script, at the crash moment, get_text_fontname is called with a font size argument of -112, which of course doesn't make sense, and causes the sigsegv.

Having corrected the subroutine as follows:

sub growfont {
        ($fontname, $plussize) = @_;
        @fontdesc = split /-/, $fontname;
        $fontdesc[8] eq "*" ?  ($fontdesc[7] += $plussize/72) : ($fontdesc[8]+= $plussize);
        $outname = join "-", @fontdesc;
        print ("!!!${fontdesc[7]}-${fontdesc[8]}!!!\n");
        $calls ++;
        return $outname;

everything worked fine!!, the fit-text didn't segfault anymore.... Any comments??

Marc Lehmann replied that

i'll look into that ;) Maybe a constraint is missing somewhere.

Seth: I updated fit-text in the cvs with that change! Mike: Thanks a lot ;)

Mike was puzzled by this:

"Unfortunately, I wasn't able to see the change in the cvs. What happened Marc?? I think the fit-text is a nice and very handy tool, and it should be available to any gimp user!"

There were no more messages in this thread.

3. Removing HSV To RBG Routines

27 Jan 2000 (3 posts) Archive Link: "hsv to rgb"

People: Martin WeberAustin DonnellyRobert L Krawitz

Martin Weber announced to the list that "I removed the rgb to hsv (and hsv to rgb) routines from several plugins because this routines are now in libgimp. But there are still some plugins like compose, decompose and flame where I din't found the time to do so. Can someone other do this?"

Austin Donnelly noted that "The INTENSITY(r,g,b) -> grey macro could also do with being moved (if it hasn't been already)."

Robert L Krawitz also mentioned "Just a comment about the print plugin (I don't know if you've actually done it) -- I suppose it's no disaster to do that to 3.0, but the intent is that the core of the print plugin live standalone without the Gimp, e. g. in Ghostscript, or as a CUPS filter, or whatnot."

There were no more messages in this thread.

4. Additional Information On Gimp Plug-In CVS

28 Jan 2000 (7 posts) Archive Link: "important: automatic mirroring to the gimp cvs"

People: Marc LehmannSven NeumannKelly Lynn MartinSven Neumann Kevin Turner

Marc Lehmann provided a status report on Gimp Plug-In CVS at SourceForge:

Ok. I've just enabled automatic mirroring from the sourceforge cvs back to the gimp cvs.

The file gimp/PLUGIN_CVS in the cvs tree controls which paths are mirrored and which are not. If anything goes havoc just delete that file and the script will stop doing anything.

At the moment, only


is being written back. This (unfortunately!!) means that changes done to these files in the gimp cvs will get overwritten. I've not found a better way to synchronize two cvs trees better (maybe CVSup would help, but...)

Also, any developer who likes to administrate that sourceforge project (consider when I am away ;) just needs to register at sourceforge and drop me a note with his username to get added.

Kevin Turner and Kelly Lynn Martin raised some objections to this.

Sven Neumann gave a resounding


Sorry, the idea of developing plug-ins outside the gimp tree is probably a good one. But it is absolutely impossible to do that now. We are approaching a release and we need control over the plug-ins that are going to be distributed with gimp-1.2.

Marc futher explained his ideas:

Yeah. I plan to use this only for plug-ins already in the core.

BTW, Olof, Daniel, whoever-thinks-about-plug-in-management: The plug-ins module on sourceforge is the ideal playground for some more intelligent plug-in management (for gimp-1.3 and beyond).

IMHO every new plug-in should get a subdirectory there, and then we can craft some guidelines. For one thing, a mini-plug-in with a single .c file should be possible. This would also be a chance to somehow decentralize the i18n tables somehow. For example one could give each plug-in it's own message catalog and translation files which could be merged into one large one.

He replied to Sven's message, stating that

I am determined to branch the gimp-plug-ins tree at the same moment the original gimp-cvs tree creates a stable branch. I guess that might be the right moment to enable mirroring (to the main trunk, not the stable branch)?

So I suggest that plug-in authors treat the "gimp" module on sourceforge as a read-only mirror, which will, at some point, become partly writable for development.

In the meantime we could populate the plug-ins module with other plug-ins, and maybe move some plug-ins from the main distribution there.

Kelly replied that "No mirroring at all is my recommendation. Plug-ins should be out of the main branch altogether starting with 1.3."

Several other people voiced concerns over the separate tree, and the general concensus was that this CVS tree would be for plug-ins not in the current distribution only. When Gimp 1.3 comes out, all plug-ins will be removed from the Gimp and put into separate CVS.

5. Suggestions For Improving Gimp 1.1

28 Jan 2000 - 31 Jan 2000 (17 posts) Archive Link: "The Gimp: New Generation"

People: Sven NeumannDean JohnsonSven Neumann

Ar't had some ideas for improving the Gimp before 1.2 comes out. His first suggestion was changing the interface to picking colours, but several people found problems with that. His second was regarding translations:

Does translation of filter help tips make any sense ? Or would it be like with internal function help tips and they are going to be excluded ? (1.1.6->1.1.10).

Most of plugins place ":" in different positions
"bla bla:"
"bla bla: "
"bla bla :"
"bla bla : "

Is it possible to choose one (more likely the first one) and post it somewhere from where people could read it and change their sources.

Suggestions Continue with the plugins:
all general options, main options ,general preferencies etc change them all to "options" and unify.

Team Gnome i18n noticed that different languages have different forms in plural (worst has 5 forms and not 2 like in english) [1 cat, 2 cats ]
I haven't noticed many forms like that in Gimp but they exist.

Necessary Reconstruction of Menu <Image>/Tools It's too big (to be honest I really don't have an idea how to do it) If it fits in 640x480 it's ok but if not-please rebuild.

Sven Neumann replied that

I'm not really sure. It surely creates lots of work for the translators and I don't know if it is worth it. If we could agree on this subject, I would volunteer to remove the marks from all help-strings in the plugins PDB registration functions.

This is handled much better after Mitch overworked most plug-ins UI once again. If you still find places that should be changed, please provide a patch.

Well, I don't know of anyone using it frequently. Only probably to look up or change keybindings, so I guess we can easily add another level of submenus in here. A menu that doesn't fit into 640x480 is indeed a bug.

Marc noted that any menu can be made not to fit on a 640x480 screen.

Dean Johnson agreed with Marc.

"Exactly! Scaling is one of the the biggest problems with modern (especially Open Source) GUI design. Stuff gets written to accommodate the author's immediate needs and what happens when the data (in this case plugins) explodes in number. EVERY gui developer (casual or not) should be required to read Tufte's design books before being allowed to code."

There were no more messages in this thread.

6. Inconsistency In Handling Translations

31 Jan 2000 - 1 Feb 2000 (8 posts) Archive Link: "Translation inconsistency"

People: Sven NeumannNick LambStanislav BrabecMarc Lehmann

Sven explained the translation problems:

as pointed out before, we have an inconsistency between the core and the plugins when it comes to the point if PDB blurb and PDB help should be translated or not.

The situation right know is:

In the core the short description and the longer help strings for the PDB functions are not marked for translation. This decision was made since the PDB help strings are considered to be targeted mainly at developers and script-writers. It would be a lot of work to translate them and even more work to get the translations correct and to keep them uptodate. So it was considered not to be worth the effort.

In the plugins domain however we did not spend too much attention and have marked those strings for translation. Well, a lot of plug-ins don't give useful help strings, so the amount of work for the translators is not as large as it would be for the core.

I have no idea how to handle this. Just a few suggestions:

(A) do nothing, ignore the problem
(B) don't mark the strings for translation, not in the core, neither in the plug-ins
(C) mark the core PDB strings for possible translation too

Nick Lamb agreed with Sven's point (B). "To contribute effectively as a developer you have to learn English anyway."

Stanislav Brabec didn't agree.

I'm not happy to hear about (B). I have already translated hundreds and hundreds of such string and I don't:

Marc Lehmann replaied that

The question is, where is it trnaslated? You can't translate it in plug-ins, you need to trnaslate it in the programs displaying the strings, e.g. the DB Browser, the PDB Explorer or other tools.

Hmm... I don't think we can make good use of it in 1.2. Maybe it would be best to preserve them for 1.3, when new ideas have a chance to get implemented?

Several other people brought up some points, but most agreed that this will have to wait for 1.3.







Sharon And Joy

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.