Hi,

David Neary writes:

the change to GTK+ 2.2 and Fontconfig a few months ago. In principle, someone who has the dependencies for a 2.0 build should have everything they need to keep up with GIMP CVS through the 2.2 release.

We will have to depend on GTK+-2.4 pretty early if we want to make use of the new functionality it provides. Since there's a lot of very useful stuff in the 2.4 API, we should make the switch to GTK+-2.4 soon after the 2.0 release.

What do people think of the idea of a Friends of GIMP list that gets added to the announce list when we make a release, for example?

I thought that's what gimp-developer was for.

Sven

David Neary writes:

Hi,

I'm replying in 2 parts, because there were 2 different issues in this mail.

Sven Neumann wrote:

David Neary writes:

In
principle, someone who has the dependencies for a 2.0 build should have everything they need to keep up with GIMP CVS through the 2.2 release.

We will have to depend on GTK+-2.4 pretty early if we want to make use of the new functionality it provides. Since there's a lot of very useful stuff in the 2.4 API, we should make the switch to GTK+-2.4 soon after the 2.0 release.

What functionality is in 2.4 that we could use? I don't mean to be a killjoy - we should definitely be able to build with 2.4.x, but IMHO, we shouldn't bump the version requirement unless there's a very good reason to do so.

There are a couple of very good reasons:

GtkFileChooser will finally give us a sane file selection dialog. We can stop to simply reassing all these bug reports to GTK+ which complain about a file dialog from the stone age that has not been significantly changed since GTK+ 1.0.

GtkAction based menus will enable us to centralize GUI callback functioality in fewer places which is an absulute prerequisite for macro recording.

GtkComboBox will enable us to get rid of GtkOptionMenu and GtkCombo in both the app and plug-ins.

GTK+ 2.4 will be binary compatible to GTK+ 2.2, so 2.2 will become unmaintained just as 2.0 is.

When we asked ourselves around the conference what hurt us the most after 1.2 was released, it was the fact that the build environment got complicated, and took a considerable amount of time to set up,

Would you tell me what would have been the alternatives? Stay with GTK+ 1.2 and postpone proper core/GUI separation for half a year? The GIMP's core is in its current shape because we switched to a sane object system early. As the recent addition of a "floating" state to GimpItem has shown we still suffer from this drastic change, and we would be not were we are today if we did this later.

The change from 2.2 to 2.4 will be totally different. It does not break anything, it only improves things. It's just a matter of installing these new libs (which will be available *long* before we will even think about releasing GIMP 2.2).

and also the GIMP was broken for longish periods.

The switch to GTK+ 1.3 didn't break the GIMP. It was broken for a long time for totally different reasons.

It all depends on what the goal of 2.2.x is. I think it should be a stabilising release, one in which we add small amounts of functionality, get it working rock solidly, and perhaps start making changes in app/base to integrate some of gegl.

Yes, the goal is stabilizing, streamlining, making small feature additions and, most important, always keeping it stable.

This of course also applies to the GUI. We can get a *lot* of user visible usability improvements by simply depending on a binary compatible GTK+ 2.4 and using the new stuff mentioned above.

Starting to integrate GEGL functionality is a much worse change (stability wise) and I would rather question this decision that the switch to GTK+ 2.4 (I'm still all for starting to use GEGL, don't get me wrong).

We might
even consider shipping gegl with the GIMP during 2.1.x to get more people building & using it (I would reccommend shipping it with the GIMP sources, rather than depending on it, if we decided to do this).

I'm absolutely against this. GEGL is a separate project we depend on and it makes no sense to include it in our sources. People *are* able to simply install it.

These are all smallish changes which shouldn't really impact people's build environments, It means that people who just want to build from CVS would be able to do so easily, and without having to spend time updating other stuff while doing so.

I consider neither the use of GEGL nor the switch to GTK+ 2.4 a "smallish change", but both changes are IMHO needed if we don't want to create a huge pile of postponed TODO items we would *have* to address after 2.2 if we are not able to do them after 2.0.

Keeping the build environment stable is a reasonable goal, but it definitely has to step back after the functionality changes and enhancments we want to acheive for 2.2.

