David Neary <[EMAIL PROTECTED]> writes:

> Hi,
> I'm replying in 2 parts, because there were 2 different issues in
> this mail.
> Sven Neumann wrote:
>> David Neary <[EMAIL PROTECTED]> 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

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

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.

Gimp-developer mailing list

Reply via email to