Re: [Gimp-developer] GIMP 2.2 and Script-Fu/Tiny-Fu.
Hi, David Neary [EMAIL PROTECTED] writes: Why wouldn't that be the case any longer? It would only be packaged in a separate source tree. Of course every GIMP installation would include it. How would you enfore the dependency? I don't understand how removing script-fu from the source tree and having it present in every GIMP installation are compatible propositions. Simply by asking packagers to bundle Script-Fu with GIMP. On a Debian system, the gimp package would recommend the gimp-script-fu package. The Win32 installer would probably simply install both. I am sure there's a solution for every platform / distribution. Of course this wouldn't strictly guarantee the availability of Script-Fu but it would make it very likely. If we want to get rid of the Script-Fu dependency in the long run, then we need to make it optional at some point. Now seems to be a good time to do that. It would allow people who want to switch to Tiny-Fu to install GIMP w/o Script-Fu while the vast majority of GIMP users would continue to use Script-Fu for now. On a side point (which is relevant), there are many users on Usenet who have been downloading the GIMP and building it from sources, who have been asking why so many plug-ins were removed from the GIMP between 1.2 and 2.0 - the plug-ins that have been removed are perl-fu plug-ins which were transparently included in 1.2.x if you were building the main GIMP source tree and had perl installed, and that's no longer the case. That's a documentation issue. I am not going to allow the source tree to be clobbered with more stuff simply because we are too lazy to add some simple notes to our web-site and FTP server. In the long run we will want to split GIMP into even more packages. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP 2.2 and Script-Fu/Tiny-Fu.
On another note, I'm not sure this is a desirable goal. splitting stuff off feels an awful lot like putting it out to pasture. The that does seem like a valid risk to consider goal of just having the core application, with no plug-ins, no image data structures, no scripts, and a minimum number of brushes, patterns and gradients doesn't seem to be the direction that people want to see the GIMP taking, from what I can tell. I think a lot more of the patterns really should be moved to gimp-data-extras (there are three different types of wood included in the basic patterns, one should really be enough in the base) so that those who want less will have less and those who want more will realise that they should install gimp-data-extras and get a lot more. People would like more brushes, more patterns, more gradients, with the ability to delete the ones they don't use/like, and more scripts/plug-ins with a way to organise the menus according to the ones they use most often. I do think users want this but I do not think users care how it is achieved. Things can be split into seperate packages but the real problem occurs when distributions do not fully realise the intention was only to modularlize not to remove the features and that they should install it _all_ unless they have a really good reason for doing otherwise. Some of us are at the mercy of systems adminstrators who install only the default packages. I know that you believe that we should work on the core application and a few plug-ins, and leave most of the plug-in development to 3rd party plug-in maintainers, I'm not sure I agree. I think that we should be almost promiscuous in what we accept into CVS, but equally vicious in removing things from CVS when they become unmaintaned. I think that most people don't want to have to install several packages, they want to install the GIMP, and automatically get plug-ins like gap, refocus, and even DBP. I would like to think that all these things would be installed by defualt on most distributions, that the users would have to specifically opt out if they didn't want the extras (and distributions like Knoppix would have to strike a careful balance on what they leave out) Note that I'm not saying that all this should happen for 2.2, but I am speaking to the general goal of a lean, mean GIMPing machine versus an application which comes with everything including the kitchen sink, which you can modify to your own usage patterns, buut which has sufficiently sane defaults as to not have a huge complicated menu structure at the same time. Maybe I'm foolishly optomistic to think that we could have both a small seperable core but have everything and the kitchen sink nicely packaged so that the developers can get on with things with the minimum of fuss and users can still have it all. - Alan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP 2.2 and Script-Fu/Tiny-Fu.
Kevin Cozens wrote: Replacing Script-Fu with Tiny-Fu could help push Tiny-Fu along a bit (ie. with translations) if it isn't fully ready yet by exposing it to more users but what is in the best interest of GIMP and its users? I'm actually quite sympathetic, but it doesn't seem to me that you've given reasons for replacing Script-fu with Tiny-fu that to users would justify the effort involved. The sorts of reasons that might be convincing would include: 1) Tiny-fu makes it possible to do things that you can't do in Script-fu. (Does it? Can you give examples?) 2) Tiny-fu scripts are easier to write than Script-fu scripts. (Are they?) 3) Tiny-fu scripts are more robust than Script-fu scripts. (Are they?) 4) ? In short, I think you have to sell this a bit better, because people aren't going to be enthusiastic about doing the work of converting their scripts unless they see some major gain that goes along with it. Best, -- Bill __ __ __ __ Sent via the KillerWebMail system at primate.ucdavis.edu ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP 2.2 and Script-Fu/Tiny-Fu.
Replacing Script-Fu with Tiny-Fu could help push Tiny-Fu along a bit (ie. with translations) if it isn't fully ready yet by exposing it to more users but what is in the best interest of GIMP and its users? I know I'd much prefer another stable release with Script-Fu in it first, but that is my entirely subjective opinion. I fear having to rewrite some of my scripts having already written gimp 1.2 and gimp 2.0 versions. Compatibility is important to me, even if only small changes are necessary it causes problems. I dont relish the prospect of new scripts I write not being usable by people who still have gimp 2.0.x or even 1.2, users are still requesting backports of scripts to 1.2. It may seem like Gimp 2 has been available for ages, particularly for those who have been using gimp 1.3 but Gimp 2.0 was only released this summer. That said I'll certainly hope to instal Tiny-Fu alongside Script-Fu and sort things out after 2.2. - Alan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
