Clipboard ImageTransfer does not work on Linux x86_64

[Phillipus]

For some time now (13 years) this has not worked on Linux 64-bit:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=283960

While investigating #143 (and using the test snippet there) I took a look at org.eclipse.swt.dnd.ImageTransfer and line 117:

transferData.format = 32;

I simply changed the value to 16 and, voila, it works.

Could this be a simple fix?

[iloveeclipse]

Just push a PR. It is broken anyway, so what could go wrong?

[Phillipus]

Just push a PR. It is broken anyway, so what could go wrong?

OK, but I just wanted to understand what that change actually does, or if there is something else in that chunk of code that could be changed.

public void javaToNative(Object object, TransferData transferData) {
	if (!checkImage(object) || !isSupportedType(transferData)) {
		DND.error(DND.ERROR_INVALID_DATA);
	}
	ImageData imgData = (ImageData)object;
	if (imgData == null) SWT.error(SWT.ERROR_NULL_ARGUMENT);
	Image image = new Image(Display.getCurrent(), imgData);
	long pixbuf = ImageList.createPixbuf(image);
	if (pixbuf != 0) {
		String typeStr = "";
		if (transferData.type ==  JPEG_ID) typeStr = "jpeg";
		else if (transferData.type ==  PNG_ID) typeStr = "png";
		else if (transferData.type ==  BMP_ID) typeStr = "bmp";
		else if (transferData.type ==  EPS_ID) typeStr = "eps";
		else if (transferData.type ==  PCX_ID) typeStr = "pcx";
		else if (transferData.type ==  PPM_ID) typeStr = "ppm";
		else if (transferData.type ==  RGB_ID) typeStr = "rgb";
		else if (transferData.type ==  TGA_ID) typeStr = "tga";
		else if (transferData.type ==  XBM_ID) typeStr = "xbm";
		else if (transferData.type ==  XPM_ID) typeStr = "xpm";
		else if (transferData.type ==  XV_ID) typeStr = "xv";
		byte[] type = Converter.wcsToMbcs(typeStr, true);
		long [] buffer = new long [1];
		long [] len = new long [1];
		if (type == null) return;
		GDK.gdk_pixbuf_save_to_bufferv(pixbuf, buffer, len, type, null, null, null);
		OS.g_object_unref(pixbuf);
		transferData.pValue = buffer[0];
		transferData.length = (int)(len[0] + 3) / 4 * 4;
		transferData.result = 1;
		transferData.format = 32;
	}
	image.dispose();
}

[iloveeclipse]

Just tried - it works fine with gimp, inkskape & kolourpaint!
Also "8" seem to work (used by all other "transfers" in SWT), don't ask me what all this magic means.

The data is used in org.eclipse.swt.dnd.ClipboardProxy.getFunc(long, long, long, long) and is passed to GTK3.gtk_selection_data_set(selection_data, tdata.type, tdata.format, tdata.pValue, tdata.length);

The documentation doesn't say anything useful what the format is : Format (number of bits in a unit)
https://docs.gtk.org/gtk3/method.SelectionData.set.html

What the "unit" should be and why 32 is bad but 8 or 16 not - no idea.

@akurtakov , @sravanlakkimsetti, @SyntevoAlex : any idea?

[Phillipus]

@iloveeclipse Thanks for checking it.

It used to work (maybe still does) with Linux 32-bit. I can't see what difference that would make.

[iloveeclipse]

Found a bit more in old GTK2 tutorial: https://www.cc.gatech.edu/data_files/public/doc/gtk/tutorial/gtk_tut-16.html

16.2 Retrieving the selection
format gives the length of the units (for instance characters) in bits. Usually, you don't care about this when receiving data

16.3 Supplying the selection
The format field is actually important here - the X server uses it to figure out whether the data needs to be byte-swapped or not. Usually it will be 8 - i.e. a character - or 32 - i.e. a. integer.

Still have no idea why 32 isn't working but 8 and 16 are. I guess no one ever understood that documentation and just used 8.

[Phillipus]

If ImageTransfer is still working for 32-bit Linux this change might break that. Perhaps we should check for OS and only set to 16 or 8 if 64-bit? How do we check for OS? Does anyone have 32-bit Linux who can check this?

Scrub that - there is no 32-bit Eclipse.