From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26527 invoked by alias); 3 Jan 2004 23:16:54 -0000 Mailing-List: contact cygwin-xfree-help@cygwin.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-xfree-owner@cygwin.com Mail-Followup-To: cygwin-xfree@cygwin.com Reply-To: cygwin-xfree@cygwin.com Received: (qmail 26519 invoked from network); 3 Jan 2004 23:16:53 -0000 Received: from unknown (HELO meg.hrz.tu-chemnitz.de) (134.109.132.57) by sources.redhat.com with SMTP; 3 Jan 2004 23:16:53 -0000 Received: from hermes.hrz.tu-chemnitz.de ([134.109.132.175]) by meg.hrz.tu-chemnitz.de with esmtp (Exim 4.22) id 1Acv0m-0000nf-Mf for cygwin-xfree@cygwin.com; Sun, 04 Jan 2004 00:16:52 +0100 Received: from odoaker.hrz.tu-chemnitz.de ([134.109.132.94] helo=stargate.ago.vpn ident=[IxBoHinTMwdmoRNzkkO3ZbL9na3u80G7]) by hermes.hrz.tu-chemnitz.de with esmtp (Exim 4.20) id 1Acv0l-00034K-Va for cygwin-xfree@cygwin.com; Sun, 04 Jan 2004 00:16:52 +0100 Received: from lupus.ago.vpn (lupus.ago.vpn [192.168.26.203]) by stargate.ago.vpn (Postfix on SuSE Linux 7.0 (i386)) with ESMTP id 27F8218FA6 for ; Sun, 4 Jan 2004 00:16:50 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by lupus.ago.vpn (Postfix) with ESMTP id 587F78FE7 for ; Sun, 4 Jan 2004 00:16:49 +0100 (MET) Date: Sat, 03 Jan 2004 23:16:00 -0000 From: Alexander Gottwald Cc: cygwin-xfree@cygwin.com Subject: X11 Selections Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Spam-Report: --- Start der SpamAssassin 2.61 Textanalyse (0.0 Punkte) Fragen an/questions to: Postmaster TU Chemnitz --- Ende der SpamAssassin Textanalyse X-Scan-Signature: e4b5076b308c977cae8cdcac8588cacb X-SW-Source: 2004-01/txt/msg00056.txt.bz2 List-Id: Just what I've already written in IRC: I've looked into the ICCCM to find out about the handling of X11 selections. >>From what I've read the xclient (eg xterm) just calls XSetSelectionOwner and can do whatever he wants. The actual data is accessed only when another client calls XConvertSelection. Is this correct? But I have no idea what happens if the xterm calls XSetSelectionOwner, the other app gets the data with XConvertSelection and the xterm then modifies the selection without calling XSetSelectionOwner again because it already own the selection buffer. To refine the outline the idea: X11->Win32 X11 client calls XSetSelectionOwner - get the data from the client (maybe by using a fake window or the root window as recipient of the clipboard data) - translate the data for the windows clipboard - OpenClipboard - EmptyClipboard - SetClipboardData - CloseClipboard If every change of the selection is indicated by XSetSelectionOwner then we always place the copy of the selection in the clipboard. Win32->X11 Win32 client copies to the clipboard - WindowProc receives WM_DRAWCLIPBOARD - call ProcSetSelectionOwner with RootWindow (or fake window) as owner X11 client calls XConvertSelection - receive SelectionRequest event - translate clipboard data for xclient - send data to client bye ago NP: Funker Vogt - Compulsions -- Alexander.Gottwald@informatik.tu-chemnitz.de http://www.gotti.org ICQ: 126018723