Hi,

William Skaggs wrote:

Dave Neary wrote:

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.

I think I agree with Dave here. Instead of a simple "download; untar; configure; make; make install", it wouldn't be an improvement to make people go through that multiple times, making sure to do it in the right order and ldconfig after each step, matching all the versions and configurations properly. And that's just for Linux.

This is what I understand Sven wants, eventually. As I understand it, if you're building from source, you're a developer. Otherwise, get the binaries, which will have everything packaged in. If I misunderstand Sven's point of view, I'm sure that he'll correct me.

If that's the case, we're working towards needing a jhbuild or a garnome for the GIMP, which just doesn't seem right - we're a desktop application, not a suite of developer libraries and desktop applications. We have one set of developers, not several dozens.

If everything ended up in one tarball, with a single-step build, that would be grand. But I don't believe that's the intention, given the precedents of GAP and gimp-perl.

Cheers, Dave.

Hi,

David Neary writes:

This is what I understand Sven wants, eventually. As I understand it, if you're building from source, you're a developer. Otherwise, get the binaries, which will have everything packaged in. If I misunderstand Sven's point of view, I'm sure that he'll correct me.

If that's the case, we're working towards needing a jhbuild or a garnome for the GIMP, which just doesn't seem right - we're a desktop application, not a suite of developer libraries and desktop applications. We have one set of developers, not several dozens.

If everything ended up in one tarball, with a single-step build, that would be grand. But I don't believe that's the intention, given the precedents of GAP and gimp-perl.

Creating such a meta tarball would be trivial and could of course be done. I doubt however that users would want to use such a beast. You wouldn't want to download a 50MB tarball everytime some new brushes are being added or a bug-fix release of the core shows up. Of course for the initial installation, if people really want to build from source, they would probably use the meta tarball.

I will nominate you two (Dave and Bill) for maintainers of the meta tarball.

Sven

Hi,

David Neary writes:

If that's the case, we're working towards needing a jhbuild or a garnome for the GIMP, which just doesn't seem right - we're a desktop application, not a suite of developer libraries and desktop applications. We have one set of developers, not several dozens.

I don't see what's wrong with needing a jhbuild type of script to ease compilation (not that I have ever felt the need to use jhbuild). GIMP is not a desktop application. It is (or should become if it isn't yet) an image manipulation suite. We have several sets of developers already and I hope that sooner or later it will be several dozens of them. If you are lacking this vision, you are effectively stalling GIMP development. We cannot continue to grow forever, splitting things into smaller packages is the only way GIMP can grow into something really large.

Dave, it was you who only yesterday complained about the time that it takes to build GIMP. Now imagine how much time it would take if GAP and gimp-perl were still in there. We are already way beyond the point where the GIMP tarball is handable. It takes hours to run make distcheck in this beast. It takes hours to check it out of CVS and build it. It takes hours to do a release, most of this due to the huge size of the tarball and the shear amount of files that need to be tagged and committed.

Face it, GIMP is large. It doesn't fit into a single tarball. Of course, as I said in another mail, such a tarball could be build but it would just be a collection of smaller tarballs and a jhbuild type of script.

Sven

Hi,

Sven Neumann wrote:

David Neary writes:

If that's the case, we're working towards needing a jhbuild or a garnome for the GIMP

[snip...]

If everything ended up in one tarball, with a single-step build, that would be grand. But I don't believe that's the intention, given the precedents of GAP and gimp-perl.

I will nominate you two (Dave and Bill) for maintainers of the meta tarball.

Perhaps we could get jamesh and jdub to add GIMP modules to jhbuild and garnome respectively, and be done with it? :)

Cheers, Dave.

Hi Sven

Sven Neumann wrote:

