DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New] Link: http://www.fltk.org/str.php?L2277 Version: 1.3-current Rxvt use primary buffer, do not recognize clipboard buffer. And ^V/^C is prepared for other function in the terminal. Thanks for the clue. I guess it is. 1. I can use xsel to add the string to primary buffer in rxvt window and paste it to fltk-1.3 based program on condition that the string is in utf8 encoding: echo "some GBK string" |iconv -f gbk -t utf8 |xsel -i -p 2. Pasting from rxvt-unicode works. It seemed that fltk-1.3 do not handle locale XA_STRING, XA_TEXT correctly. The multi-bytes pasted in other encoding will be ignored directly by fltk-1.3 before further processing for the atom name? fltk-1.3.x only support UTF8_STRING? That is to say, I can't implement the support to the pasting from rxvt in user-level? I find some code in fltk-2.x's x11/run.cxx, which is similar but different from Fl_x.cxx at fltk-1.3's source code: if (!selection_length[clipboard]) { e.property = 0; } else if (e.target == TARGETS) { Atom a[3] = {UTF8_STRING, XA_STRING, XA_TEXT}; XChangeProperty(xdisplay, e.requestor, e.property, XA_ATOM, 32, 0, (unsigned char*)a, 3); } else if (e.target == UTF8_STRING || e.target == XA_STRING || e.target == XA_TEXT || e.target == textplain || e.target == textplainutf) { // clobber the target type, this seems to make some applications // behave that insist on asking for XA_TEXT instead of UTF8_STRING // Does not change XA_STRING as that breaks xclipboard. if (e.target != XA_STRING) e.target = UTF8_STRING; XChangeProperty(xdisplay, e.requestor, e.property, e.target, 8, 0, (unsigned char *)selection_buffer[clipboard], selection_length[clipboard]); } else { e.property = 0; } Link: http://www.fltk.org/str.php?L2277 Version: 1.3-current _______________________________________________ fltk-bugs mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-bugs
