On 12/31/2013 06:36 PM, Marco Ciampa wrote:

Presumably how far are we to the new 2.10 gimp version? How many blocking bugs are left and what are these?

thanks and happy GNU year...

Will it really be 2.10? Its internals are different, the file format is different (will 2.8 be able to load 16/32/FP files saved by the next version?), and it looks like many plugins won't work anymore and will need seroius rework... If it goes public, calling it Gimp 3.0 will makes things a lot easier to explain to newcomers.

On Wed, Jan 1, 2014 at 2:26 AM, Ofnuts wrote:

Will it really be 2.10?

Yes.

Alexandre

On 12/31/2013 11:35 PM, Alexandre Prokoudine wrote:

On Wed, Jan 1, 2014 at 2:26 AM, Ofnuts wrote:

Will it really be 2.10?

Yes.

Bad decision, then...

01 . 2014 . 4:12 "Ofnuts" :

On 12/31/2013 11:35 PM, Alexandre Prokoudine wrote:

On Wed, Jan 1, 2014 at 2:26 AM, Ofnuts wrote:

Will it really be 2.10?

Yes.

Bad decision, then...

There's no pleasing you, is there? :)

You don't even know how much incompatible 2.8 and 2.10 will be, but you've already figured out what kind of decision it will be. That's quite spectacular :)

Alexandre

31 . 2013 . 21:36 "Marco Ciampa" :

Presumably how far are we to the new 2.10 gimp version?

Nobody knows.

How many blocking bugs are left and what are these?

Last night we discussed we need some sort of todo to keep track of things we need to do (on top of bugzilla, that is).

So the answer right now is that there is no simple answer :)

Do we need a complete port of plugins to GEGL? Yes. There is the porting matrix in the wiki to look at.

Do we need GEGL-based GIMP to be fast enough for production? Yes. Is there a list of things to do in order to achieve that? Not yet. Please ask specific questions :) That will also help us to formalize further plans.

Alexandre

On 31 December 2013 23:26, Ofnuts wrote:

On 12/31/2013 06:36 PM, Marco Ciampa wrote:

Presumably how far are we to the new 2.10 gimp version? How many blocking bugs are left and what are these?

thanks and happy GNU year...

Will it really be 2.10? Its internals are different, the file format is different (will 2.8 be able to load 16/32/FP files saved by the next version?), and it looks like many plugins won't work anymore and will need seroius rework...

Which plugins do you expect not to work anymore, and why?

2.8 will not be able files from 2.10 using new features (naturally). I believe files produced with 2.10 which _does not_ make use of 2.10-only features can be opened in 2.8. Correct me if I am wrong. 2.10 will be able to open all 2.8 files, of course.

Jon Nordby - www.jonnor.com

On Wed, Jan 1, 2014 at 6:10 PM, Jon Nordby wrote:

I believe files produced with 2.10 which _does not_ make use of 2.10-only features can be opened in 2.8. Correct me if I am wrong. 2.10 will be able to open all 2.8 files, of course.

If you try that, GIMP 2.8 will tell you it doesn't support XCF v5 files.

Alexandre

On 01.01.2014 15:21, Alexandre Prokoudine wrote:

On Wed, Jan 1, 2014 at 6:10 PM, Jon Nordby wrote:

I believe files produced with 2.10 which _does not_ make use of 2.10-only features can be opened in 2.8. Correct me if I am wrong. 2.10 will be able to open all 2.8 files, of course.

If you try that, GIMP 2.8 will tell you it doesn't support XCF v5 files.

Maybe we can get the new versions into https://git.gnome.org/browse/gimp/tree/devel-docs/xcf.txt

Regards,
Michael
GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD

On Wed, 2014-01-01 at 15:27 +0100, Michael Schumacher wrote:

On 01.01.2014 15:21, Alexandre Prokoudine wrote:

On Wed, Jan 1, 2014 at 6:10 PM, Jon Nordby wrote:

I believe files produced with 2.10 which _does not_ make use of 2.10-only features can be opened in 2.8. Correct me if I am wrong. 2.10 will be able to open all 2.8 files, of course.

If you try that, GIMP 2.8 will tell you it doesn't support XCF v5 files.

Maybe we can get the new versions into https://git.gnome.org/browse/gimp/tree/devel-docs/xcf.txt

Indeed, will look into it, because I also did the file format changes.

--Mitch

On 01/01/2014 03:10 PM, Jon Nordby wrote:

On 31 December 2013 23:26, Ofnuts wrote:

On 12/31/2013 06:36 PM, Marco Ciampa wrote:

Presumably how far are we to the new 2.10 gimp version? How many blocking bugs are left and what are these?

thanks and happy GNU year...

Will it really be 2.10? Its internals are different, the file format is different (will 2.8 be able to load 16/32/FP files saved by the next version?), and it looks like many plugins won't work anymore and will need seroius rework...

Which plugins do you expect not to work anymore, and why?

