On Tue, 17 Jun 2003 21:22:23 +0200, Sven Neumann wrote:

So all we need is an even version number... All around GIMP, most notably with its toolkit GTK+, the 2.0 era has begun. Should we really go for 1.4? I don't think so and everyone me and Mitch talked to (for example on #gimp) agreed that the changes since 1.2 warrant the jump to 2.0. So unless anyone speaks up with good reasons against calling the next release GIMP 2.0, it will probably happen so.

Well, I am glad to hear that there will be no 1.4. There were so many changes in the development branch that I also feel that it deserves a major release number.

However, if this numbering change is confirmed, then we should start communicating this as soon as possible to all developers (looks like this is done now) and all users. There are still many, many references to GIMP 2.0 on various web sites, saying that it should be the version that adds support for 16-bit channels and CMYK. Many Photoshop users (and Cinepaint users, maybe) have been told to wait until 2.0 to get these features. If this will be in 3.0 instead of 2.0, then we should start spreading this information soon in order to avoid bad press later from those who compare the new version to the old release schedule.

-Raphaël

On Tue, Jun 17, 2003 at 09:22:23PM +0200, Sven Neumann wrote:

So all we need is an even version number... All around GIMP, most notably with its toolkit GTK+, the 2.0 era has begun. Should we really go for 1.4?

Well, all the agruments I see in favour of 2.0 are always of the form "well, evereybody else has 2.0". Well, gtk+2 is at 2.2, msoffice is at 2003 etc..

I don't think making up numbers just for the marketing is honest or useful for users.

Frankly, I won't be oposed very much to calling it gimp-2.0, but everybody is expecting some _major_ release for 2.0, and 1.2 => 2.0, while having many enhancements, is not, in my opinion, much bigger than the 1.0 => 1.2 jump.

So... I'd beg for a little more honesty in version numbering, and a little less marketing. A gimp-2.0 with lots of very nice but minor improvements (where is the modularity? where is support for cmyk? where are the programmable layer effects? and macro capability? even the fact that most perl scripts need not a modification to run does not show major cleanups in that part) is good for initial reaction, but people will aks themeselves where all the great things planned for 2.0 have gone. (Yes, I like the text tool, I etxremely like the undo history.. but that is all nothing major).

I really don't think it qualifies as 2.0. That doesn't mean to diminish the work (which is impressive), but I think just randomly jumping on version numbers to have the same version number as everybody else doesn't help - it's just confusing, as version numbers become utterly meaningless.

Just my 0.02µ¢, I feel that I had to make this point, don't kill me :)

sven@gimp.org (2003-06-17 at 2122.23 +0200):

So all we need is an even version number... All around GIMP, most notably with its toolkit GTK+, the 2.0 era has begun. Should we really go for 1.4? I don't think so and everyone me and Mitch talked to (for example on #gimp) agreed that the changes since 1.2 warrant the jump to 2.0. So unless anyone speaks up with good reasons against calling the next release GIMP 2.0, it will probably happen so.

As already have been pointed out, lot of talk has been going about 2.0 being the great change, and something else being in the middle. So IMHO going for 2.0 directly would cause a bit of confusion, so I do not see any real adventage about starting a number race.

To mark it as "a lot have been done and it took a lot of time", there are some other numbers from 1.3 to 2.0 that are even too (ok, only three make sense, 1.4, 1.6 and 1.8). I find easier to explain that after 1.2 the next stable is not 1.4 but 1.6 ("the bridge from old to new") or 1.8 ("the path to 2.0 begins") than explaining that 2.0 is not the "promised" 2.0.

The first half-explains itself, the later looks as a good way to waste time explaining to people. Already some time have been invested in the old naming plan, and there always be docs floating around talking about the mighty 2.0. It is just about communication, PR or whatever you want to name it, so the clearer, the better.

Just my opinion, 1.6 or 1.8 sounds great, and there are no old news to rewrite.

GSR

PS: OK, maybe some places will have to s/1.4/1.whatever/g.
PS2: Name it Hobble4? j/k Bad Sun joke. Sleep time, really.

