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

On Tue, 7 Sep 2004, Alan Horkan 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 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.

Given that 2.2 is supposed to be api-compatible with 2.0, I think that should extend to the scheme extension as well.

Also, I'll again repeat my objection to the idea that the scheme extension be packaged separately from GIMP. We have always had Script-Fu as a universal -- the one scripting system you could count on for all gimp installations on every platform. It would be quite a shame if that was no longer the case.

Nathan

Hi,

Nathan Carl Summers writes:

Also, I'll again repeat my objection to the idea that the scheme extension be packaged separately from GIMP. We have always had Script-Fu as a universal -- the one scripting system you could count on for all gimp installations on every platform. It would be quite a shame if that was no longer the case.

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.

Sven

Hi,

Alan Horkan writes:

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.

I agree that backward compatibility is important also on the scripts level. There should be a way to let scripts written for 2.0 work in 2.2 without any need to change the script. I am under the impression that this won't be the case if we ship with Tiny-Fu as a Script-Fu replacement. Kevin, is that correct?

Now what can we do about this? I see a number of possible solutions:

(1) Ship with Script-Fu, package Tiny-Fu seperately and advertize it as the better alternative. This would certainly delay the switch to Tiny-Fu.

(2) Strip out Script-Fu and offer both Script-Fu and Tiny-Fu as scripting extensions. Most packagers will choose to bundle Script-Fu with GIMP so for the casual user this would look like solution (1). It would however make it a lot easier to remove Script-Fu from your GIMP installation if you decide that you prefer Tiny-Fu and have all your scripts converted.

(3) Make Tiny-Fu 100% compatible with Script-Fu. I have no idea how feasible this is but I think it would be desirable to have a backward compatibility mode in Tiny-Fu. We then would have the following choice:
(a) replace Script-Fu with Tiny-Fu (b) throw out Script-Fu and package Tiny-Fu separately

My favorite solution is (3b) but I don't know if that is doable in the given time frame. Otherwise I'd favor (2).

Sven

Hi,

Sven Neumann wrote:

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.

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.

The point I'm hoping to make is that there is a lot of work to be done when moving something out of the main source tree in letting people know that it's been moved, and where to get it, and what's included. The fact that certain plug-ins were perl rather than C or script-fu was irrelevant to the people who were just looking for the plug-in.

Cheers,
Dave.

Hi,

David Neary 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

Hi Sven,

Sven Neumann wrote:

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.

There is another alternative, which is to install both (this would perhaps confuse things...) Kevin has mentioned that script-fu and tiny-fu live quite happily together in the past.

David Neary writes:

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.

It's not just a documentation issue. The fact that perl-fu has been moved out of the source tree is pretty well documented. However, the actual knock-on effects of that aren't particularly widely known. The fact that something is documented doesn't mean that people are going to know about it.

What is needed is a list of plug-ins which are available only in perl-fu, and to somehow transfer this list to everyone downloading the GIMP sources and building from scratch, as well as packagers. We can put a file beside the traballs, listing the plug-ins that have been moved to perl-fu, but I don't think many people would read it. "They deserve what they get, then" you might say. Perhaps...

I don't know of a good way to communicate that to people who should know, except on a case-by-case basis (when someone asks what happened to filter X). I think that at least we should include links to releases of gimp-perl, gimp-help and gimp-gap in the directory where the GIMP sources are shipped. That would help, I think. And gimp-perl could have a description "Extra GIMP plug-ins" rather than "perl bindings for the GIMP" or whatever.

I don't know - I'm just throwing out ideas. I really don't have a good idea how we can communicate this to people for perl plug-ins, and I imagine that we will have even more problems if we do the same thing with the scheme plug-ins.

How about shipping the scripts with the GIMP, and somehow informing someone when they run a script that they need either script-fu or tiny-fu installed? Is that technically possible? Could we do the same thing for python-fu and perl-fu?

Cheers, Dave.

Hi again,

Sven Neumann wrote:

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.

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 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.

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 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.

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.

I don't really have ideas how to achieve that goal, but I'm a little worried about the desire to remove lots of stuff from the main GIMP CVS - this will be seen by the greater public as removing features from the GIMP.

Cheers, Dave.

Hi,

David Neary writes:

It's not just a documentation issue. The fact that perl-fu has been moved out of the source tree is pretty well documented.

It is what? Well documented? I don't think so. You already mentioned yourself what would have to be done to document this properly.

How about shipping the scripts with the GIMP, and somehow informing someone when they run a script that they need either script-fu or tiny-fu installed? Is that technically possible? Could we do the same thing for python-fu and perl-fu?

That'd be truly sick. You want to keep the scripts separately from the script interpreter? In a different source tree, in a different package even? Of course it would also not be technically possible. A script-fu doesn't register itself. It needs the Script-Fu plug-in to do that.

Sven

Hi,

David Neary writes:

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 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.

It is however the road that the developers want GIMP to be taking. The idea is that a number of smaller packages make the code easier to work with and easier to maintain. This will allow more people to work on it. The workload is shared and more people are taking responsibily for their part of the GIMP.

No one talks about shipping the core application, with no plug-ins, no image data structures, no scripts, and a minimum number of brushes, patterns and gradients to our users. What we are talking about here is what you get when you do a cvs checkout of the core gimp module.

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 think the experience with GIMP development very clearly shows that we are not able to fulfill this wish if we stick to the way that GIMP is organized now. There have been almost no changes to brushes, patterns, gradients etc. in the GIMP source tree for years. I am certain that this would change as soon as we move these out of the source tree and let someone else handle packaging of these files.

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.

Exactly. But that doesn't say anything about the way we organize that stuff in CVS. People who are installing GNOME also expect to get a set of applications and actually that is what they get when installing GNOME. Yet still all these different GNOME applications are spread over hundreds of CVS modules.

Essentially, what the user gets when installing GIMP is a question of packaging GIMP not a question of throwing it all into a single CVS tree and release a gigantic tarball of this mess every so often (this is more or less what we are doing right now).

David, I am not following you on your road. Your argumentation is severily flawed and what you are asking for is not going to happen with me as the GIMP maintainer. It's way too much work already and the only way to reduce the workload for whoever maintains the GIMP sources is to split as much stuff out as possible.

I don't really have ideas how to achieve that goal, but I'm a little worried about the desire to remove lots of stuff from the main GIMP CVS - this will be seen by the greater public as removing features from the GIMP.

I don't really care how some morons will perceive the removal of stuff from the GIMP source tree. This is basically a question of explaining and documenting this action. It could very well be seen differently.

Sven

On Wed, 8 Sep 2004, Sven Neumann wrote:

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.

Slimming down the core by moving things out to other packages is very sensible. It keeps the core smaller and easier to build without having any significant impact on users, so long as packagers are smart about it. (On a side note, I really dont like Firefox because they threw out some many little bits I actually liked without rolling them out as a package of plug-ins, which is a mistake I am very glad the gimp has avoided. Adding back in the bits you like - if they are even availabe as plugins - is far less convienent than sticking with Mozilla.)

Do you foresee a "gimp-plugins" package?

gimpressionist (and its nonstandard data files), gfig, and imagemap add a quite lot bulk to the gimp and I would think of as prime candidates to be rolled out to such a package.

I dont ever expect to be using Dicom (a medical file format) but I dont think getting rid of it would necessarily be a good idea either. The way I see it at a minimum gimp core would only really need XCF PNG and JPEG (I'd immediately add in PSD but I think that is probably just me).

Is this remotely like what you have in mind because I would be interested to hear more.

- Alan

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

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