From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Jan D." Newsgroups: gmane.emacs.devel,gmane.emacs.gnus.general Subject: Re: MML charset tag regression Date: Tue, 20 May 2003 21:42:14 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <28265A4C-8AFB-11D7-AF98-00039363E640@swipnet.se> References: <200305201247.VAA04493@etlken.m17n.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1053460731 14507 80.91.224.249 (20 May 2003 19:58:51 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 20 May 2003 19:58:51 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue May 20 21:58:46 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19IDDT-0003Y5-00 for ; Tue, 20 May 2003 21:56:07 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 19IDNu-00069L-00 for ; Tue, 20 May 2003 22:06:54 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.20) id 19IDEt-0002pq-Ex for emacs-devel@quimby.gnus.org; Tue, 20 May 2003 15:57:35 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19ID7O-0000CI-Gt for emacs-devel@gnu.org; Tue, 20 May 2003 15:49:50 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19ID5d-0007uS-33 for emacs-devel@gnu.org; Tue, 20 May 2003 15:48:02 -0400 Original-Received: from stubby.bodenonline.com ([193.201.16.94]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19ID12-0006CN-5v; Tue, 20 May 2003 15:43:16 -0400 Original-Received: from accessno42.bodenonline.com (accessno42.bodenonline.com [193.201.16.44])h4KKWZS3004083; Tue, 20 May 2003 22:32:45 +0200 Original-To: Kenichi Handa In-Reply-To: <200305201247.VAA04493@etlken.m17n.org> X-Mailer: Apple Mail (2.552) Original-cc: ding@gnus.org Original-cc: rms@gnu.org Original-cc: jas@extundo.com X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:14020 gmane.emacs.gnus.general:52784 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:14020 > In article , Richard Stallman > writes: > >> Recently, many gtk clients start supporting UTF8_STRING >> without making COMPOUND_TEXT support better. It may cause >> no problem between gtk clients because they will request >> only the type UTF8_STING. But, it's a too shortsighted >> manner. :-( > >> Is this an issue I should raise with the GTK developers? Could they, >> should they, do something to encourage app developers to handle >> COMPOUND_TEXT properly? > > Perhaps, app developers are just using some GTK function for > X selection handing (I don't know if such a function surely > exists). In that case, improving that function solve the > problem. There is a function that converts selection data to an UTF8 string, if the format is a known text format. But mostly widgets take care of selection handling by themselves (i.e. transparent to an application that uses GTK). To get better COMPOUND_STRING handling, I suspect GTK as a library must change. The reason you are seeing more UTF8_STRING is probably not a choice made by GTK client developers, it is just an effect of porting to GTK version 2. UTF8_STRING is not present in GTK 1.x, but the preferred format in GTK 2.x. The reason for this is the standards work being done by the free desktop people (see http://www.freedesktop.org/standards/) to improve interoperability between desktop environments, for example KDE and GNOME. It seems UTF8_STRING is the preferred coding. I am not sure, but I suspect that better COMPOUND_STRING handling is low on the priority, as the web page above kind of implies that UTF8_STRING is to replace COMPOUND_STRING in the future. Qt (KDE) also uses UTF8_STRING as a first choice. Jan D.