GNOME Bugzilla – Bug 118507
Support C&P using the clipboard
Last modified: 2004-12-22 21:47:04 UTC
Currently it is not even possible to copy & paste data from one gimp instance to another on the same machine. It is,n however, possible to copy an image in a web-page in Mozilla and paste it into a; OpenOffice writer document. It would be nice if the GIMP sued the X clipbopard, and perhaps even worked with other apps to have a standard clipboard format for swapping image data between apps. Anyone know how this is done in the Win32 world? I can Alt-PrintScr to do a window grab, and then Ctrl-V into outlook, word or any other application that can embed images, and it Just Works. It would be nice to be this flexible everywhere. Cheers, Dave.
GTK+/GDK needs to handle the platform issues, we would just use GDK functions.
Seriously, this a bug. OTOH, this is only a problem on X; the native windows version has a workaround using a plugin. I think that that is an acceptable solution. Do the gdk maintainers think that this functionality belongs in gdk? What do the gnome people do?
AFAIK the functionality needed is in GDK. It's just a matter of deciding how to pass the image data around. Perhaps freedesktop.org has something about this?
Comment I mistakenly added to bug #111082: --- I haven't seen anything on freedesktop. Perhaps we could propose a serialised/deserialised TempBuf? It seems to me that it would be a very basic "chunk of data with header" - I guess we would need some way to identify it as image data so that text apps didn't barf, but I don't see any problems with that. It might even become a FreeDesktop standard... Just had a couple of thoughts. It should support flat RGB(A) and greyscale(A) data, with up to 32 bits per channel (IEEE floats - it would be nice to interoperate with CinePaint). So something of a SuperTempBuf, then... Copying indexed data should result in a conversion to RGB. Cheers, Dave.
What about using a PNG? Wouldn't support all the things your super tempbuf would support but I guess that will have to wait until a proper file-format for such images exists.
Why bother with a file format? it's a copy & paste - shouldn't we keep it as simple as possible? If space is an issue, then png might be something to consider later on. But I don't think we should use something broken-by-design. tiff is probably a better idea, if we ever support loading/saving 16bpp. But even then, it doesn't support floating point... I propose we use something like this: Header: Magic Value to indicate we're image data Width Height Depth (enum, RGB, RGBA, GRAY, GRAYA, possibly other colourspaces could be supported, but not by us) Data type (enum, UCHAR8, UCHAR16, FLOAT16, FLOAT32) Data: width*height*(bytes per pixel for data type) bytes And we're done. If we really need to compress the image data, we can. But I don't see a need yet... Actually, a format like this for brushes and patterns mightn't be a bad idea if we want to start bridging the gap with CinePaint. Cheers, Dave.
PNG is the de-facto standard for exchange of image formats. All desktop specs use it whereever possible. IMO it would be very bad to design our own file format here. The brush and pattern formats are akward and so is every attempt to serialize a Tempbuf. TIFF is broken by design since it allows way too many extensions to be properly supported. PNG is simple, well defined and available everywhere.
The good thing about using a standard format such as PNG is that we don't need to introduce a new mime-type and all applications out there instantly have a chance to understand the data we are offering in the clipboard. IMO, designing a new format for this is the worst mistake we could possibly make.
As you say, png doesn't support a number of things which would permit interoperability. As such, it is not suitable. It is a de facto standard for 8 bits per channel RGB(A) and indexed palette images. Not for image interchange in general. It doesn't support other colourspaces, so cutting & pasting data other than rgb will be a nightmare, and it doesn't support floating point. So we need something else. How are the brush & pattern formats awkward? Shouldn't we try to improve them? This isn't a roll-your-own fileformat reall- it's simply raw data with a minimal header - we could use ppm if it supported the bitdepths we should have. But it doesn't. So I don't see any other solution :) And as for mime types - this is clipboard information, meant to be temporary. So I don't understand where the mime type comes into it - there is never going to be an application browsing the clipboard, and at Paste time, how does the mime type get read? I guess I just don't understand this aspect of your difficulties... Cheers, Dave.
I think you just don't understand how the clipboard works. When you copy data, you announce the availibility of data described by a mime-type. PNG fits our needs perfectly since all we need at the moment is RGB and GRAY data. As soon as we have other image formats, we can simply use another mime-type. But we should always use a standard format, not something home-brewn that only The GIMP understands. Introducing new formats should be avoided whenever possible and I don't see any good reason to do this here.
Just to clarify: Gimp can offer the selection content in multiple formats, so it could offer PNG and another "high-precision" format at the same tame and the target application decides which one it wants to have. I very much like the idea of PNG.
OK - for interoperability, RGBA 32 png it is. For consistency, I suppose we should also use the PRIMARY clipboard atom when there is a Selection active, and copy it to CLIPBOARD when an explicit Copy is called. It'd be nice to see this for 2.0, but 2.2 will be time enough. If someone wants to do it, they can fire ahead and we'll accept it any time before the 10th :) Cheers, Dave.
Just a quick heads-up -- is this still on the radar for 2.2? Is there something I can help? -- I'm not familiar with the innards of the GIMP, I only maintain the packages for Fedora Core ;-).
This is fully implemented in CVS. Closing as FIXED.
Any hints where too look for the changes for eventual backporting?
No. Simply because we don't want to see any new features backported to gimp-2.0.