On Tue, 2003-06-17 at 17:48, Guillermo S. Romero / Familia Romero wrote:

As already have been pointed out, lot of talk has been going about 2.0 being the great change, and something else being in the middle. So IMHO going for 2.0 directly would cause a bit of confusion, so I do not see any real adventage about starting a number race.

FWIW - I agree. 2.0 has already been discussed at length as being a target for GEGL support and there really isn't any need to jump revision numbers other than "it makes the product sound mature."

I would say that shorter release time frames might be considered once you do get to 2.0, but there isn't any real need to rush to that point. You have plans. They seem fairly good (you'll never get complete agreement on everything, but you do the best you can). Stick with those plans.

Mozilla and Evolution are two big projects still in the 1.x range. Linux itself was in 1.x for quite some time. Getting to 2.x doesn't need to be pushed, IMHO (except if your goal is to push GEGL support integration).

On Tuesday 17 June 2003 18:51, pcg@goof.com ( Marc) (A.) (Lehmann ) wrote:

where
are the programmable layer effects?

Hmm..are these the ones I did suggest I could do a couple of weeks ago?

I am working on them...unless the freeze is quite soon, It may very well go into 1.4/2.0 . Although in 1.4.1/2.1 they will be quite more usable.

On Wednesday 18 June 2003 00:25, Joao S. O. Bueno wrote:

On Tuesday 17 June 2003 18:51, pcg@goof.com ( Marc) (A.) (Lehmann )

wrote:

where
are the programmable layer effects?

Hmm..are these the ones I did suggest I could do a couple of weeks ago?

I am working on them...unless the freeze is quite soon, It may very well go into 1.4/2.0 . Although in 1.4.1/2.1 they will be quite more usable.

Oh well.

spent the best part of the last houe reading about the GEGL, which I did not know this far.

Certainly people HAD tought of programable layer modes before I mentioned it. :-) . But it doesn'seen to be in GEGL either, altought it is quite apropriate for it.

I will go on with my work (quite on early stages) on them using the 1.3 codebase, but with an eye in GEGL - If anyone besides me like what I am doing, it wont'be hard to be added to the GEGL core.

is this correct: when 1.4 is released, gegl is expected to be ready so work can begin on gimp-2.0.
if so, when? (in relative sense, ie. which gimp 1.3.x version will be the version just before 1.4?)

also, i have a proposition for a simple gui enhancement which could drastically boost speed of access to many things and usefulness of accelerator keys. however, while it is *simple*, it is comparitively large in scope (every registered dialog eg colorselector, layers, tool options would require an individual accel-path added, and gtk menu code would require enhancements). is this something i should make a patch for, or something that could be added to the proposals/ in gimp2/ cvs?

essentially it would enhance menu accels so you could share specific shortcuts, eg, sit in the color selector picking colors and hitting 'a' to add them to the palette.

here is a paste of the doc i wrote:

++++ Shared keyboard shortcuts - part gimp, part gtk ++++

currently, keyboard shortcuts only work in their specific context.

having shortcuts that are shared between more than one context (still owned by only one) would help greatly. for instance palette construction would be much much quicker if i could assign a shortcut to 'add' and share that with the colorpicker, so i could eg. pick color, 'a', pick color,'a' until the palette is finished. gradient creation could be speeded up similarly (stack up colors in the 'save to' slots, then use the saved colors
to create a large chunk of gradient quickly).

. likely format for shared shortcuts would be:

"(gtk-shared-accel-path /New Color)

(note that ColorEditor gets its own accel group, as would every selection dialog eg Brushes,Gradients..)

so you can share key-accels for specific menu items rather than sharing the whole class. a shared accel would require the accel being shared to be already defined. this can be done by writing shared accels to menurc last.

making the accels visible would mean adding an item to the menu, like "(PaletteEditor/New Color)". note the brackets. gtk would show the shortcut like this: "(a)" rather than "a", to denote that you must go to, in this case, the palette editor, if you want to change the key combination for that accel.

how to interface with that? 'delete' to remove the current context from the list of user-contexts for a shared accel.
adding would require an additional menu item at the bottom of the menu, like an inversion of the 'tearoff' menu item, on which you could press 'insert' to add a shared accel or add current context to the users of an existing shared-accel.