The change from GTK+ 2.2 to 2.4 will be *far from* as drastic as the change from 1.2 to 2.0. In fact it will be hardly noticable except from installing a new GTK+ version.

We really have to ask ourselves whether the functional additions to GTK+ 2.4 are really worth the cost we would incur in human terms in depending on the newer version.

We always tell people: "Wait until GTK+ fixed that". Now GTK+ has fixed a lot of longstanding uglyness and we should use the fixed stuff or functioality additions will be mostly limited to the core.

Apart from that, we outlined these goals at GimpCon and one of the most prominent goals we all agreed on was depending on GTK+ 2.4 soon and make use of its features. I see no point questioning this because of questionable fears about the build system's stability.

I'd like to see us stick
to 2.2 unless there's something indispensable that we need in 2.4, and even then I'd like to see a case made for it before the change on the devel list, rather than have the change happen silently after some discussion on IRC. We're anticipating a certain amount of breakage after 2.2 anyway with the integration of gegl and its development, so at that point it would be more reasonable to start upping the required GTK+ version (perhaps even to 2.6.0 when we get there).

You propose to actually skip one development cycle of GTK+ and directly jump to GTK+ 2.6? That's insane and implies exactly that pile of postponed TODO items i mentioned above. Making our live harder in the future for the profit of a marginally easier-to-install build environment is IMHO not very wise.

Please note that we agreed to depend on GEGL early for exactly that reason: making the migration to a really GEGL based GIMP smoother and less error prone. We *can* depend on GEGL and start to use its features without badly breaking anything, just as we can do this for GTK+

In short, I see the 2.2 series as a community building release cycle, and our best chance to get people into the project after several years in limbo. If we start depending on software that isn't commonly available yet, we risk to waste some of that opportunity.

Who says we start to depend on software that's not completely available yet? That's FUD. Nobody said we should depend on GTK+ 2.4 the day after the 2.0 release.

Easy life for developers can IMHO never outweight numerous very user visible improvements that can be easily done for the price of installing some libs that are even binary compatible and don't break anything.

ciao, --mitch

Hi,

David Neary writes:

What functionality is in 2.4 that we could use? I don't mean to be a killjoy - we should definitely be able to build with 2.4.x, but IMHO, we shouldn't bump the version requirement unless there's a very good reason to do so.

There are very good reasons. We already prepared the tree to use the new file chooser and everyone is looking forward to revamp the menu system based on GtkAction. These are very important changes that should go into the GIMP CVS tree as early as possible.

We really have to ask ourselves whether the functional additions to GTK+ 2.4 are really worth the cost we would incur in human terms in depending on the newer version. I'd like to see us stick to 2.2 unless there's something indispensable that we need in 2.4, and even then I'd like to see a case made for it before the change on the devel list, rather than have the change happen silently after some discussion on IRC. We're anticipating a certain amount of breakage after 2.2 anyway with the integration of gegl and its development, so at that point it would be more reasonable to start upping the required GTK+ version (perhaps even to 2.6.0 when we get there).

IMO it is a lot more important to get the mentioned GTK+ changes than to start to integrate GEGL.

In short, I see the 2.2 series as a community building release cycle, and our best chance to get people into the project after several years in limbo. If we start depending on software that isn't commonly available yet, we risk to waste some of that opportunity.

I don't follow you on this argumentation. Especially not since GTK+-2.4 will probably be released around the time we release GIMP-2.0. Depending on it is a must and I don't believe it will make us loose a single seriously intersted developer.

Sven

Hi,

David Neary writes:

I think that we could perhaps do the version bump in an organised way this time, at least?

What are you trying to say here? I don't remember any unorganized version bumps.

