Hi,

"William Skaggs" writes:

With the coming of summer and hints of a feature freeze for 2.2 starting to shadow the horizon, one of the things I see as most important to get into the code is some kind of preview widget.

Actually it is not so important to establish the code as to establish the API. The specific implementation can continue to be polished, or even changed radically, after the code goes into libgimpwidgets, but plug-in maintainers need to know how to invoke it.

A few plug-ins should be ported. Designing an API w/o actually using it can work out but it can also fail badly.

I know that everybody dreads another go-around on this topic, but it really needs to happen in the near future. Maybe, since it has proven so difficult to come to a consensus by email, this can be put on the list as something to be settled at GimpCon.

That would only make sense if the people willing to work on would be at GimpCon. So far it looks like you and Geert are the ones who are willing to hack on this. Geert has attached a patch here:

http://bugzilla.gnome.org/show_bug.cgi?id=144759

Sven

Hi,

Quoting William Skaggs :

I know that everybody dreads another go-around on this topic, but it really needs to happen in the near future. Maybe, since it has proven so difficult to come to a consensus by email, this can be put on the list as something to be settled at GimpCon.

To my knowledge, Ernst (who has written the only preview widget currently out there) won't be at the conference. David Odin will be, though - and he had started working on a preview widget before the 2.0 release, but hasn't had time since then to work on the GIMP.

Does this mean that you're going to be in Norway?

Cheers, Dave.

Hi Bill,

William Skaggs wrote:

My personal feeling is that it would be best to work from the preview widget developed by Shawn Amundson and Ernst Lippe. It certainly has some issues, but I think they are fixable, and it would be a shame to waste the huge amount of effort Ernst put into it. I've been working with Ernst's code, and can put it into CVS if that would be useful.

I agree with you on this. And currently the blockage to Ernst's code getting committed seems more personality than technical. I'm not sure what Sven thinks of committing this into the main CVS, perhaps you could attach your modified version of Ernst's widget to the relevant bugzilla report, so that we can have a look at it?

It would certainly be worth getting the few people who have been working on this (yourself, Geert, David Odin and Ernst) into a virtual room to hammer out any issues...

Cheers, Dave.

Hi,

David Neary writes:

My personal feeling is that it would be best to work from the preview widget developed by Shawn Amundson and Ernst Lippe. It certainly has some issues, but I think they are fixable, and it would be a shame to waste the huge amount of effort Ernst put into it. I've been working with Ernst's code, and can put it into CVS if that would be useful.

I agree with you on this. And currently the blockage to Ernst's code getting committed seems more personality than technical.

My reasons for not liking the API proposed by Ernst are completely technical. After GIMPCon I will certainly find the time to summarize the problems once more. I am sure we can use quite a lot of the work that Ernst has been doing but I don't think the proposed API should be put into CVS as is. After all it's a public API that we will have to live with for quite some time.

Sven

I'll comment on this one here since I cannot attend the GimpCon.

Splitting up as discussed on the mailinglist before:

1. a completely passive widget that has no other function then to visualize a preview image.

See bugzilla http://bugzilla.gnome.org/show_bug.cgi?id=144759. The API for this one should only contain some primitive functions. And could almost be a drop-in replacement for GtkPreview. This goal should also be fairly easy be reached before next milestone.

2. a more actively involved preview widget would have that uses the first widget and has the basic navigation lets say horizontal and vertical scroll bars.

Reaching a consensus on how this should be accomplished shouldn't be that hard as is the implementation. Probaly can also be reached before next milestone.
Question to ask : How much plugin-in's are covered with this functionality?

3. Other more advanced fearues :

Here I think there are different opinions all driven by the key factors speed / accuracy and type of image. The choice for this should IMO be made for each plugin seperatly. Compromising here is not a good option. I'll try to give some arguments.
- Computer generated images have more likely larger parts with the same pixel values then photograhic images so I would say the plugin's for the first should not be as accurate (risk of beeing flamed). - Stuff like overall collor correction can be done on a scaled down version of the image to gain speed in the preview. - Sharpening should be done at the unscaled version of a image since rescaling it would render the sharpening useless. - Blurring is kind of a problem with small radius this act's more like sharpening while with a large radiuses it's more an overall correction

Geert

I'll comment on this one here since I cannot attend the GimpCon.

Splitting up as discussed on the mailinglist before:

1. a completely passive widget that has no other function then to visualize a preview image.

See bugzilla http://bugzilla.gnome.org/show_bug.cgi?id=144759. The API for this one should only contain some primitive functions. And could almost be a drop-in replacement for GtkPreview. This goal should also be fairly easy be reached before next milestone.

2. a more actively involved preview widget would have that uses the first widget and has the basic navigation lets say horizontal and vertical scroll bars.

Reaching a consensus on how this should be accomplished shouldn't be that hard as is the implementation. Probaly can also be reached before next milestone.
Question to ask : How much plugin-in's are covered with this functionality?

3. Other more advanced fearues :

Here I think there are different opinions all driven by the key factors speed / accuracy and type of image. The choice for this should IMO be made for each plugin seperatly. Compromising here is not a good option. I'll try to give some arguments.
- Computer generated images have more likely larger parts with the same pixel values then photograhic images so I would say the plugin's for the first should not be as accurate (risk of beeing flamed). - Stuff like overall collor correction can be done on a scaled down version of the image to gain speed in the preview. - Sharpening should be done at the unscaled version of a image since rescaling it would render the sharpening useless. - Blurring is kind of a problem with small radius this act's more like sharpening while with a large radiuses it's more an overall correction

Geert

I'll comment on this one here since I cannot attend the GimpCon.

Splitting up as discussed on the mailinglist before:

1. a completely passive widget that has no other function then to visualize a preview image.

See bugzilla http://bugzilla.gnome.org/show_bug.cgi?id=144759. The API for this one should only contain some primitive functions. And could almost be a drop-in replacement for GtkPreview. This goal should also be fairly easy be reached before next milestone.

2. a more actively involved preview widget would have that uses the first widget and has the basic navigation lets say horizontal and vertical scroll bars.

Reaching a consensus on how this should be accomplished shouldn't be that hard as is the implementation. Probaly can also be reached before next milestone.
Question to ask : How much plugin-in's are covered with this functionality?

3. Other more advanced fearues :

Here I think there are different opinions all driven by the key factors speed / accuracy and type of image. The choice for this should IMO be made for each plugin seperatly. Compromising here is not a good option. I'll try to give some arguments.
- Computer generated images have more likely larger parts with the same pixel values then photograhic images so I would say the plugin's for the first should not be as accurate (risk of beeing flamed). - Stuff like overall collor correction can be done on a scaled down version of the image to gain speed in the preview. - Sharpening should be done at the unscaled version of a image since rescaling it would render the sharpening useless. - Blurring is kind of a problem with small radius this act's more like sharpening while with a large radiuses it's more an overall correction

Geert