making the accels visible would mean adding an item to the menu, like "(PaletteEditor/New Color)". gtk would show the shortcut like this: "(a)" rather than "a", to denote that you must go to, in this case, the palette editor, if you want to change the key combination for that accel.

(eof)

'how to interface with that' can hopefully be improved upon.

i also have a doc about weighting subsampling and optionally disabling subsampling in a clean way. (attached -it's short) i have some others (eg. slight colorselector interface cleanup) that are less certain.

anyway.. what should i best do with these? option to disable sub-pixel positioning , that is, force all coordinates for drawing operations to be exactly centered in each pixel. this greatly improves the smudge and clone tools, which ideally operate on a very specifically defined area.

weighting for subsampling: currently, drawing diagonal lines with a 1-pixel brush gives the impression of lines that are apparently 1.5 pixels thick. the weight value would effect the apparent thickness(AT), in other words, how optimistic the subsampling is about how much of a pixel falls into an area.
algorithymically, it would probably be a multiplication factor applied to pixels that are not wholly 'inside the area of the brush' (pixels at the edge of a brush that are getting subsampled) subsampled pixels that are at the edge could be found by comparing their subsampled opacity with their original opacity.

(ideally: weight = 0 produces AT of 1,
weight = 0.5 produces current AT of 1.5 weight = 0.999999 produces AT of 1.999999)

this would effect the sharpness and apparent thickness of the edges of most lines drawn with any brush. 90 degree lines drawn via shift-click would be unaffected (no subsampling to do).

(for gimp-2.0) hard edge should be a toggle for paintbrush (brushing with ink is hard-edged)

On Tue, Jun 17, 2003 at 08:42:00PM -0500, Michael J. Hammel wrote:

As already have been pointed out, lot of talk has been going about 2.0 being the great change, and something else being in the middle. So IMHO going for 2.0 directly would cause a bit of confusion, so I do not see any real adventage about starting a number race.

FWIW - I agree. 2.0 has already been discussed at length as being a target for GEGL support and there really isn't any need to jump revision numbers other than "it makes the product sound mature."

I'm also against changing the semantics of "GIMP 2.0". It's already well-known as "The GEGL GIMP with CMYK etc.". It is very hard to change such wide-spread information. And I don't see a real reason either. The switch to GTK2 is an argument, but I don't think version numbers need to match between GIMP and GTK (and GNOME maybe).

Let's not invalidate lots of information out there in the net just for marketing purposes. We can save ourselves a lot of confusion. Another argument against the rename: IIRC the changes from 1.0 to 1.2 were also significant. The GIMP release-cycle is very long-term, so users will expect significant changes, if 1.4 get released - just because it took such a long time.

Bye, Tino.

(Yes,
I like the text tool, I etxremely like the undo history.. but that is all nothing major).

But the undo history is not a new 1.3 feature, it was introduced by me in one of the 1.1 testing series and has thus been in all the 1.2 versions.

Austin

On Wed, Jun 18, 2003 at 09:55:52AM +0100, Austin Donnelly wrote:

I like the text tool, I etxremely like the undo history.. but that is all nothing major).

But the undo history is not a new 1.3 feature, it was introduced by me in one of the 1.1 testing series and has thus been in all the 1.2 versions.

That means either a) I don't pay attention to new features so I should not comment or b) Even less "major" features for a "major" release, or both.

I see now, it's not mentioned under File=>Dialogs as all the other dialogs, thus I kept not finding it.

*sigh*

On Wed, Jun 18, 2003 at 11:52:53AM +0200, Sven Neumann wrote:

I'm also against changing the semantics of "GIMP 2.0". It's already well-known as "The GEGL GIMP with CMYK etc.". It is very hard to change such wide-spread information. And I don't see a real reason either.

Such widespread information? There is one single document that is publically available that outlines a roadmap for the future of the GIMP.

It's in the heads of the people. I guess, it's also on some web pages, written in books and magazines etc.

Bye, Tino.