Perhaps have a 2.1.0 with a couple of weeks work (basically, the stuff which is waiting to be committed more or less now, but can't go into a 2.0 branch), and announce that it is the last release that will use gtk+ 2.2? Or even have a few releases, and do the version bump in (say) early March? You say "as early as possible" - I would argue that it's not realistic to bump versions until people have had a while to brace themselves.

We should wait for the gtk+-2.4 release and then wait another week or two to give distributors a chance to prepare packages. The rule of thumb in the past has been to wait for the package to appear in debian testing which is a rather conservative distrubtion.

What I would propose is that the GIMP CVS module have an app/gegl directory which is linked to the gegl module, so that doing a cvs co of the GIMP would also check out gegl.

This is insane. CVS modules cause nothing but trouble. If you want to use GEGL, then depend on it. If you are afraid of this dependency, don't do it then.

It's not the seriously interested developers I'm worried about, but the casual ones who might eventually become serious developers, if we don't piss them off or make it hard for them to follow the GIMP development cycle. We need more people building from CVS than we had in 1.3.x, and we're not going to have that if we depend on bleeding-edge build tools or libraries.

Nooone said we want to do that. What are you talking about? We talk about depending on GTK+-2.4 which will be the latest stable release of the GIMP toolkit at the time we start to use it. You don't want us to ignore the features it offers and use an unmaintained version instead, do you?

Sven

Hi,

This has split into 2 different issues again, replying twice with appropriate subjects.

Sven Neumann wrote:

David Neary writes:

I think that we could perhaps do the version bump in an organised way this time, at least?

What are you trying to say here? I don't remember any unorganized version bumps.

In the past, I recall there being problems with the trasition from GTK+ 1.2 to 1.3, Ipersonally heard about the version bump from GTK+ 2.0 to 2.2 when the build failed, idem for the fontconfig requirement, idem for the version bumps in automake during the release cycle.

By "in an organised way", I mean simply that we make a decent effort before changing build requirements to let people know that they're going to be changed, when, why, and what they need to do to keep a working GIMP CVS build environment. This is not the trivial problem you're making it out to be.

We should wait for the gtk+-2.4 release and then wait another week or two to give distributors a chance to prepare packages. The rule of thumb in the past has been to wait for the package to appear in debian testing which is a rather conservative distrubtion.

I think that we should definitely have a release from CVS before changing (at least a week before changing) and have something in the release notes saying that the GTK+ version will bump in the next release. And pair this up with a mail to gimp-developer saying when the change will happen, and how to keep things working.

The bump from gtk+ 2.0 to 2.2, for example, was not just a simple version bump, because there were about half a dozen other packages that needed to have recent versions installed. It would have been nice to have a small list, and a couple of days notice that things were going to change.

> No-one said we want to do that. What are you talking about? We talk > about depending on GTK+-2.4 which will be the latest stable release of > the GIMP toolkit at the time we start to use it. You don't want us to > ignore the features it offers and use an unmaintained version instead, > do you?

No-one who is not a GNOME developer will have GTK+ 2.4.0 installed on their machine. The first time people will have this software installed is the early-adopters of GNOME 2.6.0 in April and May. So I don't mind being on GTK+ 2.4 at that stage. I don't even mind being on it earlier, as long as we don't assume that people will just have it installed. That means putting some work into letting people know how to migrate their build stuff (see above).

At the heart of this issue is whether we want to make it easy for people to build the GIMP. I think we do. Depending on software that they haven't installed yet makes it a bit harder. Breaking build environments by changing dependencies without giving people adequate warning does too. I want to avoid things that make it harder for casual people to keep up to date with CVS GIMP. And that's all.

Cheers, Dave.

Hi again,

Sven Neumann wrote:

David Neary writes:

What I would propose is that the GIMP CVS module have an app/gegl directory which is linked to the gegl module, so that doing a cvs co of the GIMP would also check out gegl.

This is insane. CVS modules cause nothing but trouble. If you want to use GEGL, then depend on it. If you are afraid of this dependency, don't do it then.

I really didn't expect this to be so controversial. GTK+ was developped as part of the GIMP until it reached a certain state of maturity, I'm not suggesting that we absorb the goat, just that we include it in our tarball (again, to make the GIMP easier to build - which comes back to the other mail).

Other people do this, so perhaps it's not as obviously insane as you're making out. There is no fear of the dependency... but until gegl is in a state where it's mature enough to make standalone releases, then it's more or less exclusively a GIMP project. Why not help it along?

Cheers, Dave.

Hi,

Dave Neary writes:

Other people do this, so perhaps it's not as obviously insane as you're making out. There is no fear of the dependency... but until gegl is in a state where it's mature enough to make standalone releases, then it's more or less exclusively a GIMP project. Why not help it along?

Because I believe that it will hurt the project to become part of the GIMP tarballs. It will be much more helpful if we help to create standalone GEGL releases early. This will raise interest in GEGL and it will make packages appear for all distributions.

Moving it into the GIMP tarball is like moving GTK+ back into the GIMP tree just because we need some functionality out of the HEAD branch. GEGL is a separate project and it is IMO very important that it doesn't become too GIMP-centric. Having it included in the GIMP tarball will make it appear as part of The GIMP which it isn't supposed to be. What you suggest basically has only disadvantages. Let alone the fact that it will be a nightmare to maintain.

Sven

Hi,

Dave Neary writes:

By "in an organised way", I mean simply that we make a decent effort before changing build requirements to let people know that they're going to be changed, when, why, and what they need to do to keep a working GIMP CVS build environment. This is not the trivial problem you're making it out to be.

Sure, we can send mail to the list and I am pretty sure we did this in the past also. Perhaps we forgot in or two occasions (probably when we started to depend on automake-1.6 two years after it had been released). But we should not stall the GIMP development by introducing a policy that forces us to wait before we can do such a change. In the past all dependency changes have been necessary. There has always been the urgent need to do it in order to fix a severe problem. Do you really want us to introduce a week or two delay thus halting development until a dependency change can be made? What benefit would that give?

No-one said we want to do that. What are you talking about? We

> talk about depending on GTK+-2.4 which will be the latest stable > release of the GIMP toolkit at the time we start to use it. You > don't want us to ignore the features it offers and use an > unmaintained version instead, do you?

No-one who is not a GNOME developer will have GTK+ 2.4.0 installed on their machine. The first time people will have this software installed is the early-adopters of GNOME 2.6.0 in April and May.

GTK+ is the GIMP toolkit. I think it is completely reasonable to expect GIMP developers to have the latest stable released version of the GIMP toolkit installed. Actually I even expect GIMP developers to play with the GTK+ prereleases since that's the only way we can make sure that the GIMP toolkit works the way we need it to work. Right now for example it is important to check the 2.4 API because very soon there will be no chance to have things changed if they turn out to break The GIMP or don't suit our needs. If we would follow your suggestions we'd let the GNOME developers dictate how GTK+ evolves and I think that we should also play an important role here. I seriously believe that it is very important both for GTK+ and for The GIMP to follow GTK+ development closely and to adopt to their changes as early as possible.

At the heart of this issue is whether we want to make it easy for people to build the GIMP. I think we do.

Yes we do, but I think an easy build shouldn't be first priority. That's something that should be kept in mind and it's nice if we can make it happen. But often we will simply have to make people update their software.

Sven

Hi,

What is wrong about depending on GEGL and have people download and compile it separately? GTK+ used to live in the GIMP source tree for historical reasons only. I strongly doubt anyone would have wanted to move it into the GIMP source tree if it was started as a separate project. Why would you want to do this with GEGL now?

Sven

On Mon, Dec 22, 2003 at 06:15:17PM +0100, David Neary wrote:

Not at all. GTK+ lived in the GIMP source tree until it was capable of being a standalone project. Afterwards, its main developers were gimp developers. Unfortunately, several of them followed the path which GTK+ has become to go on to be core GNOME developers and no longer work on the GIMP.

The point is that as it is, gegl is not a standalone project. It doesn't seem to me like it is mature enough that if the GIMP went under (say a few more people quit), gegl would not go on to be a standalone graphics library in the way that gtk+ went on to be a standalone toolkit. During the incubation of the project, it needs attention from us in the same way as gtk+ got attention pre-1.0.

But it *is* a standalone project. That's been the intent from the beginning. I don't see how "incubation" helps it in any way. There are people who have indicated wanting to use it for other projects besides GIMP already.
GTK+ was distributed as part of GIMP until people found out that "hey, this is a useful general purpose toolkit". We already know that with GEGL. There weren't any notable positive benefits with keeping GTK+ as part of the GIMP tree.

GEGL is a separate project and it is IMO very important that it doesn't become too GIMP-centric. Having it included in the GIMP tarball will make it appear as part of The GIMP which it isn't supposed to be. What you suggest basically has only disadvantages. Let alone the fact that it will be a nightmare to maintain.

I'm not suggesting maintenance. I'm suggesting including milestone releases of gegl in our sources. Or storing them with our release tarballs. Either is good. Basically, releasing them together. Early. Before we use the functionality. So that they get built, and people are aware that gegl is real software, not a mission statement from 3 years ago. I'd like to see this done hand-in-hand with a configure check for gegl, so that we actually do get people downloading and building it.

There isn't any point. The problem with dependencies most people have is not downloading and installing tarballs, but rather the mess that is Freetype library incompatibilites and by extension any of the things that directly depend on it.

GEGL doesn't depend on any external library GIMP doesn't already need.

-Yosh

Hi,

Sven Neumann wrote:

What is wrong about depending on GEGL and have people download and compile it separately? GTK+ used to live in the GIMP source tree for historical reasons only. I strongly doubt anyone would have wanted to move it into the GIMP source tree if it was started as a separate project. Why would you want to do this with GEGL now?

What's wrong with having gegl sources to download with the latest release on the FTP server, the same way we used to have libaa, libmpg, libpng and all the other stuff we needed? Up until 1.2.x, we used to have gtk+ and glib sources with gimp sources. What was wrong with that?

Dave.

Manish Singh wrote:

On Mon, Dec 22, 2003 at 06:15:17PM +0100, David Neary wrote:

The point is that as it is, gegl is not a standalone project.

But it *is* a standalone project. That's been the intent from the beginning. I don't see how "incubation" helps it in any way. There are people who have indicated wanting to use it for other projects besides GIMP already.

OK - fair enough. It's a standalone project. But we're going to use it, and need it, and from what I recall, calvin was looking for more GIMP input into what it should do. How do you propose we get that kind of communication happenning?

GTK+ was distributed as part of GIMP until people found out that "hey, this is a useful general purpose toolkit". We already know that with GEGL. There weren't any notable positive benefits with keeping GTK+ as part of the GIMP tree.

Except that until people noticed that it was a useful general purpose toolkit, it kept getting worked on, with a particular application in mind... I think that being part of the GIMP was enormously beneficial to gtk+.

There isn't any point. The problem with dependencies most people have is not downloading and installing tarballs, but rather the mess that is Freetype library incompatibilites and by extension any of the things that directly depend on it.

GEGL doesn't depend on any external library GIMP doesn't already need.

I'm afraid I didn't follow the logic of this... how is this a counter-argument to having gegl and gimp downloads in the same directory?

Note, I'm no longer advocating shipping gegl as part of the GIMP sources - although I see no reason not to do that personally, I can see that most people are against it and don't consider it the thing to do (that said, only 3 people have replied with a preference).

Cheers, Dave.

On Tue, Dec 23, 2003 at 09:35:09AM +0100, Dave Neary wrote:

Manish Singh wrote:

On Mon, Dec 22, 2003 at 06:15:17PM +0100, David Neary wrote:

The point is that as it is, gegl is not a standalone project.

But it *is* a standalone project. That's been the intent from the beginning.
I don't see how "incubation" helps it in any way. There are people who have indicated wanting to use it for other projects besides GIMP already.

OK - fair enough. It's a standalone project. But we're going to use it, and need it, and from what I recall, calvin was looking for more GIMP input into what it should do. How do you propose we get that kind of communication happenning?

Not sure. Something to think about more post-2.0.

GTK+ was distributed as part of GIMP until people found out that "hey, this is a useful general purpose toolkit". We already know that with GEGL. There weren't any notable positive benefits with keeping GTK+ as part of the GIMP tree.

Except that until people noticed that it was a useful general purpose toolkit, it kept getting worked on, with a particular application in mind... I think that being part of the GIMP was enormously beneficial to gtk+.

The beneficial part was having GIMP use GTK+. Period. Having it part of the actual source tree didn't really contribute to that benefit much at all, since it would've gotten worked on regardless.

In fact, it was a minor hindrance, since GIMP specific stuff like GtkGamma got stuck in the general purpose library, and now the GTK+ folk have to maintain it when it doesn't actually belong.

There isn't any point. The problem with dependencies most people have is not downloading and installing tarballs, but rather the mess that is Freetype library incompatibilites and by extension any of the things that directly depend on it.

GEGL doesn't depend on any external library GIMP doesn't already need.

I'm afraid I didn't follow the logic of this... how is this a counter-argument to having gegl and gimp downloads in the same directory?

Note, I'm no longer advocating shipping gegl as part of the GIMP sources - although I see no reason not to do that personally, I can see that most people are against it and don't consider it the thing to do (that said, only 3 people have replied with a preference).

You didn't propose having gegl and gimp downloads in the same directory till today. So I don't follow the logic. ;)

