Hi,

Brion Vibber writes:

After a lot of recompiling, I've managed to get 2.1 running from CVS. It seems to be doing _something_ with the clipboard, but I haven't yet gotten anything resembling an image out of it. Is there any X11-based program known to interoperate with it that I could test with to make sure it's working?

The easiest way to test is to use a second instance of GIMP. Another application that is known to work is the word-processor Abiword.

Here are some links that explain how the X clipboard is supposed to be used:

http://tronche.com/gui/x/icccm/ http://www.jwz.org/doc/x-cut-and-paste.html http://www.freedesktop.org/standards/clipboards-spec/clipboards.txt

GIMP passes image data in the PNG format and announces it using the "image/png" mimetype identifier.

Either Gimp or GTK+ could be hacked up to use the Mac clipboard directly, I suppose. Any opinions on what's the correct place to do this?

It definitely belongs into GTK+ in the long run. Perhaps it would be good to start a GDK backend for MacOS X that is based on the GDK-X11 backend but deals with clipboard and other interoperability issues.

Sven

Hi Brion,

it would be very helpful if you could point us to some documentation about the MacOS X clipboard. I am particularily interested in the formats that are typically used to exchange data using the clipboard.

Sven

Hi,

Brion Vibber writes:

Cocoa apps (those written with the NeXT-derived toolkit) use TIFF for transferring raster images. Older apps (like Photoshop) tend to use PICT, which is a metafile format encapsulating calls to the QuickDraw drawing library. Using the Cocoa NSPasteboard interface, I can copy a TIFF and it performs the conversion to PICT for me, but when pasting I need to handle both formats.

We use gdk-pixbuf to handle the clipboard image data. So far we only use the PNG format but it would be reasonable to extend this to the full range of formats supported by gdk-pixbuf. There's an API that we can use that allows us to retrieve the list of supported formats and the associated mime-types.

There's a tiff loader in GTK+ but no way to save TIFF files. There doesn't seem to be support for PICT (except perhaps in a 3rd party pixbuf loader that I don't know about). So the best way to address this would probably be to write a PICT loader and either get it into GTK+ or bundle it with GIMP for MacOS X.

How is image cut-n-paste handled on Win32? Windows apps use DIB (.bmp) format for clipboard transfer; does the GDK backend handle DIBPNG conversion? I took a quick look around gdkselection-win32.c & friends but didn't see anything obvious.

It would not be the job of the backend to handle the format conversion. The backend only needs to expose the clipboard in a compatible manner (e.g. data with associated mime-types). It's the application's job to handle the actual clipboard data. Of course it would be nice if everyone could agree on using PNG but that's unfortunately not how it works. So in order to use the win32 clipboard we will need to support BMP support in gdk-pixbuf. This is there fortunately but it seems to be limited to reading.

Sven

Hi,

Brion Vibber writes:

The easiest way to test is to use a second instance of GIMP. Another application that is known to work is the word-processor Abiword.

Thanks, it seems to be working on the X11 side. I do sometimes get what looks like an RGBA/ARGB mixup copying from Abiword to Gimp though; I'll try to isolate that and report the bug to the guilty party... :P

I've seen that as well. I suspect it's the GIMP code that still assumes that a GimpBuffer is always RGBA while the clipboard code happily passes it a RGB tile-manager if the PNG data doesn't have an alpha channel. I am just not sure where this would best be fixed. We need to either remove that assumption or add an alpha channel when converting the pixbuf to a tile-manager.

Sven

Brion Vibber writes:
> How is image cut-n-paste handled on Win32? Windows apps use DIB (.bmp) > format for clipboard transfer; does the GDK backend handle DIBPNG > conversion? I took a quick look around gdkselection-win32.c & friends > but didn't see anything obvious.

There is a (Windows-specific) GIMP plug-in that does the "paste from (Windows) Clipboard" and "copy to Clipboard". That code probably should move to GTK+. (I doubt it's straightforward, though, so it hardly will get done in GTK+ 2.6.)

--tml

Hi,

Tor Lillqvist wrote:

There is a (Windows-specific) GIMP plug-in that does the "paste from (Windows) Clipboard" and "copy to Clipboard". That code probably should move to GTK+. (I doubt it's straightforward, though, so it hardly will get done in GTK+ 2.6.)

What is the state of support for the GDK clipboard in the win32 backend? Michael reported that he can't even copy and paste image data from one GIMP instance to the other on Win32. Would that be supposed to work?

Sven

Sven Neumann writes:
> What is the state of support for the GDK clipboard in the win32 > backend?

For the *GDK* clipboard only cut&paste of text is supported. The winclipboard plug-in uses the Windows clipboard directly.

> Michael reported that he can't even copy and paste image data > from one GIMP instance to the other on Win32. Would that be supposed > to work?

Yes it does work. (Although I now notice that it always copies the whole drawable to the Windows clipboard, not just the selection as one would expect).

--tml

Hi,

Tor Lillqvist writes:

Sven Neumann writes:
> What is the state of support for the GDK clipboard in the win32 > backend?

For the *GDK* clipboard only cut&paste of text is supported. The winclipboard plug-in uses the Windows clipboard directly.

> Michael reported that he can't even copy and paste image data > from one GIMP instance to the other on Win32. Would that be supposed > to work?

Yes it does work. (Although I now notice that it always copies the whole drawable to the Windows clipboard, not just the selection as one would expect).

I was actually asking about the newly added support for the system clipboard which is supposed to obsolete the winclipboard plug-in. Well, you basically answered that above. So the answer is that it is _not_ supposed to work :( This is rather unfortunate. When I started to implement the GDK clipboard functionality I was hoping there was better support for it in the win32 GDK backend.

Sven