On Wed, Jun 18, 2003 at 11:58:06AM +0200, Sven Neumann wrote:

Well, all the agruments I see in favour of 2.0 are always of the form "well, evereybody else has 2.0". Well, gtk+2 is at 2.2, msoffice is at 2003 etc..

I give shit on msoffice but GTK+ is the GIMP ToolKit and we will have a hard time to explain why even it's major release numbers diverge.

I don't think we'd need to explain anything. GIMP 1.4 depends on GTK2. Period. In some way, it's separate software. It's not distributed with The GIMP, it just happens to be called "The GIMP ToolKit" for historical reasons. ;-)

Bye, Tino.

On Wed, Jun 18, 2003 at 11:52:53AM +0200, Sven Neumann wrote:

well-known as "The GEGL GIMP with CMYK etc.". It is very hard to change such wide-spread information. And I don't see a real reason either.

Such widespread information?

Try google with such harmless keywoards as "gimp" and "2.0".. you might be surprised how many people wait for the new 2.0 backend or other features.

After all GTK+ is the GIMP toolkit. This is IMO a very good argument for calling the next GIMP release 2.0. Actually it's the only good argument that is out there (and I don't see any good one against it).

Frankly, that makes no logical sense. Just because I wrote some linux-only software does not mean I should make my software version 2.4. A softwrae version should reflect the software's version, not the marketing behind it.

You keep explaining tzhat this is a good argument, but people don't seem to be convinced. Why is it such a good argument? It's a very bad argument in most other cases, so why is it a good argument for the gimp? Especially, what's the logical connection between the version numbers of two independent projects?

The same argument can be applied to any gtk+, especially gnome. I don't see the benefits, or the "goodness", of having the same version number for all software packages. To the contrary, this will just confuse me, as vital information (is the version number the only thing that changed on many software packages) will be destroyed.

that warrants to increase the major release number. If you looked at the code you would have noticed that every single file was touched.

That's also not a good argument.

interface has been completely rewritten. There is not much in the app directory that resembles the old 1.2 code. If that's not worth an update in major release, I really don't know what would warrant it.

A major version should be reserved for major changes... There is no major change in the user-interface. (In the code, yes, the UI, no).

I do believe that users will not be able to see any major changes.

Again, don't get me wrong. I am not trying to diminish all the work that has gone into gimp-1.3, but I fail to see why a bigger version number will be of any practical help, as opposed to more confusion.

It might be for egotistical reasons, after all, if I invested a lot of work into a release, I want to bump the version number up appropriately. But that's no service to the users of my module.

Better use codenames, that works well with users. (I liked "the road to 2.0" ;)

On Wed, Jun 18, 2003 at 11:58:06AM +0200, Sven Neumann wrote:

"well, evereybody else has 2.0". Well, gtk+2 is at 2.2, msoffice is at 2003 etc..

I give shit on msoffice but GTK+ is the GIMP ToolKit and we will have a hard time to explain why even it's major release numbers diverge.

Pardon? Why would you ever have a problem explaining why version numbers of *different* packages *differ*?

You don't even have a problem of explaining why version numbers for single files differ, even less so for different packages.

That GTK+ is the GIMP ToolKit is not at all of any concern, after all, gimp is the minority of applications using it. GTK+ has evolved. IF you want to tie the version numbers, better make it a single package.

You obviously didn't look at the code.

You obviously haven't read my mail. Really, I don't see why you are so pissed off... I don't need to look at the code to see that there are no major changes, and certainly none of the changes planned for 2.0 for a long time.

is easy to migrate plug-ins and scripts. Apart from libgimp and some basic core functionality, the whole thing has been completely rewritten.

Well, if that would be all, then there would be no reason to upgrade for users at all, as nothing has changed for them.

On Wed, 18 Jun 2003 11:58:06 +0200, Sven Neumann wrote:

Frankly, I won't be oposed very much to calling it gimp-2.0, but everybody is expecting some _major_ release for 2.0, and 1.2 => 2.0, while having many enhancements, is not, in my opinion, much bigger than the 1.0 => 1.2 jump.