OK, maybe I'm pessimistic here, even if some of my python scripts had to be reworked between 2.6 and 2.8, which have far less differences than 2.8 and 2.10. Then in the current API there are still many values with 0-255 ranges (gimp-drawable-{get|set}-pixel (),gimp-histogram) for instance. So either there is absolutely no change in the API and the script may produce sub-optimal results in images with high bit depth, or there is some change and the script has to be reworked and may be made bimodal or forked to support 2.8 and 2.10.

2.8 will not be able files from 2.10 using new features (naturally). I believe files produced with 2.10 which _does not_ make use of 2.10-only features can be opened in 2.8. Correct me if I am wrong. 2.10 will be able to open all 2.8 files, of course.

In the usual V.R.M numbering, the situation above is typically when you change the version number (and maybe the file extension)... because my point here is not the (completely understandable) incompatibilities, it their understatement by calling the next version 2.10.

On 31 December 2013 23:26, Ofnuts wrote:

it looks like many plugins won't work anymore and will need seroius rework...

On 01/01/2014 03:10 PM, Jon Nordby wrote:

Which plugins do you expect not to work anymore, and why?

I'm sure this isn't what Ofnuts was talking about, but I've noticed that with git master gimp and the xsane plug-in that's in Debian sid, I have to dismiss a deprecation warning dialog for every page I scan, which is rather annoying since it messes with window focus. I don't get the warning in 2.8. (Sorry to be so nonspecific -- my scanner is packed away right now so I can't easily regenerate the warning, but if deprecation dialogs are unexpected I'd be happy to chase down the details and file a bug.)

Obviously this isn't a "won't work any more" nor is it "serious rework" -- scans still work, and it's probably just a one-line change to xsane to make the warning go away. (I've hit some deprecation warnings in my own plug-ins, and fixing them is always very easy.) But it is an annoyance when using a pre-compiled plug-in, so I switched back to 2.8 for scanning.

It is kind of a shame that GIMP shows a dialog every time for deprecations ... might be nicer if it could show it once then be quiet about it for the rest of the session, since it's not something the user can do anything about.

...Akkana

OK, maybe I'm pessimistic here, even if some of my python scripts had to be reworked between 2.6 and 2.8, which have far less differences than 2.8 and 2.10. Then in the current API there are still many values with 0-255 ranges (gimp-drawable-{get|set}-pixel (),gimp-histogram) for instance. So either there is absolutely no change in the API and the script may produce sub-optimal results in images with high bit depth, or there is some change and the script has to be reworked and may be made bimodal or forked to support 2.8 and 2.10.

If the PDB/Python API is to support even the majority of the new functionalities, i t will need
a lot of additions/rethink. And it is not only on the Python side. On the other hand, It would not be nice to add a lot of new calls to the API for 2.10, and get those invalidated by the transition to a GIMP 3.0 afterwards, so we better have some care in picking the new calls.

When working from Python code, the ideal direction to go is easy to imagine: to have a couple PDB calls to get a GEGL buffer (or source node) returned from GIMP, and then using GEGL-based code to perform the actual image operations, and return a node, or buffer back to GIMP.

That way, one won't need to rewrite every PDB call to support several pixel formats, and that would be valid only for GIMP 2.10.

On the other hand, it is not currently easy to use GEGL bindings to the Python linguage -
due to tha fact that all binding is delegated to be auto-generated by gobject introspection, which in, its turn, is only maintained for glib3, gtk+3 - (while GEGL is tied to glib2).

