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
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: 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
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
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
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
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, 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 (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
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 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
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 28 Jan, Kelly Lynn Martin 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. :) Do you volunteer? -- Servus, Daniel
Re: Plugins at Sourceforge
> > This is not at all a distribution issue. Linux is a *multi*-user system, so > > 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. Whatever, we need a good tool to install other plug-ins later, both for the admin and the single-user case (like CPAN), since the "most interesting plug-ins" (for some user) will not be delivered with the gimp anyway. This will be done, no doubt, after 1.2, and the better it works, the less plug-ins do we have to deliver with the core distribution. We just have to train distribution people to deliver the full plug-ins archive on their cd's (yes, some people still have no internet!), and maybe we could provide a working binary kit. After reading that article about innovative free software and non-innovative gui design, I begin to think that gimp is more prone to be end-user software than, say, gcc ;) (OTOH, I think the gimp GUI is quite innovative: being innovative in GUI design usually lowers the usability index a lot). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
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 | |
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
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 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: 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
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: 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: 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: Plugins
On Sat, Nov 13, 1999 at 03:50:47PM +0100, Michael Natterer <[EMAIL PROTECTED]> wrote: > Hm, I don't exactly know how the plug-in stuff works but there surely > is a pipe to each client and the gimp (or gtk) does a select() at some > place to wait for the pipes' file descriptors. Many clients can share a pipe, so there should be a way to set a new context. Otherwise the problem I want this context stuff for is still not solved, namely multiple clients connecting to the gimp. And how does the application change between setting it's own context vs. setting the gui context? I cannot see how this can be done without an explicit PDB interface for this. > But as I said, I'm not 100% sure if this asumptions are true... are they? most plug-ins do not share a pipe. but many plug-ins (and most script-fu scripts) would need a way to set either context. > ...also true, but I'm not yet sure (see above) how to do it and if it can > be done without breaking too much... you're more a plug-in expert than > I am, any idea where to do this context switching?? In the core, we have to find out _who_ is calling an internal pdb function (or an external plug-in), and use the appropriate context during the execution. Every plug-in should get a copy-on-write-like context, and the option to modify the parent context (or the gui context, but the latter is not important at this point, as it is clearly a new feature). You also need a way to copy/set the context, for clients sharing a pipe. The default for 1.2 could be to modify the parent context anyway (but I think that only a small minority of scripts require changes to colours/brushes etc. to be backpropagated, so these could probably be fixed) > Yep, this sounds better ;-) But do we really need pdb context functions > for 1.2 if internal context switching (depending on the plug-ins' file > descriptors) is possible? No (if!). But even if not we could not just decide not to fix the (non-fatal for normal usage) bug. It is still easy to confuse the gimp by calling normal plug-ins, even with the context stuff. > Maybe just a stripped down context interface (allowing e.g. > the client to say if it wants a private context or not) How about always having a provate context? Which plug-ins require that their changes to the context are global? Most only set colours etc. for their internal use, and backpropagating thes evalues is usually NOT wanted, but unavoidable. > uh, I guess this mail has too much "if"s... If we could get some pdb functionality, we could even fix the big annoyancies for script-users. And little annoyances for ui-users (ui users are already aware that hell breaks loose when they try to call more than one plug-in at a time). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Plugins
Hi Marc, Marc Lehmann wrote: > > On Tue, Nov 09, 1999 at 05:14:07PM +0100, Michael Natterer ><[EMAIL PROTECTED]> wrote: > > 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) > > The latter one (as a start). However I can't see how the gimp can guess > what context my application is in automatically, so there must be a set of > functions to handle the current context. Hm, I don't exactly know how the plug-in stuff works but there surely is a pipe to each client and the gimp (or gtk) does a select() at some place to wait for the pipes' file descriptors. As the gimp app does all manipulating stuff synchronously, we could just switch to the client's context whenever it wants to do something and switch back to the user context when the job is done. But as I said, I'm not 100% sure if this asumptions are true... are they? > > 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 :( ) > > Well, for me it is a new feature in the feature freeze that is only > half-finished ;) It does not solve any of the problems we currently have. > > For example you can easily crash the gimp by running multiple plug-ins at the > same time (no, gimp is _not_ able to do more than one plug-in at the time). Very true. My intention was to fix the ui inconsistencies caused by the old brush/pattern/... handling functions. This should be fixed now... > So, maybe, implementing the rest may even be considered a bugfix ...also true, but I'm not yet sure (see above) how to do it and if it can be done without breaking too much... you're more a plug-in expert than I am, any idea where to do this context switching?? > > Currently I don't plan to break the pdb interface because now the whole > > stuff is in a sane state. > > Why break? I thought about just extending the interface for the new > functionality (contexts). Yep, this sounds better ;-) But do we really need pdb context functions for 1.2 if internal context switching (depending on the plug-ins' file descriptors) is possible? Maybe just a stripped down context interface (allowing e.g. the client to say if it wants a private context or not) uh, I guess this mail has too much "if"s... bye, --Mitch
Re: Plugins
On Thu, Nov 11, 1999 at 08:34:59PM +0100, [EMAIL PROTECTED] wrote: > > 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... You told me that, but I neither buy your explanation nor do I experience this bug myself. > > Ok, then let's vote on this. "I vote that this is less confusing..." > Do so, but at a public place, please... I just did this, didn't I?? > 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. But this is still no argument on why everything must be translated... -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
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
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 Tue, Nov 09, 1999 at 05:14:07PM +0100, Michael Natterer <[EMAIL PROTECTED]> wrote: > 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) The latter one (as a start). However I can't see how the gimp can guess what context my application is in automatically, so there must be a set of functions to handle the current context. > 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 :( ) Well, for me it is a new feature in the feature freeze that is only half-finished ;) It does not solve any of the problems we currently have. For example you can easily crash the gimp by running multiple plug-ins at the same time (no, gimp is _not_ able to do more than one plug-in at the time). So, maybe, implementing the rest may even be considered a bugfix ... But it's eventually your decision. > Currently I don't plan to break the pdb interface because now the whole > stuff is in a sane state. Why break? I thought about just extending the interface for the new functionality (contexts). > 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 ;-) Then don't change the api! > However, putting additional stuff to the context (like the error message > as you proposed) wouldn't be too much work. But that's the least important thing. Getting working error reporting into gimp is definitely an 1.4 feature (for me). Making gimp work in the already advertised but not implemented "gimp can multitask" case is what I thought the context stuff would do... > Please let me know what your plans are. I don't have plans, just expectations ;-> -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
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
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
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
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 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 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. /Xtns/Animation/Seth Spin => /Xtn/Animation/Seth's Dreher (translation available) /File/Selection/Add Selection => /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 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
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: >> 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
Marc Lehmann wrote on Mit, 03 Nov 1999: >On Tue, Nov 02, 1999 at 03:07:49PM +0100, [EMAIL PROTECTED] wrote: >> >> And I can't think of something more bad than halfdone things... we even >> have Plug-ins which are half-translated... nice feature, right? > >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 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. 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. >> Fix it or forget it and fixing it needs some more hours to be put > >Half-translated plug-ins are definitely no reason to forget it!! I mean, do >you want to translate "ls" to "vz" with LANG=de? mixed language environments >are the rule today, not the exception. > see above. Yours 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
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
[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
On Tue, Nov 02, 1999 at 03:07:49PM +0100, [EMAIL PROTECTED] wrote: > At the moment the localisation of plug-ins is really buggy. Of course > it works flawlessly if you just use LANG=de to test the German menus, but > running it a bit longer causes segfaults which are definitely caused by > bad hacks which "localize" Plug-ins... most developers unfortunately don't This sounds interesting (explain!).. how can i18n lead to segfaults? > have quite a clue of what's going on in this area Me included! Maybe I shouldn´t even reply here.. ;-> > And I can't think of something more bad than halfdone things... we even > have Plug-ins which are half-translated... nice feature, right? Well, half-translated is surely better than not translated at all, so this is IMHO no reason to switch it of totally. Maybe we should just push the translators a bit for the release (unless code changes are necessary).. > Fix it or forget it and fixing it needs some more hours to be put Half-translated plug-ins are definitely no reason to forget it!! I mean, do you want to translate "ls" to "vz" with LANG=de? mixed language environments are the rule today, not the exception. > a few people who really use GIMP for earning some money and they'd > really enjoy a great translation of GIMP into German and possibly would > be really grateful for some work here... I don`t mind it either.. > 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 BTW: I appreciated both new features a lot! > than by the ideas I'm having which would be something like "little > changes with big positive effects"... So..? ;) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Plugins
On 30 Oct, Marc Lehmann wrote: > 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). Of course > 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. At the moment the localisation of plug-ins is really buggy. Of course it works flawlessly if you just use LANG=de to test the German menus, but running it a bit longer causes segfaults which are definitely caused by bad hacks which "localize" Plug-ins... most developers unfortunately don't have quite a clue of what's going on in this area And I can't think of something more bad than halfdone things... we even have Plug-ins which are half-translated... nice feature, right? Fix it or forget it and fixing it needs some more hours to be put in > Yes ;-> But these ideas were mostly aimed at 1.3, no? I didn't mean our discussion but the talks between my person and a few people who really use GIMP for earning some money and they'd really enjoy a great translation of GIMP into German and possibly would be really grateful for some work here... > Or do we plan to revamp the registry, the i18n system &c before 1.2? > no.. I really don't know what WE want... I want a bug free GIMP for release and that's definitely some days away, even more if we want to keep i18n for plug-ins... 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"... -- 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
On Fri, 29 Oct 1999 [EMAIL PROTECTED] wrote: > I could continue this list... In this sector a lot work has to be 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. Already plug-ins are a pain in the ass. Half of the authors can't be reached. Some messages are cryptic jokes. Some messages marked for I18N are internal error messages that are meaningless to end users. Etc... Don't increase our workload with some half-thought attempt at rationalizing plugins. We shall have time to set this up AFTER 1.2 ships. --- David Monniaux Tel: +33 1 44 32 20 66Fax: +33 1 44 32 20 80 Laboratoire d'informatique de l'École Normale Supérieure, 45 rue d'Ulm - 75230 PARIS cedex 5 - FRANCE
Re: Plugins
On 22 Oct, Sven Neumann wrote: > I don't think that internationalisation is our major problem with > plug-ins right now. This doesn't mean that we shouldn't think about > it now, but our main problem is the mass of plug-ins shipped with the > Gimp. It is and there a quite a couple of reasons why: - Extracting messages from files distributed over a lot of directories is just broken... - Plug-ins are usaing the localising features themselves very badly -> broken - Different plug-ins may want to different different translations for the same message, impossible now -> broken - External plug-ins can't get a translation very easily -> broken I could continue this list... In this sector a lot work has to be done... any volunteers? Otherwise the only right way for Gimp 1.2 would be to ship it wihtout localisation support for plug-ins And please don't think that I will do this work, although I'm very active in this area... creating some hundred patches isn't something I like to do in my spare time... -- Servus, Daniel
Re: Plugins
On Tue, Oct 19, 1999 at 09:55:57AM -0400, "Shawn P. Wallace" <[EMAIL PROTECTED]> wrote: > > > > Of course, a simple gimptool wrapper plus some archiving database (the > > registry!) might suffice. > > > > It doesn't seem as if Gimp development has the critical mass (read: > sheer number of module developers) that Perl has. Well, I'd say installing one hundred plug-ins via gimptool, Makefile tweaking and worse has the critical mass to require something like cpan to install modules. > expansion/tweaking of the registry would suffice for now, but perhaps we > should be thinking of the NG Plug-in Registry, which should probably be > modelled on CTAN/CPAN. I'm fine with the current _storage_ model (files in the registry), I'm looking for an easy way to install additional plugins. However, what we should think of in _any_ case is a revision of a "what is a plug-in" on the registry. I'd say either: - a single .c file (with absolutely NO portability requirements whatsoever), [deprecated ;)] - a .tar.gz, which includes source, a Makefile.am and configure.in. If either of these is missing, some standard way to regenerate these (i.e. write a standard configure.in and Makefile.am for that case). This allows us to package .po files &similar to the plug-in. - a xxx-architecture.tar.gz (or .zip), containing a precompiled version for a specific os (e.g. somethine like redhat-6-x86, aix-4.1, suse-6.2-axp etc..) that would allow us to support the most common targets with ~99% success rate without user intervention. (we could copy CPAN's proposed standard for binary modules here) Having a wrapper (like the cpan shell) would also allow us to retro-fit extensions like better i18n for plug-ins (like storing and merging po files on installation) independent of the module authors or users. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
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
Sven Neumann <[EMAIL PROTECTED]> writes: > Hi, > > > my EUR 0.02 to the plug-in discussion > > [stuff deleted] > > (3) Let's test all those plug-ins heavily and drop everything that is not > stable or usable into gimp-plugins-unstable. Do the same thing with what is > called gimp-plugins-unstable now and move all plugins that seem to be stable > and usable up into the main distribution. Then start the menu discussion all > over (we had one before 1.0 was released) and find a better way to put all > those plug-ins into suitable menu positions. This is IMHO the first necessary thing to do. I assume that the amount of plugins we talk about here will be reduced by this operation so much that we don't have to think about anything further for some time... jtl
Re: Plugins
Hi, my EUR 0.02 to the plug-in discussion I don't think that internationalisation is our major problem with plug-ins right now. This doesn't mean that we shouldn't think about it now, but our main problem is the mass of plug-ins shipped with the Gimp. The Filters menu is IMHO overcrowded. Even a redesign can't solve the fact that it is really difficult to find the plug-in you need and most users will only need a small subset of the included plugins. On the other hand there quite a few nice plug-ins that are definitely worth to be included (if we go along with our current philosophy to include each and every plug-in that could come in handy). Antialias is one of those candidates just to bring up an example. One strength of Gimp definitely is that it comes with a huge amount of filters and file-formats by default. But with the amount of plug-ins growing constantly, we should IMHO discuss if we can continue like that. I have for myself included a whole bunch of plug-ins to CVS in the last months. This was done with the intention to have them tested by a wider audience. It was never my intention to definitely have them all included in the final 1.2 distribution. Now, what can we do about this? There are a few solutions that I can imagine and I'm sure you can imagine more... (1) Include only a few core plug-ins and package others into groups that the user can install at will and that will stay in one menu place as a group. This doesn't mean that no core plug-ins are part of the same menu, but by 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) For the hardcore user create a package that contains them all. (2) Stay with the same basic plug-ins as in (1), rewrite the plug-in 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. (3) Let's test all those plug-ins heavily and drop everything that is not stable or usable into gimp-plugins-unstable. Do the same thing with what is called gimp-plugins-unstable now and move all plugins that seem to be stable and usable up into the main distribution. Then start the menu discussion all over (we had one before 1.0 was released) and find a better way to put all those plug-ins into suitable menu positions. Salut, Sven
Re: Plugins
Why not add this capability to gimptool? Each plug-in could have its own PlugInName.mo file bundled with it, which gimptool would grab and install in the proper /usr/local/share/locale/ subdirectories. --Shawn On Thu, 21 Oct 1999 [EMAIL PROTECTED] wrote: > > Hm, we would have to hack a script which dynamicly adds all the source > files to gettexts path... > But: This script has to run either on the server on a regularly base or > all the catalog authors have to get every possible plugin and put the source > into the right directory otherwise every try to update the .po > files would end up in blown away translations > S h a w n W a l l a c e AS220, Providence RI USA URL: www.as220.org/shawn
Re: Plugins
On 19 Oct, Marc Lehmann wrote: > 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. Hm, we would have to hack a script which dynamicly adds all the source files to gettexts path... But: This script has to run either on the server on a regularly base or all the catalog authors have to get every possible plugin and put the source into the right directory otherwise every try to update the .po files would end up in blown away translations -- Servus, Daniel
Re: Plugins
On 17 Oct, Marc Lehmann wrote: > 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. Hearing that I hope you a great idea how to achieve that, too? i.e. How do you want integrate messages from a seperate plugin tree into the catalog template? -- Servus, Daniel
Re: Plugins
> > Of course, a simple gimptool wrapper plus some archiving database (the > registry!) might suffice. > It doesn't seem as if Gimp development has the critical mass (read: sheer number of module developers) that Perl has. I think an expansion/tweaking of the registry would suffice for now, but perhaps we should be thinking of the NG Plug-in Registry, which should probably be modelled on CTAN/CPAN. S h a w n W a l l a c e AS220, Providence RI USA URL: www.as220.org/shawn
Re: Plugins
On Tue, 19 Oct 1999 02:29:52 +0200, Marc Lehmann <[EMAIL PROTECTED]> said: >>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 ;) I have no problem with using perl. People who don't have perl installed (are there really such people anymore?) can manually install things. :) Kelly
Re: Plugins
On Tue, Oct 19, 1999 at 02:29:52AM +0200, Marc Lehmann <[EMAIL PROTECTED]> wrote: > > 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... Of course, a simple gimptool wrapper plus some archiving database (the registry!) might suffice. -- -==- | ==-- _ | ---==---(_)__ __ __ 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
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 | |
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 Sat, 16 Oct 1999 22:31:09 +0200, Marc Lehmann <[EMAIL PROTECTED]> said: >So lets talk about alternative and sensible ways to solve this. ACE >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 Kelly
Re: Plugins
On Sun, Oct 17, 1999 at 01:35:17PM +0200, David Monniaux <[EMAIL PROTECTED]> wrote: > > 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. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Plugins
On Sat, 16 Oct 1999, Marc Lehmann wrote: > I remember some thoughts about a seperate plug-in cvs server where > most or all plug-ins reside. plug-in authors would easily get access. > 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 There is no consensus, and even no published opinion, as to where to store translations for plugins not shipped with core. --- David Monniaux Tel: +33 1 44 32 20 66Fax: +33 1 44 32 20 80 Laboratoire d'informatique de l'École Normale Supérieure, 45 rue d'Ulm - 75230 PARIS cedex 5 - FRANCE
Re: Plugins
On Sat, Oct 16, 1999 at 02:21:29AM -0500, Kelly Lynn Martin <[EMAIL PROTECTED]> wrote: > >Hi everyone, can anyone add Kevin Turner's plugins Adaptive Contrast > >Enhancement and AntiAlias and also the kaleidoscope plugin to GIMP > >cvs. > > NO! There are already too many plugins in the main CVS package as it > is. Adding more is just making a bad situation even worse. So lets talk about alternative and sensible ways to solve this. ACE is definitely more useful for the average gimp user than gap or mosaic (although these are highly useful to some). I remember some thoughts about a seperate plug-in cvs server where most or all plug-ins reside. plug-in authors would easily get access. 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). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Plugins
On Thu, 14 Oct 1999 01:23:47 -0700, [EMAIL PROTECTED] said: >Hi everyone, can anyone add Kevin Turner's plugins Adaptive Contrast >Enhancement and AntiAlias and also the kaleidoscope plugin to GIMP >cvs. NO! There are already too many plugins in the main CVS package as it is. Adding more is just making a bad situation even worse. Kelly
