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?

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.

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.

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.

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).

Hi!

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??

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 ;)

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

ChangeLog.plugins
plug-ins/maze/*

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...)

NO!!

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.

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.

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.

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 : "
etc.

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.

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.

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

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

• want to trash my work
• The reading is very interesting (and sometimes only reasonable explanation, what plug-in does), that there is good reason to have it translated.

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?