I don't see what's wrong with needing a jhbuild type of script to ease compilation (not that I have ever felt the need to use jhbuild). GIMP is not a desktop application. It is (or should become if it isn't yet) an image manipulation suite. We have several sets of developers already and I hope that sooner or later it will be several dozens of them. If you are lacking this vision, you are effectively stalling GIMP development.

So do I (hope that some day we will have dozens of developer groups). I like the idea of splitting the project up in terms of domains of responsibility. That was the whole idea behind having plug-in maintainers. I'm just not sure we have the same ideas about how to get there. Then again, my ideas on the issue are pretty blurred right now. I should maybe sit down and try to clarify the way I think things might happen.

Dave, it was you who only yesterday complained about the time that it takes to build GIMP.

Small correction - IO was complaining about how shit my computer is. The GIMP's compile time is simply a symptom of that.

Now imagine how much time it would take if GAP and gimp-perl were still in there. We are already way beyond the point where the GIMP tarball is handable. It takes hours to run make distcheck in this beast. It takes hours to check it out of CVS and build it. It takes hours to do a release, most of this due to the huge size of the tarball and the shear amount of files that need to be tagged and committed.

I agree, build time is a big issue. But you've said that most people will have everything anyway, so how does build time improve? Is the idea that if we don't change the API or API for libgimp that you could recompile the core without recompiling gimp-plug-ins? I guess that idea could work...

But compile time has doubled over the past couple of years without a huge change in the size of the source code. It seems to me that the build tools we use have gotten more i/o and more processor intensive. Is it possible we could make improvements there?

I'm not opposed to having stuff split off, but I am worried about the stuff getting a bit lost. Most gimp 2.0 installs (the vast majority, I would say) don't have GAP or the perl bindings installed. That's not a trend we should be encouraging, IMHO. In fact, I think we need to work out ways to actively discourage it, and make sure most people have those packages (and others) installed. I'm just not sure how to do that (as I said before).

Cheers, Dave.

hello,

long ago when i had a job and a home and friends who were gimp developers i had an idea of a plug-in building environment.

in the time that this environment was designed, i lost all of those things previously listed. the environment i helped to design is now being used successfully at oracle saving them $150K a year and doing absolutely nothing for gimp except tossing it a few crumbs every so often. this thing is called sourcebo.

i am still waiting for beta.gimp.org. i was (perhaps teminally) dismayed to find out very recently that there will be no beta. i had to ask outright. all my plans were on hold for that. all my plans are gone now. not gone, just being used successfully at oracle and not with my project. if me and yosh were an experiment in a paid hacker working with an unpaid hacker, it has really really failed. i am doing everything i can with what i have left to end the few shreads of what is left from this venture.

my experience with gimp is different than dave neary is talking about. he is saying that if you dont get everything at one time, you will not get it. when i first started to use gimp, it was so much fun to go online and "shop" (for lack of a better term) for new and fun things for gimp that were on several different web sites -- each with its own personality. much more the pleasure when i got to meet those web site owners later online and even more in real life this year.

my biggest complaint was that many times, after long and enjoyable "shopping trips" coming back to /usr/home and installing the stuff i found -- only to find gimp already had it. and the trend tried to continue when i had the older web site full of things for gimp-1.2. yosh wanted to include my palettes in the tarball. i was sort of upset because this was exactly what we were supposed to be not doing. i guess i could have seen the problems then.

now, raphael has broken and rebuilt the web site without knowing any of this stuff. with the blessing of all i guess.

gap will be more popular as people with ideas and needs for animation eh, get their ideas and full fill their needs. i never was able to figure out how to use it, having no ideas or needs for animations.

gimp-perl gets installed now by debian for gimp-2.0 and i tried to install it for gimp-2.1.

people who want gimp-python will go and install it.

if there were a web site, like the plug-in development site i had envisioned, stripping all that stuff from the gimp core should be no problem and just increase the popularity of gimp.

too bad it is all working at oracle now and not for me and my project.

carol

more,
On Wed, Sep 08, 2004 at 06:02:16PM -0700, Carol Spears wrote:

my experience with gimp is different than dave neary is talking about. he is saying that if you dont get everything at one time, you will not get it. when i first started to use gimp, it was so much fun to go online and "shop" (for lack of a better term) for new and fun things for gimp that were on several different web sites -- each with its own personality. much more the pleasure when i got to meet those web site owners later online and even more in real life this year.

my biggest complaint was that many times, after long and enjoyable "shopping trips" coming back to /usr/home and installing the stuff i found -- only to find gimp already had it. and the trend tried to continue when i had the older web site full of things for gimp-1.2. yosh wanted to include my palettes in the tarball. i was sort of upset because this was exactly what we were supposed to be not doing. i guess i could have seen the problems then.

the thing i did get from these shopping trips i took was information about the plug-ins and resources that i already had. i got something that the documentation might not give and that is enthusiasm and instruction on what the plug-in or resource(s) could do.

how many times on the mail list or on the irc channel you need to point the stuff out to people. one place for tutorials, examples and the actual plug-in seem(ed) ideal to me.

so, i learned about the stuff that was in this tarball by accidentally getting excited and installing it again. silly, but this is from a user perspective.

carting everything around from tarball to tarball and having it instantly install does nothing for education or enthusiasm. it helps those who expect it to be there.

carol

Hi,

David Neary writes:

But compile time has doubled over the past couple of years without a huge change in the size of the source code. It seems to me that the build tools we use have gotten more i/o and more processor intensive. Is it possible we could make improvements there?

We? You could be upgrading to gcc 3.4 or downgrading to gcc 2.95.

Sven

Quoting Sven Neumann :

Hi,

David Neary writes:

But compile time has doubled over the past couple of years without a huge change in the size of the source code. It seems to me that the build tools we use have gotten more i/o and more processor intensive. Is it possible we could make improvements there?

We? You could be upgrading to gcc 3.4 or downgrading to gcc 2.95.

I'll do that.

Do automake and libtool have any upcoming improvements that might help with the pre-configure and linking stages that I should know about?

Cheers, Dave.

--
Dave Neary
Lyon, France

Hi,

Dave Neary writes:

Do automake and libtool have any upcoming improvements that might help with the pre-configure and linking stages that I should know about?

Well, what versions are you using at the moment?

Sven

Hi,

Quoting Sven Neumann :

Dave Neary writes:

Do automake and libtool have any upcoming improvements that might help with the pre-configure and linking stages that I should know about?

Well, what versions are you using at the moment?

1.7 and 1.5 respectively. The improvements I was asking about were particularly performance improvements, by the way.

Cheers, Dave.

--
Dave Neary
Lyon, France

David Neary schrieb:

> I'm not opposed to having stuff split off, but I am worried about

the stuff getting a bit lost. Most gimp 2.0 installs (the vast majority, I would say) don't have GAP or the perl bindings installed. That's not a trend we should be encouraging, IMHO. In fact, I think we need to work out ways to actively discourage it, and make sure most people have those packages (and others) installed. I'm just not sure how to do that (as I said before).

There's one aspect to splitting things out that hasn't been discussed yet. By splitting e.g. a plug-in out into it's own module and basing it on gimp-plug-in template, it becomes incredibly easy to compile it for any platform without going though the hassle of having to compile GIMP itself. This would be especially interesting for those plug-ins that have dependencies not already covered by GIMP or GTK+ itself, e.g. AA or XPM.

Additionally, this would send an important signal to plug-in developers. Currently, some of them think that being included in the core gimp module is the ultimate goal of their plug-in. Some even develop their plug-in in the GIMP source tree, which makes it uneccessary difficult to build for other people. By providing examples for standalone plug-ins that can be updated independently of GIMP releases and provided as binaries for an arbitrary platform in no time, this could be changed.

For the distribution of the plug-ins, it might become neccessary to improve the registry. Adding things to it without being the author of a particular plug-in would be interesting for providers of binaries, for example (provided that any bad stuff is kept out). Installers that can get plug-ins directly from the registry might be interesting, too.

Just my 2 cents, Michael

On Wed, 8 Sep 2004, Carol Spears wrote:

Date: Wed, 8 Sep 2004 18:02:16 -0700 From: Carol Spears
To: David Neary ,
GIMPDev
Subject: Re: [Gimp-developer] on splitting things off

hello,

my experience with gimp is different than dave neary is talking about. he is saying that if you dont get everything at one time, you will not get it. when i first started to use gimp, it was so much fun to go online and "shop" (for lack of a better term) for new and fun things for gimp that were on several different web sites -- each with its own personality. much more the pleasure when i got to meet those web site owners later online and even more in real life this year.

gimp-perl gets installed now by debian for gimp-2.0 and i tried to install it for gimp-2.1.

people who want gimp-python will go and install it.

When using the University computers I'm pretty much stuck with what the systems adminstrator installs and they is almost always only the defaults.

Most users will rate the gimp based on what it includes by default. If something is not there by default is missing.

I can understand that some people relish hunting for all sorts of different add-ons (sometimes I feel like doing that too) but I dont think most people do.

- Alan

On Thu, 9 Sep 2004 00:06:12 +0200, David Neary wrote:

Sven Neumann wrote:

David Neary writes:

If everything ended up in one tarball, with a single-step build, that would be grand. But I don't believe that's the intention, given the precedents of GAP and gimp-perl.

I will nominate you two (Dave and Bill) for maintainers of the meta tarball.

Perhaps we could get jamesh and jdub to add GIMP modules to jhbuild and garnome respectively, and be done with it? :)

