Re: important: automatic mirroring to the gimp cvs
Hi, 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. I liked the whole idea, but I wasn't aware that are you planning to do that before 1.2. If this is absolutely necessary, we might consider branching the plug-ins. But doing so will certainly lead to more problems than it solves. So, if Kevin thinks that Maze has to be worked on before 1.2 is out, he may either send patches or ask for the maze plug-in being removed from the distribution. Salut, Sven
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
PDB_PASS_THROUGH
I can find no evidence that this is actually used anywhere in the GIMP. Anybody know what it's for and whether it even works? Kelly
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: Print plug-in
On Fri, 28 Jan 2000 18:03:32 -0500, Federico Mena Quintero [EMAIL PROTECTED] said: (As for footprint, well, the GIMP is not terribly lightweight either) :-) GIMP's a lot lighter than gnome-libs. I would substantially oppose any serious dependence on gnome-libs in GIMP. Especially since gnome-libs appears to depend on a library that is only available if you have RPM installed. 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: Print plug-in
We might also choose to use the upcoming Gnome Print System if it turns out to fit our needs and appears to be portable to non-Linux systems. As long as it doesn't require actually running Gnome (works with bare X, KDE, etc.) and its footprint is reasonably light, that sounds like a reasonable thing to do. As far as I know no GNOME application requires a running GNOME session, if by such thing you mean running the gnome-session program. If a GNOME program does not run under "bare" X or KDE, then it is broken and should be fixed. Do you have any examples of such programs? (As for footprint, well, the GIMP is not terribly lightweight either) :-) Federico
Re: Print plug-in
Date: Fri, 28 Jan 2000 18:03:32 -0500 From: Federico Mena Quintero [EMAIL PROTECTED] CC: [EMAIL PROTECTED] If a GNOME program does not run under "bare" X or KDE, then it is broken and should be fixed. Do you have any examples of such programs? No; I just wanted to make certain that the GNOME print system wasn't tied to GNOME. (As for footprint, well, the GIMP is not terribly lightweight either) :-) That's true, too :-) The GIMP hammers my system (256 MB DRAM) far harder than GNOME. -- 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] "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton
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