I could get it working, more or less here - some calls simply crash - and started a small project to wrap the g.i. automatically generated objects ito things friendler to the Python developer (check https://github.com/jsbueno/python-gegl), but that depends that one sets-up g.i. and pygobject, correctly previously. And these projects branchs to support glib2 are apparently unmaintained, and had already bit-rot a bit. (If someone can get pygobject working cleanly with GEGL, please do tell me and say which versions you have used)

Still, I maintain that, at least for a Python API, that would be the better way to go - we'd have to either "unrot" pygobject + gegl bindings, or find another route to use GEGL from Python that would be api-compatible to pygobject + gegl on glib3.

(So that is also my "what is missing before 2.10" in what concerns automating GIMP via Python)

js ->

On Wed, 2014-01-01 at 19:10 -0800, Akkana Peck wrote:

On 31 December 2013 23:26, Ofnuts wrote:

it looks like many plugins won't work anymore and will need seroius rework...

On 01/01/2014 03:10 PM, Jon Nordby wrote:

Which plugins do you expect not to work anymore, and why?

I'm sure this isn't what Ofnuts was talking about, but I've noticed that with git master gimp and the xsane plug-in that's in Debian sid, I have to dismiss a deprecation warning dialog for every page I scan, which is rather annoying since it messes with window focus. I don't get the warning in 2.8. (Sorry to be so nonspecific -- my scanner is packed away right now so I can't easily regenerate the warning, but if deprecation dialogs are unexpected I'd be happy to chase down the details and file a bug.)

These warnings appear by default in unstable but do not appear in stable, and you can control them via a command line switch.

Obviously this isn't a "won't work any more" nor is it "serious rework" -- scans still work, and it's probably just a one-line change to xsane to make the warning go away. (I've hit some deprecation warnings in my own plug-ins, and fixing them is always very easy.) But it is an annoyance when using a pre-compiled plug-in, so I switched back to 2.8 for scanning.

It is kind of a shame that GIMP shows a dialog every time for deprecations ... might be nicer if it could show it once then be quiet about it for the rest of the session, since it's not something the user can do anything about.

See above.

--Mitch

On Thu, 2014-01-02 at 00:48 +0100, Ofnuts wrote:

On 01/01/2014 03:10 PM, Jon Nordby wrote:

On 31 December 2013 23:26, Ofnuts wrote:

On 12/31/2013 06:36 PM, Marco Ciampa wrote:

Presumably how far are we to the new 2.10 gimp version? How many blocking bugs are left and what are these?

thanks and happy GNU year...

Will it really be 2.10? Its internals are different, the file format is different (will 2.8 be able to load 16/32/FP files saved by the next version?), and it looks like many plugins won't work anymore and will need seroius rework...

Which plugins do you expect not to work anymore, and why?

OK, maybe I'm pessimistic here, even if some of my python scripts had to be reworked between 2.6 and 2.8, which have far less differences than 2.8 and 2.10. Then in the current API there are still many values with 0-255 ranges (gimp-drawable-{get|set}-pixel (),gimp-histogram) for instance. So either there is absolutely no change in the API and the script may produce sub-optimal results in images with high bit depth, or there is some change and the script has to be reworked and may be made bimodal or forked to support 2.8 and 2.10.

I did a really quick look at all non-deprecated PDB functions and came up with a very short list (I'm sure some are missing, but it's a harmless list that remains to be done):

limited range:

gimp-brightness-contrast gimp-curves-explicit
gimp-curves-spline
gimp-drawable-set-pixel
gimp-drawable-get-pixel
gimp-levels

limited range unclear:

gimp-color-balance gimp-posterize

missing:

gimp-buffer-get-format

2.8 will not be able files from 2.10 using new features (naturally). I believe files produced with 2.10 which _does not_ make use of 2.10-only features can be opened in 2.8. Correct me if I am wrong. 2.10 will be able to open all 2.8 files, of course.

In the usual V.R.M numbering, the situation above is typically when you change the version number (and maybe the file extension)... because my point here is not the (completely understandable) incompatibilities, it their understatement by calling the next version 2.10.

It's called 2.10 because it's binary and source compatible to 2.x. We did not remove any functions, we only deprecated. That's the only thing that counts, not how much has changed behind the public API.

It's going to be called 2.10, you can stop arguing.

--Mitch

On 2 January 2014 16:05, Michael Natterer wrote:

On Thu, 2014-01-02 at 00:48 +0100, Ofnuts wrote:

In the usual V.R.M numbering, the situation above is typically when you change the version number (and maybe the file extension)... because my point here is not the (completely understandable) incompatibilities, it their understatement by calling the next version 2.10.

It's called 2.10 because it's binary and source compatible to 2.x. We did not remove any functions, we only deprecated. That's the only thing that counts, not how much has changed behind the public API.

This means that plugins/scripts that worked in 2.8 should work in 2.10 and if things break it is considered a bug. So please report such issues in bugzilla!

Jon Nordby - www.jonnor.com

On 2 January 2014 15:04, Joao S. O. Bueno

On the other hand, it is not currently easy to use GEGL bindings to the Python linguage -
due to tha fact that all binding is delegated to be auto-generated by gobject introspection, which in, its turn, is only maintained for glib3, gtk+3 - (while GEGL is tied to glib2).

I could get it working, more or less here - some calls simply crash - and started a small project to wrap the g.i. automatically generated objects ito things friendler to the Python developer (check https://github.com/jsbueno/python-gegl), but that depends that one sets-up g.i. and pygobject, correctly previously. And these projects branchs to support glib2 are apparently unmaintained, and had already bit-rot a bit. (If someone can get pygobject working cleanly with GEGL, please do tell me and say which versions you have used)

First of all, there is no glib3. The relevant incompatibilities here are (as I understand).
1) One cannot combine pygobject-2.0 with pygobject-3.0 (crashes horribly). 2) GTK+2 is not well supported by gobject introspection, and never will be. 3) PyGTK (the Python bindings for GTK+2) cannot be combined with PyGI.

In practice this means, one can only use GEGL from Python in programs which does not use GTK+2 (GTK+3 is fine). Is this a problem for GIMP 2.10 (do Python plugins run in-process)? These are my experiences from experimenting with using GEGL in MyPaint, and working on GEGL-GTK.

Jon Nordby - www.jonnor.com