I don't think that we need something like jhbuild or garnome for a meta tarball. From my point of view, the contents of this tarball could look like this:

./configure ./Makefile.in
./gimp-2.0.4/... (all files from the standard tarball) ./gimp-gap-2.0.2/... (same for GAP) ./Gimp-2.0/... (same for Perl) ./gimp-data-extras-2.0.0/...

The top-level configure script would basically contain something like AC_CONFIG_SUBDIRS(gimp-2.0.4...) and the Makefile.in would contain SUBDIRS=gimp-2.0.4 etc. Autoconf has been designed to support building multiple packages from a top-level configure script, so we should take advantage of it.

This meta tarball would not be very hard to create or maintain: it's just that the version numbers would have to be increased from time to time, whenever the contents of a new gimp/gimp-gap/gimp-perl/... tarball are extracted and included in the meta tarball. This would not require much effort.

-Raphaël

On Thu, 09 Sep 2004 16:51:47 +0200, Michael Schumacher wrote:

There's one aspect to splitting things out that hasn't been discussed yet. By splitting e.g. a plug-in out into it's own module and basing it on gimp-plug-in template, it becomes incredibly easy to compile it for any platform without going though the hassle of having to compile GIMP itself. This would be especially interesting for those plug-ins that have dependencies not already covered by GIMP or GTK+ itself, e.g. AA or XPM.

