Re: Clipboard (was Re: [Gimp-developer] Screenshot plug-in status)
Nick Lamb wrote: On Fri, Sep 12, 2003 at 12:38:26PM +0200, Sven Neumann wrote: Oh, will you? I am sorry but if I remember correctly we postponed this until after 2.0 since we hope that until then there well be an accepted Free Desktop standard for this. Our prefered solution would be to offer the image data as image/png and so far there seems to be consensus that this is a good choice. I had hoped to spend time on this before 2.0 pre1, but that's not going to happen now. And it does kind of break the feature freeze. But it shouldn't be a huge packet of code. Any Free Desktop standard for routine image clipboard handling seems to have been overtaken by events. There might still be room for some discussion about hi-resolution or hi-precision graphics, but for the average user the de facto standard is already set and since there's nothing obviously wrong with it we can move on from there. X content negotation lets us change our minds later, and GIMP's plug-in architecture lets us make this modular if we decide that's necessary... I'm not aware of any de facto standard - how does kde pass image data around? The only clipboard standard I know of is the one on freedesktop which says Explicit copy - use SECONDARY, and keeps the selected buffer = PRIMARY as an easter egg which isn't really going to be used much in future. There is no standard for image data interchange that I know of, and I did have a look. Is there any engineering reason why this shouldn't happen prior to 2.0, assuming the spirit of Free Time is on our side? That's a fairly big assumption :) 2.0 pre 1 (which will be absolutely string feature frozen to give translators, documentors and the like time to clean up before 2.0) is planned for a fortnights time. There are only 2 or 3 blockers left for that release, and they're all pretty small. So the spirit of Free Time is the biggest problem I see with it :) It would be nice if we did this in a way which would interoperrate with other apps, though - which is why using image/png is so attractive. Even if we were to use something else between different gimp instances, we get to communicate with everyone who understands png. As to freedesktop, as I said I'm not aware of any standard (de facto or otherwise) - I had planned to write up a proposal to use as the basis of a freedesktop proposal after 2.0 pre1 gets out the door. But if you implement something in the meantime, there shouldn't be any problem getting it in, as long as it's feature complete and fairly clean (as Sven said). 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: Clipboard (was Re: [Gimp-developer] Screenshot plug-in status)
Hi, David Neary [EMAIL PROTECTED] writes: That's a fairly big assumption :) 2.0 pre 1 (which will be absolutely string feature frozen to give translators, documentors and the like time to clean up before 2.0) is planned for a fortnights time. There are only 2 or 3 blockers left for that release, and they're all pretty small. If your plan is to do a complete string freeze, I see a couple more than 2 or 3 blockers. But yes, we should try to avoid changes to translatable messages when the time has come for the prereleases. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: Clipboard (was Re: [Gimp-developer] Screenshot plug-in status)
Hi, Nick Lamb [EMAIL PROTECTED] writes: It should work that way but I haven't been able to build The GIMP to check for ages now. To be completely clear: Edit/Cut, Copy and Paste _ought_ to transparently work between applications. The image-related KDE apps get this right and when GIMP 1.3.x devel code is once again up and running on this system I will ensure that it works properly in the GIMP too. Oh, will you? I am sorry but if I remember correctly we postponed this until after 2.0 since we hope that until then there well be an accepted Free Desktop standard for this. Our prefered solution would be to offer the image data as image/png and so far there seems to be consensus that this is a good choice. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: Clipboard (was Re: [Gimp-developer] Screenshot plug-in status)
On Fri, Sep 12, 2003 at 12:38:26PM +0200, Sven Neumann wrote: Oh, will you? I am sorry but if I remember correctly we postponed this until after 2.0 since we hope that until then there well be an accepted Free Desktop standard for this. Our prefered solution would be to offer the image data as image/png and so far there seems to be consensus that this is a good choice. Any Free Desktop standard for routine image clipboard handling seems to have been overtaken by events. There might still be room for some discussion about hi-resolution or hi-precision graphics, but for the average user the de facto standard is already set and since there's nothing obviously wrong with it we can move on from there. X content negotation lets us change our minds later, and GIMP's plug-in architecture lets us make this modular if we decide that's necessary... Is there any engineering reason why this shouldn't happen prior to 2.0, assuming the spirit of Free Time is on our side? Nick. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: Clipboard (was Re: [Gimp-developer] Screenshot plug-in status)
Hi, Nick Lamb [EMAIL PROTECTED] writes: Any Free Desktop standard for routine image clipboard handling seems to have been overtaken by events. There might still be room for some discussion about hi-resolution or hi-precision graphics, but for the average user the de facto standard is already set and since there's nothing obviously wrong with it we can move on from there. Sorry, but what is, in your opinion, the de facto standard? Is there any engineering reason why this shouldn't happen prior to 2.0, assuming the spirit of Free Time is on our side? It would break the feature freeze but since we aren't yet handling the freeze very strictly and since we actually wanted to have this in 2.0, a clean patch that arrives before the end of the month could probably still be considered. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
