Re: [Gimp-developer] preview widgets, wiedermal
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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] preview widgets, wiedermal
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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] preview widgets, wiedermal
Hi, Quoting William Skaggs [EMAIL PROTECTED]: 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. -- Dave Neary Lyon, France ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] preview widgets, wiedermal
Dave Neary wrote: 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? No, unfortunately. Really my motivation is that I want to add previews to a few plug-ins, and feel like I would be wasting my time if I do it before there is a policy in place. So I am just trying to promote settling this in any way I can. 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. (It is GPL'ed, and almost follows the Hackordnung. It is also very well documented.) But really I can live with any policy, even one that says that each plug-in should handle previewing on its own. Best, -- Bill __ __ __ __ Sent via the KillerWebMail system at primate.ucdavis.edu __ __ __ __ Sent via the KillerWebMail system at primate.ucdavis.edu ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] preview widgets, wiedermal
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. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] preview widgets, wiedermal
Hi, David Neary [EMAIL PROTECTED] 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] preview widgets, wiedermal
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. 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. Best, -- Bill __ __ __ __ Sent via the KillerWebMail system at primate.ucdavis.edu ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