I don't really mind symlinking the gegl sources into the gimp ftp dir, but that's a fairly minor thing. Most people follow webpage links rather than poking through an ftp site these days, and the download webpage should of course link to gegl.

-Yosh

On Tue, Dec 23, 2003 at 09:27:17AM +0100, Dave Neary wrote:

Hi,

Sven Neumann wrote:

What is wrong about depending on GEGL and have people download and compile it separately? GTK+ used to live in the GIMP source tree for historical reasons only. I strongly doubt anyone would have wanted to move it into the GIMP source tree if it was started as a separate project. Why would you want to do this with GEGL now?

What's wrong with having gegl sources to download with the latest release on the FTP server, the same way we used to have libaa, libmpg, libpng and all the other stuff we needed? Up until 1.2.x, we used to have gtk+ and glib sources with gimp sources. What was wrong with that?

Actually, as far as I can recall, the gtk+ and gimp sources were not in the same directory since before 1.0.0.

-Yosh

Manish Singh wrote:

On Tue, Dec 23, 2003 at 09:35:09AM +0100, Dave Neary wrote:

OK - fair enough. It's a standalone project. But we're going to use it, and need it, and from what I recall, calvin was looking for more GIMP input into what it should do. How do you propose we get that kind of communication happenning?

Not sure. Something to think about more post-2.0.

