GNOME Bugzilla – Bug 55152
cannot cut and paste text from gtk to motif 2.1 application.
Last modified: 2011-02-18 15:47:43 UTC
running on an ultra 10 machine with GTK 1.3 installed from CVS Head 23rd May 2001. steps to reproduce: 1] system with Solaris 8/Motif 2.1 app/gtk 1.3 installed 2] have dtpad running (with Motif 2.1 libs) 3] have gtk 1.3 app running (in this case the 'testtext' app that comes as part of the build. 4] write some text into the testtext app. highlight the text, right click and hit the cut option 5] bring the cursoe over to the motif2.1 app (dtpad) and hit the edit -> paste option... nothing happens...you hear a beep and the following is sent to standard out: "testtext (pid:572): Gdk-WARNING **: Error converting from UTF-8 to '646': Conversion form character set 'UTF-8' to '646' is not supported"
Seems to be a portability problem with g_get_charset and Solaris. g_get_charset() is supposed to return a value that g_iconv() [ and hence the native iconv() ] can understand. "646" does not appear to be such a value.
*** Bug 55141 has been marked as a duplicate of this bug. ***
*** Bug 56397 has been marked as a duplicate of this bug. ***
In cut&paste or dnd from gtk+ apps to motif apps, requested target type for text string is CompoundText, first, and then STRING whle it is "UTF-8" and then STRING between two gtk+ applications. The problem is in gdk_string_to_compound_text() function. Upon succeed, this function should return TRUE, but actually not. Below is a patch for gdkselection-x11.c. I verify cut&paste from testtext to dtpad works well after the change, even for the text including some japanese characters. RCS file: /cvs/gnome/gtk+/gdk/x11/gdkselection-x11.c,v retrieving revision 1.17 diff -u -r1.17 gdkselection-x11.c --- gdkselection-x11.c 2001/07/18 04:31:09 1.17 +++ gdkselection-x11.c 2001/07/24 20:36:47 @@ -486,6 +486,7 @@ property.format = None; property.value = NULL; property.nitems = 0; + return FALSE; } if (encoding) @@ -497,7 +498,7 @@ if (length) *length = property.nitems; - return res; + return TRUE; }
need to apply another patch to gtkclipboard.c belo: This is for cut&paste from motif apps to gtk+ apps to try COMPOUND_TEXT affter UTF-8_String and before TEXT: RCS file: /cvs/gnome/gtk+/gtk/gtkclipboard.c,v retrieving revision 1.4 diff -u -r1.4 gtkclipboard.c --- gtkclipboard.c 2001/07/18 22:43:41 1.4 +++ gtkclipboard.c 2001/07/24 22:34:35 @@ -641,11 +641,19 @@ if (!result) { - /* If we asked for UTF8 and didn't get it, try text; if we asked - * for text and didn't get it, try string. If we asked for - * anything else and didn't get it, give up. + /* If we asked for UTF8 and didn't get it, try compound_text; + * text; if we asked for compound_text and didn't get it, try text; + * if we asked for text and didn't get it, try string. If we asked + * for anything else and didn't get it, give up. */ if (selection_data->target == gdk_atom_intern ("UTF8_STRING", FALSE)) + { + gtk_clipboard_request_contents (clipboard, + gdk_atom_intern ("COMPOUND_TEXT", FALSE), + request_text_received_func, info); + return; + } + else if (selection_data->target == gdk_atom_intern ("COMPOUND_TEXT", FALSE)) { gtk_clipboard_request_contents (clipboard, gdk_atom_intern ("TEXT", FALSE),
Created attachment 776 [details] [review] selection with COMPOUND_TEXT b/w Motif apps and gtk+ apps
Note: iconv itself has a known interoperability issue. Solaris native iconv and GNU's libiconv is not compatible in module naming, so if you use native iconv(), gtk+ apps won't work properly. This problem has to be resolved somehow, for instance, by creating certain aliasing mechanism either in Solaris native iconv or in glib.
Created attachment 782 [details] [review] updated patch from yesterday for gdkselection-x11.c
please review the 7/25/01 patch, and let me know if I can commit the patch.
There is no reason to ask for COMPOUND_TEXT, TEXT, than STRING. TEXT is supposed to mean "COMPOUND TEXT if you can supply it, otherwise STRING". If apps are supporting COMPOUND TEXT, but not TEXT, then we should ask first for COMPOUND TEXT then for STRING. (Also note that if we are averaging asking for more than two targets, then we should ask for first TARGETS than the one we ask for. Since GTK+-2.0 => GTK+-2.0 c-n-p is most likely going to be most common, I don't think we are at that point.) As for the other part of the patch, I think the right thing to do is to keep the old (very strange) return values from gdk_string_to_compound_text(), and fix g_utf8_to_compound_text() interpret the result correctly. g_string_to_compound_text() won't be used by any new apps, so I don't want to incompatibly change it - that will just inconvenience existing apps for no good reason. (And the breakage is very hard to cathc.)
Can we remove code to ask apps for TEXT? Then the target to be asked for is UTF8_STRING, COMPOUND_TEXT, then STRING. For the other part, I was not aware that gdk_string_to_compound_text has behaved so since 1.2.x. will fix the caller part. A new patch will be attached for check-in approval again.
Created attachment 863 [details] [review] revised patch incorporting review comment
ok to commit new patch?
Yes, this is OK to commit, with the small formatting change of 'TRUE : FALSE' not 'TRUE:FALSE'.
committed the patch, so mark fixed.
tested this with GTK+ source built from CVS 9th of August 2001 - i highlighted and dragged text from a Java AWT application to/from the testtext GTK+ application, with no success. i tried using the copy and paste buttons on the Sun keyboard, still no success, also tried using the CTRL-V method, with no success.... i then dragged and dropped text to/from a motif2.1 app to/from a Java AWT app - with success, so it's not due to some weird keyboard config....
For Sun's cut/copy/paste keys, See comments and attachment in #58203, You need to create etc/gtk+-2.0/gtkrc. I have not tested with java apps, will try. How about with CDE/Motif apps like dtpad?
just tried dtpad with drag and drop....cannot seem to drag and drop from the testtext application at all....nothing drags.... still getting following error message: testtext (pid:984): Gdk-WARNING **: Error converting UTF-8 to '646': Conversion from character set 'UTF-8' to '646' is not supported this looks kinda like the patch is not in at all...but the build is definitely from 9th August... also just tried copy and paste buttons to/from dtpad and testtext and SunTea (AWT)...nothing works....hmmm...i created the /etc/gtk+-2.0 dir, then populated it with the sample gtkrc file you had in the attachment, then logged out/back into a gnoem session...made no difference...the buttons are not working...this is strange, and would again suggest along with the error message above that the patch did not go in (if you are definitely seeing the bug as fixed)
just checked the changelogs - the patch was built in alright...
Apprantly, glib with GNU libiconv does not provide necessary code conversion modules in many locales on Solaris. In "C", nl_langinfo(CODESET) returns "646", and "ISO8859-1", in en_US locale, but neithere is supported in libiconv, but "ISO-8859-1" is expected. On Solaris, a solution generic and applicable to all the locales should be to use native iconv in libc, instead of libiconv library, with module naming aliasing mechanism proposed in #58195.
With the fixeds checked in with 58195, it should work properly with libiconv now, and might work with native Solaris iconv.
verified the fix with libiconv as well as with native Solaris iconv. Marking the bug "FIXED". gnome_bugs@ireland, please test today's latest cvs head. You may configure glib without --with-libiconv option.
marking verified...on internal build of gtk+ w/motif2.1