Re: Plugins at Sourceforge
On Fri, 28 Jan 2000 19:18:53 -0500, Robert L Krawitz <[EMAIL PROTECTED]> said: >And yes, I agree with Michael also that 2002 is not a reasonable >target for the next stable release of the Gimp. Target dates are impossible to stick to. I offered 2002 because it took two years to go from 1.0 to 1.2. :) 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
From: "Michael J. Hammel" <[EMAIL PROTECTED]> Date: Fri, 28 Jan 2000 14:31:15 -0700 (MST) Cc: [EMAIL PROTECTED] (Gimp Developer List) Thus spoke Kelly Lynn Martin > I agree entirely. It is my considered position that the first thing > we should with 1.3 is remove all, or virtually all, of the plug-ins > from the standard distribution. Moving them to the gimp-plug-in > repository on sourceforge seems practical. All we need to do is Agreed, with a modification: a review of plug-ins should be done so that a set of very useful ones could be left with the core. This would permit a useful, small distribution for *nix distributors to include without having to concern themselves about the added extras on sourceforge. It would also allow the core developers to concentrate on architectural issues and let another group of plug-in developers grow (over time) to handle the extras. I agree. I think that the right question is whether a typical end user would consider something to be core functionality vs. an addon. It doesn't really matter how it's implemented; if an end user expects it as a fundamental part of the application, it's core functionality. That doesn't mean that the development of the core plugins has to be centralized; in our case (presuming that printing is considered core functionality) I don't see any harm in our working on our development series, and releasing stable code to the Gimp core. That's essentially what we're doing right now; I intend 3.0.5 as the version to get into 1.2, unless we have bugs that are deemed high enough priority, but 3.1 is under active development. The more interesting question from our standpoint is what happens when Gimp 1.3 gets underway. My intent is to release versions off the 3.1 development tree (or whatever the latest version that at least passes the paper bag test) into the Gimp development, and then sync up our latest stable release when Gimp 1.4 or 2.0 gets close to release. And yes, I agree with Michael also that 2002 is not a reasonable target for the next stable release of the Gimp. -- 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: 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: 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: 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
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: Print plug-in
On Fri, Jan 28, 2000 at 06:03:32PM -0500, Federico Mena Quintero <[EMAIL PROTECTED]> wrote: > > (As for footprint, well, the GIMP is not terribly lightweight either) :-) Well, the main block is probably the considerable number of libraries gnome consists of ;*> I mean, we could create the killer application(*) by using gnome in the gimp ;-> (*) some companies obviously are able to create programs consisting of hundreds of megabytes of code. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Plugins at Sourceforge
Thus spoke Marc Lehmann > Well, most distros tend to compile every optional feature they cna find > into a program. It's already not too difficult to tailor a distribution, > but nobody does that. They do make it moderately easy during installation, but the default installations include lots of things many users will never need. But that's a discussion for another list, I think. :-) > 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. 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. GTK supports internationalization, right? So shouldn't the plug-ins be responsible for the language issues? Otherwise it puts a large burden on Gimp to manage something that is already (supposedly) handled at a lower level (the widget kit). Anyway, I could be way off here. Like I said, I don't know that much about internationalization. Or even if that's what you were referring to! :-) -- Michael J. Hammel |We need somebody who can work The Graphics Muse |independently and innovatively in the [EMAIL PROTECTED] |face of unreasonable demands." http://www.graphics-muse.comJob posting at Stanford CS Department
Re: Plugins at Sourceforge
Thus spoke Kelly Lynn Martin > I agree entirely. It is my considered position that the first thing > we should with 1.3 is remove all, or virtually all, of the plug-ins > from the standard distribution. Moving them to the gimp-plug-in > repository on sourceforge seems practical. All we need to do is Agreed, with a modification: a review of plug-ins should be done so that a set of very useful ones could be left with the core. This would permit a useful, small distribution for *nix distributors to include without having to concern themselves about the added extras on sourceforge. It would also allow the core developers to concentrate on architectural issues and let another group of plug-in developers grow (over time) to handle the extras. > develop a good installer tool before 1.4 rolls, which will probably be > sometime in 2002. Oh geez. I hope not. 1.4 by December. Incremental development, I'm hoping this won't stay an all or nothing process. BTW, I've looked at the Loki installer (setup) and think this would be a terrific base for developing an installer for Gimp. It needs some extensions, some of which I discussed in my article on setup on my web site. But it's easy to use and fairly easy to base a platform independent installation package on it. -- Michael J. Hammel |We need somebody who can work The Graphics Muse |independently and innovatively in the [EMAIL PROTECTED] |face of unreasonable demands." http://www.graphics-muse.comJob posting at Stanford CS Department
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, Jan 28, 2000 at 04:09:55PM -0500, Kelly Lynn Martin <[EMAIL PROTECTED]> wrote: > >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. :) Wel... we are _about_ to do something, yes.. ;) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Plugins at Sourceforge
On Fri, Jan 28, 2000 at 11:55:20AM -0700, "Michael J. Hammel" <[EMAIL PROTECTED]> wrote: > 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 One goal of the seperate cvs is to make the choice between "distribute it" and "leave it out" very easy. I imagine that, before some future release, we can just edit a simple configuration file that specifies which plug-ins are part of the distribution and which aren't. That way removing a plug-in from gimp-2.0 would be a matter of commenting out a line somewhere. > necessarily be included with the core package. Throwing in the kitchen > sink is what's starting to bloat some Linux distros. Well, most distros tend to compile every optional feature they cna find into a program. It's already not too difficult to tailor a distribution, but nobody does that. 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. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: important: automatic mirroring to the gimp cvs
On Fri, 28 Jan 2000 18:49:29 +0100, Marc Lehmann <[EMAIL PROTECTED]> said: >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)? No mirroring at all is my recommendation. Plug-ins should be out of the main branch altogether starting with 1.3. Kelly
Re: Plugins at Sourceforge
On Fri, 28 Jan 2000 11:55:20 -0700 (MST), "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 agree entirely. It is my considered position that the first thing we should with 1.3 is remove all, or virtually all, of the plug-ins from the standard distribution. Moving them to the gimp-plug-in repository on sourceforge seems practical. All we need to do is develop a good installer tool before 1.4 rolls, which will probably be sometime in 2002. Kelly
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: 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: important: automatic mirroring to the gimp cvs
On Fri, Jan 28, 2000 at 10:40:54AM +0100, Sven Neumann <[EMAIL PROTECTED]> wrote: > > 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!! okokok ;-> Just when I thought it would be good ;-> > I liked the whole idea, but I wasn't aware that are you planning to do that > before 1.2 Well, sometimes I'm much slower, sometimes much faster than even I think ;) > If this is absolutely necessary, we might consider branching the > plug-ins. But doing so will certainly lead to more problems than it > solves. 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. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
The Gimp: New Generation
Hi Proposition proposition (despite Gimp freezing): Difficult choice of colour Solution A small colour pick window (the size of palette window) after clicking enlarging 2-3 times with palette as in the drawing ___ | White | | R G B | | Black | +---+ as in brush, palette, pattern in toolbox I mean the magnification It doesn't have to be exact, there is a special tool for that kind of action. [certainly the mouse: left FG-right BG]. It would be very useful because the window of colour choice is 1/3 screen in size when working in 800x600. Check my web site at: http://www.geocities.com/art_pl/gimp/gimp.html It should be easier to understand. 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 /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. Greetings Ar't __ _ _ , | __ | | __ \ |/ |_ _| Artur Polaczynski <[EMAIL PROTECTED]> | __ | | _/ | | <[EMAIL PROTECTED]><[EMAIL PROTECTED]> |_| |_| |_|\_\ |_| #Poland/Warsaw/Mila College#
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
On Fri, 28 Jan 2000 17:29:48 +0100, Marc Lehmann <[EMAIL PROTECTED]> said: >As it is now there is the slight danger that the "self-management" >can cause _more_ work for the maintainers. If Sven has to od a >one-line change in every plug-in he would be force to use two >different cvs servers. Well, hopefully this sort of thing shouldn't have to happen; that would occur because of a noncompatible interface change and I'd like to think we can avoid that. (If the interfance needs to be changed, we should offer a "legacy mode" so unadapted plug-ins continue to function.) 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, Jan 28, 2000 at 04:42:57AM -0500, "Garry R. Osgood" <[EMAIL PROTECTED]> wrote: > Maybe there ought to be a line in PLUGIN_MAINTAINERS indicating > where "authoritative source" resides? I'll put the word "sourceforge" into the COMMENT field of any such plug-ins. Does anybody know of a way to merge two cvs files? CVSup reportedly can do that, but it needs the original *,v files and I have no idea what it does in the face of conflicts. As it is now there is the slight danger that the "self-management" can cause _more_ work for the maintainers. If Sven has to od a one-line change in every plug-in he would be force to use two different cvs servers. However, since the masses haven't cried out yet, I guess we can try and see how it works in practise. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: important: automatic mirroring to the gimp cvs
On Fri, Jan 28, 2000 at 12:20:31AM -0500, Kelly Lynn Martin <[EMAIL PROTECTED]> wrote: > FWIW, I think this should be used sparingly. It is my belief that > we should try to move plugins into a separate package from the GIMP Yeah. I plan to use this only for plug-ins already in the core. > deal. Lots of applications require multiple packages to get > "everything", and GIMP is a _large_ application. 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. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
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
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: 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