You obviously didn't look at the code. Frankly, the libgimp API hasn't changed much but that's probably a good thing t'since it means that it is easy to migrate plug-ins and scripts. Apart from libgimp and some basic core functionality, the whole thing has been completely rewritten.

Yesterday, I was in favor of 2.0, but now I am not sure anymore. Marc and the others are right to some extent: from a user's point of view, the changes in 1.3 compared to 1.2 are about as big as the changes from 1.0 to 1.2.

From a developer's point of view, a lot of things have changed. Many

parts of the code have been rewritten. But from a user's point of view, the visible differences are not that big.

Reasons for calling it 2.0: - GTK+ is at 2.2 (maybe 2.4 by the time the next GIMP is out), so we would at least get the same major release number even if the minor number is different.
- This reflects the amount of changes that occured in the code (from a developer's point of view).

Reasons for calling it 1.4: - Many users expect 2.0 to include support for 16-bit channels, CMYK, better color calibration, layer trees/masks/styles, and several other features. This information has been published on various web sites and even printed in some magazines. - The original plan was that 1.4 would consist in a re-write and clean-up of the code without introducing too many user-visible changes. In fact, except for the timing and the part about the distribution of plug-ins, the original plan is still a good description of 1.3.x.
- The user-visible changes in this version are comparable to the transition from 1.0 to 1.2 (user's point of view)

-Raphaël

On 18 Jun 2003, at 13:04, Sven Neumann wrote:

The switch from GTK+-1.2 to 2.0 was a lot smaller than what we have to offer for GIMP now.

IMHO, Guillermo Romero's suggestion of making it 1.6 or 1.8 is a nice compromise.

On 2003-06-18 at 1218.44 +0200, Tino Schwarze typed this:

On Wed, Jun 18, 2003 at 11:58:06AM +0200, Sven Neumann wrote:

Well, all the agruments I see in favour of 2.0 are always of the form "well, evereybody else has 2.0". Well, gtk+2 is at 2.2, msoffice is at 2003 etc..

I give shit on msoffice but GTK+ is the GIMP ToolKit and we will have a hard time to explain why even it's major release numbers diverge.

I don't think we'd need to explain anything. GIMP 1.4 depends on GTK2. Period. In some way, it's separate software. It's not distributed with The GIMP, it just happens to be called "The GIMP ToolKit" for historical reasons. ;-)

i was assured that as long as Owen Taylor was involved it would always be The GIMP Tool Kit.

was i misinformed about this?

carol

Sven Neumann wrote:

If you think that the GTK+ menu system needs improvement, it's probably best to involve the GTK+ developers.

yes.

What about proposing
your changes on the gtk-devel list?

will do.

As far as I know, the gimp2 CVS module is dead. I'm not sure if it makes sense to revive it. Especially since the code that is probably going to become 2.0 lives in module gimp.

you should document that more publicly then. searching for 'gimp development path' didn't provide any of that information.

so, you mean there is not going to be any rewrite-from-scratch? or that when there is it will be numbered eg 3.x?

Date: Wed, 18 Jun 2003 13:10:26 +0200 From: =?ISO-8859-1?Q?Rapha=EBl?= Quinet

Reasons for calling it 2.0: - GTK+ is at 2.2 (maybe 2.4 by the time the next GIMP is out), so we would at least get the same major release number even if the minor number is different.

IMHO, this is not a good reason for numbering it 2.0. By now, GTK+ stands independently of the GIMP; it's maintained by different people, the releases aren't synchronized, and indeed (even in 1.2) the GIMP has its own widget set layered on top of GTK+. Whatever the origins of the name, at present GTK+ is no more "the GIMP toolkit" than Gimp-Print is "the Print plug-in for the GIMP".

On 06/18/03 07:37, Sven Neumann wrote:

"Branko Collin" writes:

IMHO, Guillermo Romero's suggestion of making it 1.6 or 1.8 is a nice compromise.

Hmm, it should be either 1.4 because it's into people's head already or 2.0 because it's worth a major number increase and because of GTK+-2.x. There doesn't seem to be any good argument for 1.6 or 1.8.

I really hate to pollute this discussion further, but I just wanted to, firstly, thank Sven (and everyone else) for all their work on porting the GIMP to GTK2. This was no doubt as much of an effort as going from the 0.5x series to the 0.99.x series.

However, I just wanted to give my opinion from more of an end-user perspective. Firstly, the 1.3 codebase seems to have a lot more polish to it than the current 1.2. But, the feel isn't that different, and I agree that many of the "new features" are bugfixes. Sadly, a lot of the work done upgrading the codebase simply won't empower the end user that much more because the workflow and featureset isn't changed "radically enough" (for lack of a better way to phrase it).

The GIMP isn't much closer to prepress than it was before. It isn't closer to GEGL or Cinepaint, or many of the other much anticipated features. It's (I ceratinly hope) in a better position to do this stuff because of the rewrite, but the end user doesn't see any of that. They just see a few new features and some slicker dialogs. Nothing here is "groundbreaking", as it were.

Now, my personal feelings are those of the user: the new release could certainly be called "1.4" and I wouldn't think the person picking the version number was crazy. If I saw it called "2.0" and I used it, I would think, "Hmm ... that seems like a bit of a stretch". Something of a "clincher" for me is: has the file format changed? If I save an XCF under "1.4" and I can still open it under version 1.2, then it seems more like a point release.

However, why does the GIMP need to follow kernel style version numbers, or GTK version numbers? I also think that "1.5" is a good number. To me this means "This was a major effort, but it's still going to feel or behave like the 1.x series," which I find quite fitting. To say the version should be "2.0" because GTK+ is at version 2 I think is also wrong, because you can't keep these in sync, and there's no reason to try. Toolkits like GTK tend to stabilize and move slowly. When the next version of the GIMP has GEGL and CMYK and custom gamuts and 64bit RGBA with animations and filters to load/save .SWF files, are we going to call it 2.2 simply because GTK+ is still stuck at version 2?

So to summarize, let GTK+ declare whatever versions it wants and let others fixate on even-stable and odd-development cycles; call this thing 1.5, go drink some beer, and come back ready to code up version 1.90 with all the cool core enhancements that'll subsume Cinepaint, POV-Ray, Macromedia, and Photoshop. =)

rgds, Chris

From: Sven Neumann
Date: Thu, 19 Jun 2003 14:15:25 +0200

Robert L Krawitz writes:

> IMHO, this is not a good reason for numbering it 2.0. By now, GTK+ > stands independently of the GIMP; it's maintained by different people, > the releases aren't synchronized, and indeed (even in 1.2) the GIMP > has its own widget set layered on top of GTK+.

Huh? Well, of course we have build widgets on top of the toolkit we use. What are you trying to prove here? I fail to see your point.

> Whatever the origins of the name, at present GTK+ is no more "the > GIMP toolkit" than Gimp-Print is "the Print plug-in for the GIMP".

I don't agree. I do think that GIMP and GTK+ are in fact still more tightly coupled than you receive it. GIMP developers are constantly contributing to GTK+ and they do take part in decisions made for GTK+. At the same time GTK+ developers are giving the GIMP developers a hand when it comes to improving and debugging The GIMP. The two projects are not as diverged as perhaps gimp-print and gimp.

The point of both of these comments is that these two projects are not joined at the hip. They have independent release cycles, and GTK+ itself is considerably more than just a service library for the GIMP (which is why it's necessary to layer other widgets on top of it). Furthermore, from a user standpoint functionality such as CMYK and 16 bits is a lot more interesting than the fact that it's layered on top of GTK+ (very few end users really care if it's based on GTK+, Qt, Xaw, Motif, or whatnot). There may certainly be significant contributions from the GIMP back to GTK+, but that doesn't mean that the entire architecture of the GIMP is inextricably linked to that of GTK+ in the way that, say, KDE is intertwined with Qt (where the version numbers now do match from release to release).

Unless we're talking about a complete rearchitecting of the system (and switching from one version to another of a UI framework doesn't qualify in my book), IMHO internal changes aren't usually a reason to bump the major version number. There should be some really compelling change in the user capabilities in addition to major internal changes.