David Neary <bolsh@xxxxxxxx> writes: > Hi, > > I'm replying in 2 parts, because there were 2 different issues in > this mail. > > Sven Neumann wrote: >> David Neary <dneary@xxxxxxx> 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
