Re: plugins
Hi, Martin Weber [EMAIL PROTECTED] writes: Could we now start and add new plugins to GIMP cvs? No, but we should settle on a system for plug-in development, maintainance and distribution and start to move plug-ins out of gimp CVS soon. Some ideas have come up, but the discussion calmed down a little. Does this mean that you people are working on this ?? Salut, Sven
plugins
Could we now start and add new plugins to GIMP cvs? Martin -- Sent through GMX FreeMail - http://www.gmx.net
Re: [gimp-devel] New Plugins
Tuomas Kuosmanen ([EMAIL PROTECTED]) wrote: Speaking of old stuff to be ported to 1.2.. If I remember correctly, the 0.54 version (yes, kids. It did exist and it ruled.) had antialiased Threshold tool. Hmm - i just compiled gimp 0.54 and did not manage to find *any* threshold function. Can you give me a rough idea, if this is a separate plugin or how to invoke this function? A am considering to create a plugin for this... Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] New Plugins
On Fri, Dec 29, 2000 at 05:48:07PM +0100, thus said Simon Budig: Martin Weber ([EMAIL PROTECTED]) wrote: Now that we have the new gimp 1.2.0 out, we should think about adding new plugins to the gimp. Here my proposal: Speaking of old stuff to be ported to 1.2.. If I remember correctly, the 0.54 version (yes, kids. It did exist and it ruled.) had antialiased Threshold tool. Now it might be a bit backwards as threshold probably shouldnt work like that in the algorithmic sense. But it was _totally_ useful for making masks and stuff (hi Carey :) The current one is pretty limited as the edges will be very blocky and rough.. I wonder what kind of algorighm the old version had? Would it be possible to have a toggle for this? Is it very hard to port? Does anyone have the 0.54 sources anyway? Tuomas BTW. I have PS6 and it is cool. Expect some ideas once I get some free time and have had some time to play with it. -- .--- [EMAIL PROTECTED] .|\,/| [EMAIL PROTECTED] -. + www.helixcode.com - ()-@@ , tigert.gimp.org + `- art director , `--')/ a gimp artist ---'
New Plugins
Now that we have the new gimp 1.2.0 out, we should think about adding new plugins to the gimp. Here my proposal: 1. Stable plugins: Anti-Alias 0.8.1 Fixer Homogenizer logconv-1.2.1 mathmap-0.12 (make seamless in 0.11 works correctly in the Linux version, but in the windows version, the picture turns red) raw_load-3.0 resynthesizer-0.6 2. Unstable plugins gimp-ace: We should take the code from cvs not version 0.6.3. The cvs version removes some problems at light and dark places, but has some problems in the dialog in the gtk part. Also the configure doesn't run with gimp 1.2.0. gimp-freetype-0.2: Still some seg faults. fourier 3. Not yet adopted to the new gimp, but stable in the old version: quant.c from gimp-unstable-plugins from the old 1.0.4. gimp. ipx-plugins kaleidoskope 4. Scripts: lcd-downscale.scm warp-sharp.pl warp-sharp.scm
Re: [gimp-devel] New Plugins
Martin Weber ([EMAIL PROTECTED]) wrote: Now that we have the new gimp 1.2.0 out, we should think about adding new plugins to the gimp. Here my proposal: Basically the number of plugins distributed with the gimp will most probably shrink. We are thinking about a new scheme of distributing plugins. There is no final result of this discussion. 3. Not yet adopted to the new gimp, but stable in the old version: quant.c from gimp-unstable-plugins from the old 1.0.4. gimp. quant used to crash sometimes deeply in the quantizing algorithm where I have no idea of 4. Scripts: lcd-downscale.scm Do you think, this script ios so importand it should be distributed with the Gimp? It has a fairly experimental nature... warp-sharp.pl Is in Gimp 1.2. warp-sharp.scm Do you think it is useful to duplicate the same functionality, just because it is implemented in two different Languages? Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Plugins - what they can and cannot do.
I was recently looking at the possibility of a gimp tile editor. After looking in to it I have found that this is really quite difficult to do with the plugin api. As far as I can see it would be possible but at the user end it would be messy. The plugin would have to create a new canvas, then allow the user to draw on this and then read back from the canvas. (and possibly destroy it). Non editible sections of the image could be protected by being put in a seperate layer. The user could change layers by using a menu on the plugin. My main concern is that there is no way (as far as I know) to prevent the user using the layer menu, to bypass all of this. Is what I am saying making sense? Has anyone else encountered this problem? Thanks David
Re: Plugins - what they can and cannot do.
tile editor? you so you can make seamles tiles? (im guessing here, dont know what you mean by tile editor) maybe just make a plug in that displays the drawable(s) in an offset view. of course you would have to have an update button or poll the image regularly or something silly like that (which is why i never bothered to make this plug in) so what we really need is something for alternate forms of displaying the image, such as offset or hieghtfield (already working on that one, now that i fixed the silly clipping problem but polling and having an update button is how im doing it) or mapped to abritrary shapes... at the least a way for a plug in to know when an image changes... On Fri, 1 Sep 2000, david rohde wrote: I was recently looking at the possibility of a gimp tile editor. After looking in to it I have found that this is really quite difficult to do with the plugin api. As far as I can see it would be possible but at the user end it would be messy. The plugin would have to create a new canvas, then allow the user to draw on this and then read back from the canvas. (and possibly destroy it). Non editible sections of the image could be protected by being put in a seperate layer. The user could change layers by using a menu on the plugin. My main concern is that there is no way (as far as I know) to prevent the user using the layer menu, to bypass all of this. Is what I am saying making sense? Has anyone else encountered this problem? Thanks David
Re: Sample Colorize [Was: Re: Buggy plugins]
On Mon, 7 Feb 2000, Tuomas Kuosmanen wrote: On Sun, Feb 06, 2000 at 07:04:12PM -0500, Garry R. Osgood wrote: [zap] What it does: [zap] So it is basically Gradient Map on steroids? Tuomas I experimented with it a little last night. The thing rocks! -- Jon Winters http://www.obscurasite.com/ OpenVerse http://www.openverse.org/
Re: Sample Colorize [Was: Re: Buggy plugins]
Sven Neumann wrote: Hi, snipped... If you'd ever seen how Karin turns an old b/w photo into a colored one in a few minutes, you would know how good and useful his plug-in really is. (I had the chance to make this joyful experience last year in Berlin, when Karin and Olof presented the printed versiom of the GUM.) Salut, Sven I couldn't agree more - a plug-in that I find just mildly interesting found in the hands of another individual becomes a tool of great power. I trust, when the time comes to winnow plug-ins down to production numbers, the traffic on this mailing list will increase dramatically ;) By the way, Image/Filters/Colors/Map/Sample Colorize... which engendered this small aside has Wolfgang Hofer as author of record (and no one is maintaining it on a regular basis, according to PLUGIN_MAINTAINERS) Were Karin/Olof unsung contributors? Be good, be well Garry Osgood
Re: Sample Colorize [Was: Re: Buggy plugins]
Hi, So it is basically Gradient Map on steroids? The option to use a gradient as colorsource is an extra goodie. The normal usage is colorizing grayscale photos with the use of color photos as color source. Ever tried to colorize human skin using standard techniquees like painting in color mode etc.? Try this with the Sample Colorize plug-in and use a portrait photo as color source. If you created your selection accurately the outcome is just perfect. Salut, Sven
Please Make Bug Reports [Was: Re: Buggy plugins]
Martin Weber wrote: Here a list of buggy plugins in GIMP-1.1.16: snipped... Did you make bug reports of these? (http://www.xach.com/gimp/news/bugreport.html) 1. With 55 days (count'em) to a supposed release date, and lots of issues outstanding, Gimp needs all the resources it can possibly garner from the community. 2. Those of us on the periphery of support have time to lend - but perhaps only single-digit hours per week. 3, Expecting those of us on the periphery of support to go hunting through the mailing list wastes precious time that should go to the Gimp. 4. Mailing list "bug reports" are notorious for being incomplete. The form on the bug report page solicits pertinent information in an orderly manner, enhancing the possibility of a successful diagnosis. If you made bug reports that were not yet posted at http://bugs.gnome.org/db/pa/lgimp.html because of various latencies, then please accept my sincere thanks. Be good, be well Garry Osgood
Re: Buggy plugins
On Sat, 05 Feb 2000 23:50:56 -0800, "Martin Weber" [EMAIL PROTECTED] said: Here a list of buggy plugins in GIMP-1.1.16: tileable blur plugin: the status bar is appearing in an extra window -- color exchange / color mapping plugins: color selection: you can choose a color but black is taken instead -- sample colorize plugin: when starting this plugin you get: Gtk-CRITICAL: file gtkwidget.c: line 3313 (gtk_widget_set_sensitive): assertion 'widget!=NULL' failed. -- max rgb / value invert plugins: the effect is only applied to a small rectangle -- curve bend plugin: no undo possible -- pnm plugin: When I save pbm in GIMP it is not saved as pbm but as pnm. Here's a novel idea: file bug reports, eh? Kelly
Re: Buggy plugins
On Sun, Feb 06, 2000 at 11:41:50AM +0200, Tuomas Kuosmanen [EMAIL PROTECTED] wrote: If I remember correctly the progress window also happens on lot of the save plugins. In theory those all could be in the statusbar if the window has The api for that, however, is quite a hack. If you call the pdb function you get a seperate window (because there is no way to guess the display for you image). If you call the libgimp function gimp second-guesses on you. Since this plug-in is a script-fu (am I right?) a fix requires changes to the script-fu interpreter itself. After 1.2 I will happily introduce another of my break-everything patches that corrects this ;) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Sample Colorize [Was: Re: Buggy plugins]
On Sun, 06 Feb 2000 19:04:12 -0500, "Garry R. Osgood" [EMAIL PROTECTED] said: Personally, I think similiar tricks may be pulled fully in the confines of the Curve tool, but as Marc pointed out, not everyone is a copy of me (or is it 'a copy of Daniel Egger'? I forget ... ;), so some people may find this plug-in to be lots and lots of fun. I've found Sample Colorize to be occasionally interesting, and certainly harmless. It should be an optional plugin post-1.2, but I see no reason not to include it in 1.2 if rendered relatively bug-free. Kelly
Plugins at Sourceforge
In ChangeLog : Fri Jan 28 01:16:35 CET 2000 Marc Lehmann [EMAIL PROTECTED] * PLUGIN_CVS: updated to give Kevin Turner write access to the maze plug-in (therefore, the maze plug-in is no longer managable within the gnome cvs server. If you have any comments/suggestions...) Maybe there ought to be a line in PLUGIN_MAINTAINERS indicating where "authoritative source" resides? Be good, be well Garry Osgood
Re: Plugins at Sourceforge
On Fri, 28 Jan 2000 12:40:32 -0500, Zach Beane - MINT [EMAIL PROTECTED] said: Count this as a cry out against it. I suggest waiting for a logical pause in development, such as the release of GIMP 1.2, to begin making these not-insubstantial changes in source management. My position is sourceforge should be used at this time only for plug-ins which are not already in the source tree. Such plug-ins will not be a part of 1.2 anyway because 1.2 is frozen at this time. When 1.3 development begins, we can decide what to do with the plug-ins currently in the distribution. Kelly
Re: Plugins at Sourceforge
On Fri, 28 Jan 2000, Zach Beane - MINT wrote: On Fri, Jan 28, 2000 at 05:29:48PM +0100, Marc Lehmann wrote: [snip] However, since the masses haven't cried out yet, I guess we can try and see how it works in practise. Count this as a cry out against it. I suggest waiting for a logical pause in development, such as the release of GIMP 1.2, to begin making these not-insubstantial changes in source management. Hear hear. Let's get Gimp 1.2 out the door please, before we start mucking with everything's structure? Keep in mind there are lots of users waiting for a `stable' release before they get all the new nifty functionality that 1.2 has to offer. So get the GIMP 1.2 release out, with the crufty plugins and all, and THEN start making changes like this. for 2.0. --- Even if you can deceive people about a product through misleading statements, sooner or later the product will speak for itself. - Hajime Karatsu
Re: Plugins at Sourceforge
Date: Sat, 5 Feb 2000 12:33:38 -0800 From: "Michael J. Hammel" [EMAIL PROTECTED] I'm curious why any new plug-ins should be added to the core *at all*. Gimp's distribution is fairly large as it is. Isn't it getting time to limit additional plug-ins to the core distribution to plug-ins which are considered "vital" in some way? Even some estoric file plug-ins need not necessarily be included with the core package. Throwing in the kitchen sink is what's starting to bloat some Linux distros. Furthermore, look at it from the standpoint of someone trying to package a Linux distribution (especially vis a vis esoteric file formats and other things that depend upon external software). If our jpeg plugin is part of the core (as an example, I don't want to debate jpeg per se), then installing the gimp requires installing jpeg. If we start forcing a unitary build, then eventually we have everything depending upon everything else, and we get into the Windows mess all over again. It *must* be possible to build and install plugins separate from the Gimp tree. Now, that doesn't mean that anything should change *right now*. It's entirely too close to the release, as many people have pointed out, to change something fundamental even if it means an improvement. It seems to me that right now everyone except people working on advanced development should focus on the release. (And yes, however good Print 3.1 becomes, and even if 3.2 is ready before Gimp 1.2 is, Gimp 1.2 will contain Print 3.0. At some point down the road we might want to put Print 3.2 into a Gimp 1.2 refresh or point release, but that's another matter.) -- Robert Krawitz [EMAIL PROTECTED] http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for The Gimp Print -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton
Re: Plugins at Sourceforge
Michael J. Hammel spontaneously blurts out: I'm curious why any new plug-ins should be added to the core *at all*. Gimp's distribution is fairly large as it is. Isn't it getting time to limit additional plug-ins to the core distribution to plug-ins which are considered "vital" in some way? Even some estoric file plug-ins need not necessarily be included with the core package. Throwing in the kitchen sink is what's starting to bloat some Linux distros. I totally agree! Ideally Gimp should have a connection to some plug-in registry so that needed esoteric (or not so esoteric) plug-ins could be downloaded and installed without restarting gimp. Have the simple plugin's with the distro and then have a series of "power packs" that roughly align with usage domains (i.e. "import powerpack","export powerpack", fine art powerpack", "prepress powerpack", etc). -Dean Johnson Tool Hooligan Cluster Admin Tools Jessie Project Silicon Graphics Inc.Eagan,MN (651) 683-5880 "I am Dyslexic of Borg, Your Ass will be Laminated"-- unknown
Re: Plugins at Sourceforge
On Sat, 5 Feb 2000 12:33:38 -0800, "Michael J. Hammel" [EMAIL PROTECTED] said: I'm curious why any new plug-ins should be added to the core *at all*. Gimp's distribution is fairly large as it is. Isn't it getting time to limit additional plug-ins to the core distribution to plug-ins which are considered "vital" in some way? Even some estoric file plug-ins need not necessarily be included with the core package. Throwing in the kitchen sink is what's starting to bloat some Linux distros. I couldn't concur with you more. I'm radical enough to suggest taking all the plugins out of the standard distribution entirely. :) Kelly
Re: Plugins at Sourceforge
On 1 Feb, Kelly Lynn Martin wrote: additional plug-ins. Some things, like translations, must be part of the distribution currently. This needs to be fixed. :) Do you volunteer? I don't understand translations at all. :) What a pity... I'm currently trying to dissolve all these problems but while I coding some source I stumbled over a problem with gettext which took me nearly a whole to identify. I would really like someone to give me a helping hand on this to reduce the time and of course I would need someone to wake up Ulrich Drepper because I really need his answer :)) -- Servus, Daniel
Re: Plugins at Sourceforge
On 28 Jan, Michael J. Hammel wrote: Do you mean language locales? I'm not very familiar with working with multi-language issues, but I have wondered why this isn't handled by the plug-ins directly. Because it won't work entirely this way... localisation works for everything but the menues which are set up by GIMP at startup time not by the plugins... GTK supports internationalization, right? Errr, let's say: a little bit So shouldn't the plug-ins be responsible for the language issues? Yes, they SHOULD, but it's not possible, at the moment... -- Servus, Daniel
Re: Plugins at Sourceforge
On Mon, 31 Jan 2000 08:57:59 +0100 (CET), [EMAIL PROTECTED] said: additional plug-ins. Some things, like translations, must be part of the distribution currently. This needs to be fixed. :) Do you volunteer? I don't understand translations at all. :) Kelly
Re: Plugins at Sourceforge
Thus spoke Marc Lehmann This is not at all a distribution issue. Linux is a *multi*-user system, so there is not much sense in tailoring the number of installed plug-ins to the needs of, say, the admin. Playing the devils advocate here, you could also say there is not much sense in tailoring it for a multi-user system if many of your users are using it on a single user box. It's a reasonable argument, but there isn't a good answer for it. From my point of view, Gimp is not a multi-user tool (even if it can run happily on multi-user systems) so should be packaged for single users. University admins would probably argue otherwise. Most (but of course not all) of the problems are related to the fact that the menus are too full and can'T be changed, not necessarily that too many plug-ins are installed (which is mostly a diskspace problem). There are some menus that need adjusting to reduce the number of entries. One thing I noticed today is that there are still menus that don't fit well on my 800x600 laptop. Configurable menus is probably the only good long term solution to this sort of problem, however. Similarly, the Palette options for the Indexed Color Conversion dialog doesn't fit in an 800x600 display using the default fonts. There are so many palettes provided in the distribution that a scrolled list is now a better display option here. -- Michael J. Hammel | The Graphics Muse | Women should put pictures of missing husbands [EMAIL PROTECTED] | on beer cans. http://www.graphics-muse.com
Re: Plugins at Sourceforge
On Fri, 28 Jan 2000, Michael J. Hammel wrote: Thus spoke Marc Lehmann This is not at all a distribution issue. Linux is a *multi*-user system, so there is not much sense in tailoring the number of installed plug-ins to the needs of, say, the admin. Playing the devils advocate here, you could also say there is not much sense in tailoring it for a multi-user system if many of your users are using it on a single user box. It's a reasonable argument, but there isn't a good answer for it. From my point of view, Gimp is not a multi-user tool (even if it can run happily on multi-user systems) so should be packaged for single users. University admins would probably argue otherwise. Why yes, admins (like me) generally don't like things that are packaged for single users. I suppose I don't care much about whatever packaging changes are made, as long as I can still install the gimp (and plug-ins, and data, and whatever else) in some system-wide location, and as long as users can still put extra bits and pieces in their .gimp directory. Being an admin lets me see a variety of interesting things, such as the guy who ran gimp for the first time, and chose [Ignore] in the gimp installation dialog, and then told me that gimp didn't work right. Why is ignore an option? It doesn't seem to provide anything other than a quick way to make the gimp not work; unless it has some sort of use, it should probably be taken out. later, Andrew Kieschnick
Re: Plugins at Sourceforge
On Fri, Jan 28, 2000 at 07:14:49PM -0700, "Michael J. Hammel" [EMAIL PROTECTED] wrote: There are some menus that need adjusting to reduce the number of entries. Some menus (like the file type in the file dialog) still are unusable with some font/screen combination since most of it will be outside the screen. So if the menu is too full, it still should be shown someway (e.g. using wrapping like motif, just a bit better maybe). But that's a gtk+ issue, and I use gtk+-1.2, so maybe that problem is nil already. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Plugins at Sourceforge
In ChangeLog : Fri Jan 28 01:16:35 CET 2000 Marc Lehmann [EMAIL PROTECTED] * PLUGIN_CVS: updated to give Kevin Turner write access to the maze plug-in (therefore, the maze plug-in is no longer managable within the gnome cvs server. If you have any comments/suggestions...) Maybe there ought to be a line in PLUGIN_MAINTAINERS indicating where "authoritative source" resides? Be good, be well Garry Osgood
Re: Plugins at Sourceforge
On Fri, Jan 28, 2000 at 05:29:48PM +0100, Marc Lehmann wrote: [snip] However, since the masses haven't cried out yet, I guess we can try and see how it works in practise. Count this as a cry out against it. I suggest waiting for a logical pause in development, such as the release of GIMP 1.2, to begin making these not-insubstantial changes in source management. Zach -- Zachary Beane [EMAIL PROTECTED] PGP mail welcome. http://www.xach.com/pgpkey.txt
Re: Plugins at Sourceforge
On Fri, 28 Jan 2000, Zach Beane - MINT wrote: On Fri, Jan 28, 2000 at 05:29:48PM +0100, Marc Lehmann wrote: [snip] However, since the masses haven't cried out yet, I guess we can try and see how it works in practise. Count this as a cry out against it. I suggest waiting for a logical pause in development, such as the release of GIMP 1.2, to begin making these not-insubstantial changes in source management. Hear hear. Let's get Gimp 1.2 out the door please, before we start mucking with everything's structure? Keep in mind there are lots of users waiting for a `stable' release before they get all the new nifty functionality that 1.2 has to offer. So get the GIMP 1.2 release out, with the crufty plugins and all, and THEN start making changes like this. for 2.0. --- Even if you can deceive people about a product through misleading statements, sooner or later the product will speak for itself. - Hajime Karatsu
Re: Plugins at Sourceforge
On Fri, 28 Jan 2000 21:40:56 +0100, Marc Lehmann [EMAIL PROTECTED] said: One possible reason is that it is a pain in the ass to install additional plug-ins. Some things, like translations, must be part of the distribution currently. This needs to be fixed. :) Kelly
Re: Plugins at Sourceforge
On Fri, 28 Jan 2000 23:47:25 +0100, Marc Lehmann [EMAIL PROTECTED] said: Most (but of course not all) of the problems are related to the fact that the menus are too full and can'T be changed, not necessarily that too many plug-ins are installed (which is mostly a diskspace problem). One of the things I would change is allow the user to specify where in the menu system a plug-in goes, when it is installed. The plug-in would provide a default. (Actually, I have a more progressive concept than this, but it's not fully fleshed out.) Kelly
Re: Plugins at Sourceforge
On Fri, Jan 28, 2000 at 02:36:36PM -0700, "Michael J. Hammel" [EMAIL PROTECTED] wrote: They do make it moderately easy during installation, but the default installations include lots of things many users will never need. But This is not at all a distribution issue. Linux is a *multi*-user system, so there is not much sense in tailoring the number of installed plug-ins to the needs of, say, the admin. Most (but of course not all) of the problems are related to the fact that the menus are too full and can'T be changed, not necessarily that too many plug-ins are installed (which is mostly a diskspace problem). Do you mean language locales? I'm not very familiar with working with multi-language issues, but I have wondered why this isn't handled by the plug-ins directly. Because the plug-ins run in a different process-space from the gimp, but the gimp needs to know translations, and gettetx does not support complex applications like these. GTK supports internationalization, right? Looking at the current state of gimp, I'd say GTK does not really _support_ i18n :( Anyway, I could be way off here. No, you aren't ;) What you said is what _should_ be the case, however, existing packages like gtk+ and gettext do not support the gimp model of distributed programs with shared menus. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Plugins at Sourceforge (fwd)
Thus spoke Zach Beane - MINT On Fri, Jan 28, 2000 at 05:29:48PM +0100, Marc Lehmann wrote: [snip] However, since the masses haven't cried out yet, I guess we can try and see how it works in practise. Count this as a cry out against it. I suggest waiting for a logical pause in development, such as the release of GIMP 1.2, to begin making these not-insubstantial changes in source management. Make that two cries. Ditto the reasoning. -- Michael J. Hammel The Graphics Muse [EMAIL PROTECTED] http://www.graphics-muse.com -- Try again. Fail again. Fail better. -- Thomas Beckett
Re: Plugins at Sourceforge
Thus spoke Kelly Lynn Martin My position is sourceforge should be used at this time only for plug-ins which are not already in the source tree. Such plug-ins will not be a part of 1.2 anyway because 1.2 is frozen at this time. When 1.3 development begins, we can decide what to do with the plug-ins currently in the distribution. I'm curious why any new plug-ins should be added to the core *at all*. Gimp's distribution is fairly large as it is. Isn't it getting time to limit additional plug-ins to the core distribution to plug-ins which are considered "vital" in some way? Even some estoric file plug-ins need not necessarily be included with the core package. Throwing in the kitchen sink is what's starting to bloat some Linux distros. Just a thought. -- Michael J. Hammel The Graphics Muse [EMAIL PROTECTED] http://www.graphics-muse.com -- Try again. Fail again. Fail better. -- Thomas Beckett
Re: perl plugins on AIX...
On Thu, 30 Dec 1999 [EMAIL PROTECTED] wrote: I'm trying (and succeeding!) to build a binary distribution for the Gimp (1.1.14) on AIX 4.3.2. Everything appears to work, except for the perl plugins, which generate a core. "make test" in .../gimp-1.1.14/plug-ins/perl produces: t/load..dubious Test returned status 0 (wstat 139, 0x8b) test program seems to have generated a core Panic's over, I found the problem. I'd added -lgtk to the link phade of UI.so, whereas I should have used -berok to stop the AIX linker complaining about the gtk_init symbol. I've put the resulting binary on the AIX freeware/shareware archive at http://www-frec.bull.com/ Is it normal that when saving an image it only proposes the GIMP (toto.xcf) file format? I thought those plugins would let me save it in any format? Happy new year, Ciaran +-+ Ciaran DeignanTel: (France) 04 76 29 79 92 BULL XS-BU (http://www-frec.bull.com) HA and Consolidation Mail to: [EMAIL PROTECTED]Bullcom: 229 79 92 PGP: B1 78 FB 88 FD 86 58 A8 89 7B 22 8C D0 E8 71 FC Fax: 229 75 18 +-+
(patch) Fixes for different perl plugins in Gimp V1.1.14
Hello,
The attached patch should fix different bugs in different plugins
written in Perl in Gimp V 1.1.14. The patch is mostly an updated
version of the patch I send some weeks ago. The things the patch
should fix:
- In the blowinout, innerbevel, randomblends, terral_text, and
windify plugins the auto import tag was missing.
- In the blowinout and the windify plugins different plugins were
called with 1 for RUN_NONINTERACTIVE.
- In the guidegrid plugin an update of the image was missing. I
inserted a call to gimp_drawable_update.
- Scripts in the logulator plugin which only had the arguments
text_string, font_size_pixels, and font did not get defaults for
this arguments.
- In different Perl-plugins (logulator, xachlego, xachshadow, and
xachvision) the plugins sparkle, nova, and grid were called with a
wrong amount of arguments (or, in the xachshadow plugin, the
arguments were wrong).
- In the ditherize plugin a call to Gimp::set_trace(-1) was done.
- In the frame_filter plugin the default expression could lead to a
call to gauss_rle with a radius1, which is not allowed anymore.
- In the parasite-editor gimp_is_layer was called as
gimp_layer. This PDB-Entry was renamed some time ago.
During fixing this bugs I found some other bugs (this ones are not
fixed by the attached patch):
- In the Parasite Editor every click on Edit results in the error
message "parasite-editor: Callback called exit.(ERROR)".
- Firetext, Bricks, Map To Gradient, §D Outline, Chip Away, Comic
Book, Glossy, and Textured give the error:
"fire: Can't call method "add" on an undefined value at
/usr/lib/perl5/site_perl/5.005/i586-linux/Gimp/UI.pm line 139. (ERROR)"
This plug-ins all use PF_PATTERN or PF_GRADIENT.
- Inner Bevel prints the message
"innerbevel: Can't call method "set_preserve_trans" on an undefined value at
/opt/gimp11//lib/gimp/1.1/plug-ins/innerbevel line 85. (ERROR)"
and continues without problems.
- Pixelmap gives the error:
"pixelmap: dimension mismatch, pdl has dimension 4 but at
/opt/gimp11//lib/gimp/1.1/plug-ins/pixelmap line 43 (ERROR)"
This seems to be a problem with the default expression.
I used Perl versionn 5.005_02 and Gtk-Perl version 0.6123.
Regards,
Frank
diff -ru orig/gimp-1.1.14/plug-ins/perl/examples/blowinout.pl
gimp-1.1.14/plug-ins/perl/examples/blowinout.pl
--- orig/gimp-1.1.14/plug-ins/perl/examples/blowinout.plSat Dec 18 19:34:52
1999
+++ gimp-1.1.14/plug-ins/perl/examples/blowinout.pl Sun Dec 19 23:02:38 1999
@@ -3,7 +3,7 @@
# Blow In/Out
# John Pitney
-use Gimp 1.06;
+use Gimp qw(:auto __ N_);
use Gimp::Fu;
# print "hello there\n";
@@ -44,11 +44,11 @@
$i * $distance / $nsteps * sin($angle * 3.14159 / 180) :
$distance ** ($i/$nsteps) * sin($angle * 3.14159 / 180);
gimp_edit_clear($dmlayer);
-plug_in_noisify(1, $dm, $dmlayer, 0, 255, 255, 255, 0);
+plug_in_noisify($dm, $dmlayer, 0, 255, 255, 255, 0);
gimp_levels($dmlayer, 0, 0, 255, 1.0, 128, 255);
$drawable = gimp_layer_copy($drawable, 0);
gimp_image_add_layer($img, $drawable, -1);
-plug_in_displace(1, $img, $drawable, $xdist, $ydist, 1, 1, $dmlayer,
+plug_in_displace($img, $drawable, $xdist, $ydist, 1, 1, $dmlayer,
$dmlayer, 1);
if ( $inmode == 1 )
{
@@ -62,11 +62,11 @@
$i * $distance / $nsteps * sin($angle * 3.14159 / 180) :
$distance ** ($i/$nsteps) * sin($angle * 3.14159 / 180);
gimp_edit_clear($dmlayer);
-plug_in_noisify(1, $dm, $dmlayer, 0, 255, 255, 255, 0);
+plug_in_noisify($dm, $dmlayer, 0, 255, 255, 255, 0);
gimp_levels($dmlayer, 0, 0, 255, 1.0, 128, 255);
$drawable = gimp_layer_copy($drawable, 0);
gimp_image_add_layer($img, $drawable, -1);
-plug_in_displace(1, $img, $drawable, $xdist, $ydist, 1, 1, $dmlayer,
+plug_in_displace($img, $drawable, $xdist, $ydist, 1, 1, $dmlayer,
$dmlayer, 1);
if ( $inmode == 1 )
{
diff -ru orig/gimp-1.1.14/plug-ins/perl/examples/ditherize.pl
gimp-1.1.14/plug-ins/perl/examples/ditherize.pl
--- orig/gimp-1.1.14/plug-ins/perl/examples/ditherize.plSat Dec 18 19:34:52
1999
+++ gimp-1.1.14/plug-ins/perl/examples/ditherize.pl Sun Dec 19 21:28:53 1999
@@ -37,7 +37,7 @@
sub {
my($image,$drawable,$dither,$colours)=@_;
- Gimp::set_trace(-1);
+# Gimp::set_trace(-1);
$drawable-is_layer or die "this plug-in only works for layers";
diff -ru orig/gimp-1.1.14/plug-ins/perl/examples/frame_filter
gimp-1.1.14/plug-ins/perl/examples/frame_filter
--- orig/gimp-1.1.14/plug-ins/perl/examples/frame_filterSat Dec 18 19:34:52
1999
+++ gimp-1.1.14/plug-ins/perl/examples/frame_filter Mon Dec 20 21:02:57 1999
@@ -13,7 +13,7 @@
"*",
Re: Plugins
On 8 Nov, Marc Lehmann wrote: Hint: It's the way menues are handled by Gtk... And if this leads to segfaults it is surely a bug in gkt+? No, really, I am _simply_ interested in how a call to gettext can result in a "legal" segfault. The most likely way to cause a segfault is to write to an address not owned by the process... In C this is very easily because we sometimes even calculate with pointers... Well, if you care that I won´t repeat the same error again it would be nice if you explained the bug... Got me here, but since I don't exactly know what the bug is I can hardly explain it. I just know the symptoms and you do, too... I don't think so. Half-translations can be really confusing and annoying for a user. Ok, then let's vote on this. "I vote that this is less confusing..." Do so, but at a public place, please... Push me, please... PUSH! Not hard enough, but this may change VERY soon "ls" is ls(1) and "vz" is the shortcut for "verzeichnis". Ouch mixed language environments are the rule today, not the exception. That doesn't make them any better I think it's the only way to go. Look at how M$ handles translation (by looking at i18n'ed visual basic for example ;) ROTFL. Did you have a look how M$ does internationalisation? Have you ever seen a catalog for any Microsoft program? No? Maybe it's their special art of doing Cut'n'Paste... :)) Well, I have an opinion about half-trabslation that is just as good as any opinion from an average user. The gimp is not the only i18n'ed project, and I didn't speak english all the time in the past... Well, for distributors internationalisation is a very big concern because they address firms (which don't care about it very much) on the one hand but on the other hand also users who want a stable OS with many free programs and they DO care about. -- Servus, Daniel
Re: Plugins
On 10 Nov, Marc Lehmann wrote: That all plug-ins that are part of the distribution should have corretc translated menu entries is (for me) obvious. The problem is new (third-party) plug-ins. These problems are solvable by a consistent way to handle the translations. Im working on these but I guess I'll have to sleep until the release of Gimp 1.2 ... In this area we have too much changes to allow me to start coding now for Gimp 1.3... A way around would be to increase the version number to something like 1.1.95 to show that we are on the right way and get a big bug fixing push :)) -- Servus, Daniel
Re: Plugins
You wrote on Mon, 08 Nov 1999: Would it still be a problem for you if only the menu entry itself is english, but the english menu is sorted under the corresponding german standard menu (see above for "Add Selection")? Oh, it's not for me ;-) I think about all the "only" users. I use gimp in english and are satisfied (so I am searching for ways to make my system better). I think of it pragmatically: If there are no two (or more) menus with the same name (but in different languages) it is not really bad. It is not nice though! Think of it as a little gift just around the corner: "The whole gimp is in english. I understand it but I would prefer german. Oh, here in File are all entries translated -- very good." So what I wanna say: All that makes two menus of the same manner disappear is a bugfix. The other things like improvement of the i18n-Code to make it consistent and in toto able to translate all messages is the right thing todo after 1.2! Just my 0.2 Euro Uwe Koloska -- mailto:[EMAIL PROTECTED] http://rcswww.urz.tu-dresden.de/~koloska/ ---- right now the web page is in german only but this will change as time goes by ;-)
Re: Plugins
Hi Marc, Marc Lehmann wrote: On Wed, Nov 03, 1999 at 10:20:37AM +0100, Michael Natterer [EMAIL PROTECTED] wrote: I was (or at least tried to be) very careful not to change any external interface (which I suppose you mean by "cause other changes as well") with the context changes because playing around with the PDB interface in freeze mode looks dangerous to me... I'm sorry... do you really say that you won't implement the context stuff fully for 1.2? I had always thought that the work would be finished before 1.2 I'm not really sure what you mean. The internal stuff is now done only by the context and finished. There are still some (uncritical) things to be done, but that's bugfixing. Do you want to use context functions at the pdb interface? (ie writing stuff like gimp_context_get_brush(NULL)) and put all current color/brush/... access functions to gimpcompat.[ch] or just let all clients run in their own context (which could be done internally without changing the interface) I considered bringing the context to the pdb as a feature for 1.4 (also because I was away from my machine for months when the gimp was frozen :( ) So please let me know if you find the semantics of any PDB brush/color/pattern/gradient function changed and I'll restore the old semantics. I don't expect them to be changed yet. I would have appreciated this very much, this would probably result in much less work on my side (no backward-compatibility crap). If you are about to break the pdb interface we should do it now, not later. Doing it later is just awkward, resulting in more work from many others (update it to 1.2, and then to 1.3 again. Doing the major work once would be much better). Currently I don't plan to break the pdb interface because now the whole stuff is in a sane state. It would be a major api change that will need lots of debugging and I'm not sure if there's enough time until the new release in god-knows-how-many-months ;-) However, putting additional stuff to the context (like the error message as you proposed) wouldn't be too much work. Please let me know what your plans are. bye, --Mitch
Re: Plugins
On Tue, Nov 09, 1999 at 11:07:32AM +0100, Uwe Koloska [EMAIL PROTECTED] wrote: So what I wanna say: All that makes two menus of the same manner disappear is a bugfix. The other things like improvement of the i18n-Code to make it consistent and in toto able to translate all messages is the right thing todo after 1.2! The problem is not fixable by mere developer effort. It also has to work (somewhat) with plug-ins "we" have no control over. That all plug-ins that are part of the distribution should have corretc translated menu entries is (for me) obvious. The problem is new (third-party) plug-ins. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Plugins
On Wed, Nov 03, 1999 at 11:07:32AM +0100, Uwe Koloska [EMAIL PROTECTED] wrote: I don't know anything about the actual CVS-release but with 1.1.10 I have to disable nls-support, because there are so many doubled menus (some german, some english). Maybe it's because I'm using a libc5 based system but I think there are many systems out there with similar problems. Strange that I don't encounter this problem (that sever), maybe the version we used for the booth at the Systems '99 had a much better german translation? In any case, this problem is a totally seperate issue (as I talked about with Daniel). A solution (workaround, fix...) would be to do it like perl, i.e. translate by component unless there is a better translation. E.g. Toolbox/Xtns/Animation/Seth Spin = Toolbox/Xtn/Animation/Seth's Dreher (translation available) Toolbox/File/Selection/Add Selection = Toolbox/Datei/Auswahl/Add Selection (only a partila translation for File/Selection available) This would solve your problem for the vast majority of untranslated (E.g. third-party) plug-ins. Well, what I understand about half-translated plug-ins is, that if the binding for the inclusion in menus and so on is fully translated and the rest isn't that isn't bad, but if some menu entries are and others not is very bad. Would it still be a problem for you if only the menu entry itself is english, but the english menu is sorted under the corresponding german standard menu (see above for "Add Selection")? -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Plugins
On Sun, Nov 07, 1999 at 08:39:51PM +0100, [EMAIL PROTECTED] wrote: This sounds interesting (explain!).. how can i18n lead to segfaults? Not again Marc, we have had this discussion before You told me that all my menus would be shown twice (which was a problem on your machine only). Hint: It's the way menues are handled by Gtk... And if this leads to segfaults it is surely a bug in gkt+? No, really, I am _simply_ interested in how a call to gettext can result in a "legal" segfault. But since its purely for my own pleasure you don't have to explain... (I am serious, btw!) Me included! Maybe I shouldn´t even reply here.. ;- Maybe :) Well, if you care that I won´t repeat the same error again it would be nice if you explained the bug... I don't think so. Half-translations can be really confusing and annoying for a user. Ok, then let's vote on this. "I vote that this is less confusing..." Maybe we should just push the translators a bit for the release (unless code changes are necessary).. Push me, please... PUSH! Half-translated plug-ins are definitely no reason to forget it!! I mean, do you want to translate "ls" to "vz" with LANG=de? I don't understand your intention here... what should "ls" and "vz" be? "ls" is ls(1) and "vz" is the shortcut for "verzeichnis". mixed language environments are the rule today, not the exception. That doesn't make them any better I think it's the only way to go. Look at how M$ handles translation (by looking at i18n'ed visual basic for example ;) I don`t mind it either.. I know, but you aren't supposed to be the average user, are you? Well, I have an opinion about half-trabslation that is just as good as any opinion from an average user. The gimp is not the only i18n'ed project, and I didn't speak english all the time in the past... -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Plugins
On Wed, Nov 03, 1999 at 10:20:37AM +0100, Michael Natterer [EMAIL PROTECTED] wrote: I was (or at least tried to be) very careful not to change any external interface (which I suppose you mean by "cause other changes as well") with the context changes because playing around with the PDB interface in freeze mode looks dangerous to me... I'm sorry... do you really say that you won't implement the context stuff fully for 1.2? I had always thought that the work would be finished before 1.2 So please let me know if you find the semantics of any PDB brush/color/pattern/gradient function changed and I'll restore the old semantics. I don't expect them to be changed yet. I would have appreciated this very much, this would probably result in much less work on my side (no backward-compatibility crap). If you are about to break the pdb interface we should do it now, not later. Doing it later is just awkward, resulting in more work from many others (update it to 1.2, and then to 1.3 again. Doing the major work once would be much better). BTW: I appreciated both new features a lot! :-) But AFAICS, there is only one new feature... -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Plugins
On 3 Nov, Marc Lehmann wrote: This sounds interesting (explain!).. how can i18n lead to segfaults? Not again Marc, we have had this discussion before Hint: It's the way menues are handled by Gtk... Me included! Maybe I shouldn´t even reply here.. ;- Maybe :) Well, half-translated is surely better than not translated at all, so this is IMHO no reason to switch it of totally. I don't think so. Half-translations can be really confusing and annoying for a user. Maybe we should just push the translators a bit for the release (unless code changes are necessary).. Push me, please... Half-translated plug-ins are definitely no reason to forget it!! I mean, do you want to translate "ls" to "vz" with LANG=de? I don't understand your intention here... what should "ls" and "vz" be? mixed language environments are the rule today, not the exception. That doesn't make them any better I don`t mind it either.. I know, but you aren't supposed to be the average user, are you? -- Servus, Daniel
Re: Plugins
On 3 Nov, Michael Natterer wrote: Just because I didn't write for many files "using the context here fixes a bug" doesn't mean it didn't. E.g. the device status dialog was totally unusable after a "refresh" and ensuring it's consistency without the context would have needed another weird function to be called from outside. IMHO waiting for context signals and self-updating is much cleaner and less dangerous than the old paradigm and making the ui always sync with the internal state _is_ a bugfix. Many changes can be expressed to be bugfixes, but somewhere we have to stop introducing new features and bugs... -- Servus, Daniel
Re: Plugins
[EMAIL PROTECTED] wrote: Note: At the moment featurefreeze is more violated by the changes done by for example Michael than by the ideas I'm having which would be something like "little changes with big positive effects"... You mean the context and dnd stuff... Well, as Olof has already pointed out, we announced that there are checkins to come and nobody objected. When starting to add the posibility to store brush/pattern/... in the context, I even put the question to the ChangeLog. The actual big checkin where I changed all brush/pattern/... access functions was 9 days later and I didn't get any mail in the meantime. Just because I didn't write for many files "using the context here fixes a bug" doesn't mean it didn't. E.g. the device status dialog was totally unusable after a "refresh" and ensuring it's consistency without the context would have needed another weird function to be called from outside. IMHO waiting for context signals and self-updating is much cleaner and less dangerous than the old paradigm and making the ui always sync with the internal state _is_ a bugfix. bye, --Mitch
Re: Plugins
Marc Lehmann wrote: Note: At the moment featurefreeze is more violated by the changes done by for example Michael Or Sven! Even worse, Sven's changes required me to add something else (which is not bad, but it introduced instabilities again), and Michaels changes are very likely to cuase other changes as well... So I'd really say: either we feature freeze or we forget 1.2 I was (or at least tried to be) very careful not to change any external interface (which I suppose you mean by "cause other changes as well") with the context changes because playing around with the PDB interface in freeze mode looks dangerous to me... So please let me know if you find the semantics of any PDB brush/color/pattern/gradient function changed and I'll restore the old semantics. BTW: I appreciated both new features a lot! :-) ciao, --Mitch
Re: Plugins
On 3 Nov, Michael Natterer wrote: Note: At the moment featurefreeze is more violated by the changes done by for example Michael than by the ideas I'm having which would be something like "little changes with big positive effects"... Just because I didn't write for many files "using the context here fixes a bug" doesn't mean it didn't. E.g. the device status dialog was totally unusable after a "refresh" and ensuring it's consistency without the context would have needed another weird function to be called from outside. IMHO waiting for context signals and self-updating is much cleaner and less dangerous than the old paradigm and making the ui always sync with the internal state _is_ a bugfix. I just said that my ideas wouldn't really introduce new features but just be a kind of cleanup -- Servus, Daniel
Re: Plugins
On Fri, Oct 29, 1999 at 11:46:30PM +0200, [EMAIL PROTECTED] wrote: Should we leave the plug-ins as they are know or bugfix them i18n-wise? Real design bugs can´t be solved for 1.2, so either we can do it painlessly or we can´t do it (in 1.2). bugfixing way... Otherwise I would suggest du disable i18n for plug-ins which on the other hand is a bad solution because localisation is a I´m not sure LANG=de works extraordinarily good for me... no extra menus or other problems anymore, so I think we should only disable the languages that don´t work. On the GIMP booth at the Systems we have had some really nice discussions about this, also with firms which use GIMP for web publishing. Just Yes ;- But these ideas were mostly aimed at 1.3, no? Or do we plan to revamp the registry, the i18n system c before 1.2? no.. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Plugins
On 29 Oct, David Monniaux wrote: I agree with Daniel. I18N maintainers already have too much to do. Frankly, I think we should try to ship 1.2 before changing how plug-ins are handled. It would be really helpful to know the thoughts of other developers or even or great maintainer to this topic... Should we leave the plug-ins as they are know or bugfix them i18n-wise? I do have a proposal on my Palm which would provide an idea for the bugfixing way... Otherwise I would suggest du disable i18n for plug-ins which on the other hand is a bad solution because localisation is a "MUST BE" (tm) for any real work with GIMP outside English spoken countries On the GIMP booth at the Systems we have had some really nice discussions about this, also with firms which use GIMP for web publishing. Just tell me if you want to know more about this -- Servus, Daniel
Re: Plugins
installing this package, the user would customize the gimp for his special needs by adding special functionality For example this would like: gimp-plugins-artistic (gimppressionist, mosaic, oilify, ...) gimp-plugins-webdesign (imagemap, html, animoptimize, ...) gimp-plugins-render-fractal (fractal-explorer, cml_explorer, ) gimp-plugins-fileformats(fits, sunras, ...) gimp-plugins-perl (you get the point) This is just like the cpan bundle system, btw. I suggest we _really_ should look at a comparable database like cpan before starting our own hacks. registry, mirror it and include a nice tool that allows users to download and install plug-ins when the need arises. Of course this would have to be possible from within a running gimp and since I'm not sure if this would work at all, this is possibly only a solution for 2.0. That would require re-scanning the plug-ins, which is a viable thing, but also sounds like a new feature (i.e. a 2.0 feature). But if we drop that restriction, i.e. by requiring a restart and using a seperate tool (i.e. super-gimptool), the work to implement this shouldn't be that large. For example we could copy the cpan logic of downloading and unpacking the plug-ins portably. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Plugins
On Mon, Oct 18, 1999 at 10:04:35AM -0500, Kelly Lynn Martin [EMAIL PROTECTED] wrote: is definitely more useful for the average gimp user than gap or mosaic (although these are highly useful to some). IMO, something akin to Perl's CPAN module would be a good idea for GIMP plugins. Don't look at me to write it, though I volunteer, if I am allowed to use perl ;) However, this is an interesting idea indeed. all we needed would be to ensure some rules on how to create CGAN-able (comprehensive gimp archival network) plug-ins, i.e. plug-ins that can be installed with no (or with little) user interaction. BnP comes to mind, which was created to do this.. there are already BnP scripts that download all of gimp (including any third party libraries), build and install it... -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Plugins
plug-ins that don't compile or don't survive beta tests just wouldn't be distributed (or the plug-in cvs would become a seperate tarball, which IMHO is not useful, though). What do we do for i18n? Today, there are two translation files: gimp - core gimp-std-plugins - plugins shipped with Gimp Just as we do now.. no changes are necessary. Just that we change how the plug-ins are stored (cvs) does not necessarily change the way they are distributed. And a few extra messages in gimp-std-plug-ins for plug-ins we do not ship because they are unstable don't mind. The i18n issue isn't where the plug-ins are shipped. The issue for plug-ins that are not part of the gimp-std-plugins distribution is the organization of the translation effort (if there is to be one at all). What is needed is a place where programmers can put their plug-ins (and their associated *.po files) and where translators, who are presumably different people from the programmers, can look to find translations that need doing. Without this, the translation effort cannot be extended to submitted plug-ins in a general way. -tom --- tomss at ids.net - 401-861-2831
Re: Plugins
On Mon, Oct 18, 1999 at 11:53:09AM -0400, [EMAIL PROTECTED] wrote: organization of the translation effort (if there is to be one at all). What is needed is a place where programmers can put their plug-ins (and their associated *.po files) and where translators, who are presumably different people from the programmers, can look to find translations that need doing. Without this, the translation effort cannot be extended to submitted plug-ins in a general way. I don't understand - how does the current situation (different dirs for plug-in and gimp i18n) differ from having the plug-ins in a different cvs tree? Wether we create a tarball from one or from two cvs trees is just a matter of some script-hacking, but it does not affect the final tarball. Except that we might have a better link with the plug-in maintainers and gimp.. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