We could think about it now, and do something about it post 2.0 :) That's all I am doing is throwing ideas around.

The beneficial part was having GIMP use GTK+. Period. Having it part of the actual source tree didn't really contribute to that benefit much at all, since it would've gotten worked on regardless.

So having the GIMP use gegl will be beneficial to gegl :)

In any case, that is not the goal of the 2.2 release. I still believe that always stable, always releasable, with a 6 week freeze on functionality and a release for GUADEC are the technical goals of the 2.1.x series. If we start using tiny bits of gegl, then that's great.

I'm afraid I didn't follow the logic of this... how is this a counter-argument to having gegl and gimp downloads in the same directory?

You didn't propose having gegl and gimp downloads in the same directory till today. So I don't follow the logic. ;)

The post you replied to immediately before this one talked about having the tarballs together. I posted that yesterday.

I don't really mind symlinking the gegl sources into the gimp ftp dir, but that's a fairly minor thing. Most people follow webpage links rather than poking through an ftp site these days, and the download webpage should of course link to gegl.

I agree.

Cheers,
Dave.

Hi,

Dave Neary writes:

What is wrong about depending on GEGL and have people download and compile it separately? GTK+ used to live in the GIMP source tree for historical reasons only. I strongly doubt anyone would have wanted to move it into the GIMP source tree if it was started as a separate project. Why would you want to do this with GEGL now?

What's wrong with having gegl sources to download with the latest release on the FTP server, the same way we used to have libaa, libmpg, libpng and all the other stuff we needed? Up until 1.2.x, we used to have gtk+ and glib sources with gimp sources. What was wrong with that?

Putting the tarballs somewhere close to the GIMP tarball on the FTP server is of course reasonable. But unless I completely misunderstood you earlier, you proposed to include gegl as a virtual CVS module and to include it in the GIMP tarball. That's what we've been discussing here.

Sven