Note that doing splitting things out and using the gimp-plug-in-template will significantly increase the build time because each plug-in would then run its own configure script, which can take longer than building the plug-in itself. I can already hear Dave complaining. ;-)

Additionally, this would send an important signal to plug-in developers. Currently, some of them think that being included in the core gimp module is the ultimate goal of their plug-in. [...]

Besides the advantages of being distributed together with the GIMP, including a plug-in in the main tree has another advantage: the translations. Currently, it is rather hard for a plug-in distributed separately from the GIMP to have good translations in many languages. If it is in the main tree, several translators will (have to) work on it. If it is outside, chances are that the developer will not be able to get enough people interested in contributing translations.

One way to solve this would be to put many plug-ins in a gimp-plug-ins module in gnomecvs, but that would only shift the goal for the plug-in developers from being included in the main tree to being included in the "official" list of plug-ins. Maybe that's better than the current situation?

Note that it would only work with one (or just a few) module in cvs, not with dozens of separate modules because it would be more motivating for the translators to cover just one new module than having to look at many modules containing very few things to translate. This also takes into account the fact that gettext tries to be smart about handling identical strings that occur multiple times in the source tree, which makes the translators' life easier (sometimes).

-Raphaël

On Thu, Sep 09, 2004 at 06:57:56PM +0200, Rapha?l Quinet wrote:

One way to solve this would be to put many plug-ins in a gimp-plug-ins module in gnomecvs, but that would only shift the goal for the plug-in developers from being included in the main tree to being included in the "official" list of plug-ins. Maybe that's better than the current situation?

the people with permissions on gnomecvs have proven (at least to me) to have permission yet not have gimp's interest in their plans.

i had problems with gnomecvs, big problems. anyone who got their permission can destroy a project.

and it can be difficult to get permissions for people who have gimps best interests in mind.

i consider gnomecvs to be a liability and a vulnerability -- not an asset.

carol

Hi,

Raphaël Quinet writes:

Besides the advantages of being distributed together with the GIMP, including a plug-in in the main tree has another advantage: the translations. Currently, it is rather hard for a plug-in distributed separately from the GIMP to have good translations in many languages. If it is in the main tree, several translators will (have to) work on it. If it is outside, chances are that the developer will not be able to get enough people interested in contributing translations.

The vast amount of translatable strings in po-plug-ins is a good reason not to translate them at all. If we would split plug-ins out into a number of smaller packages and put these in GNOME CVS, I don't expect less translations than we have today. Again, it's just a matter of telling the GTP people about it.

Note that it would only work with one (or just a few) module in cvs, not with dozens of separate modules because it would be more motivating for the translators to cover just one new module than having to look at many modules containing very few things to translate. This also takes into account the fact that gettext tries to be smart about handling identical strings that occur multiple times in the source tree, which makes the translators' life easier (sometimes).

Translators are already using tools that share these strings across different modules so that is not really a valid argument.

Sven

Hi,

Raphaël Quinet writes:

This meta tarball would not be very hard to create or maintain: it's just that the version numbers would have to be increased from time to time, whenever the contents of a new gimp/gimp-gap/gimp-perl/... tarball are extracted and included in the meta tarball. This would not require much effort.

You should talk to Havoc one day and ask him why this meta tarball thing didn't work for GTK+. I don't think it is as easy as you put it.

Sven