From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21121 invoked by alias); 5 Oct 2011 13:03:09 -0000 Received: (qmail 21097 invoked by uid 22791); 5 Oct 2011 13:03:08 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from smtpout.karoo.kcom.com (HELO smtpout.karoo.kcom.com) (212.50.160.34) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 05 Oct 2011 13:02:40 +0000 Received: from 213-152-38-55.dsl.eclipse.net.uk (HELO [192.168.0.5]) ([213.152.38.55]) by smtpout.karoo.kcom.com with ESMTP; 05 Oct 2011 14:02:38 +0100 Message-ID: <4E8C556E.7020607@dronecode.org.uk> Date: Wed, 05 Oct 2011 13:03:00 -0000 From: Jon TURNEY User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20110929 Thunderbird/8.0 MIME-Version: 1.0 To: cygwin-xfree@cygwin.com CC: Paul Maier , dickey@his.com Subject: Re: AW: AW: AW: Can't paste text or type blind keys when mouse is out of the window References: <000901cc54e1$1dca8c50$595fa4f0$@de> <4E6762AA.6020802@dronecode.org.uk> <002401cc6e69$3431eb90$9c95c2b0$@de> <4E69FB99.1000608@dronecode.org.uk> <001001cc81b8$491350f0$db39f2d0$@de> <20111003200921.W12166@mail101.his.com> <000001cc82f8$f64689e0$e2d39da0$@de> In-Reply-To: <000001cc82f8$f64689e0$e2d39da0$@de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact cygwin-xfree-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-xfree-owner@cygwin.com Reply-To: cygwin-xfree@cygwin.com Mail-Followup-To: cygwin-xfree@cygwin.com X-SW-Source: 2011-10/txt/msg00014.txt.bz2 On 05/10/2011 01:51, Paul Maier wrote: >>>>>> I assume that you see the same behavior with other X applications, i.e. it's >>>>>> not xterm-specific? >>>>> >>>>> No, at least xedit works fine on my PC, with blind keys and with mouse text pasting, >>>>> no matter if the mouse pointer is really inside or on blue window frame or >>>>> (for blind keys:) really outside. >>>> >>>> Actually, maybe this is an xterm problem? >>>> >>>> It seems to be somehow related to the xterm's --enable-toolbar configuration >>>> (which is turned on in the cygwin package). If I rebuild xterm with that >>>> disabled, the problem goes away, and I can also reproduce the problem on F15 >>>> under twm if I build xterm with --enable-toolbar there (which is not enabled >>>> in the distro supplied package) >> >> hmm - I'm not clear on precisely what a "blind key" is. Sounds like a >> compose sequence - and if so, it's puzzling that passing key-presses from >> different levels in the widget hierarchy would interfere with that. >> >> The main difference with the toolbar configuration is that xterm's using a >> form to contain the toolbar and the vt100 window. The buttons take care >> of themselves, but that area to the right of the buttons is dead. >> >> To make it somewhat friendlier, xterm adds the actions used for the vt100 >> window (except for the ones related to the mouse) to the toolbar area. >> >> I omitted the mouse-related ones since it seems that they'd interfere with >> the menus. I also did the same for the scrollbar widget (since keystrokes >> there used to be lost - it would seem that you could reproduce your >> problem also by looking at the behaviour around the scrollbar). > > > yes, with mouse over the scrollbar the problem is reproducable. > > A blind key is a key that needs to be followed by another key to produce something. I think this is usually called a 'dead key' -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/