From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from Ishtar.sc.tlinx.org (ishtar.tlinx.org [173.164.175.65]) by sourceware.org (Postfix) with ESMTPS id AA0453857816 for ; Sun, 11 Apr 2021 14:53:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org AA0453857816 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=tlinx.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=cygwin@tlinx.org Received: from [192.168.3.12] (Athenae [192.168.3.12]) by Ishtar.sc.tlinx.org (8.14.7/8.14.4/SuSE Linux 0.8) with ESMTP id 13BErZvN000920; Sun, 11 Apr 2021 07:53:37 -0700 Message-ID: <60730D71.2090806@tlinx.org> Date: Sun, 11 Apr 2021 07:53:37 -0700 From: L A Walsh User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Jon Turney CC: The Cygwin Mailing List Subject: Re: X11 blinking cursor in text window like 'gvim' - only halts if moved-over another X11-win References: <606CFC89.6030700@tlinx.org> <3a23e83c-670b-c599-b77b-18074dadf42e@dronecode.org.uk> <6071F92E.5050802@tlinx.org> <60721A9B.1000605@tlinx.org> <0d803d41-42b6-4725-b1c8-3e01486907fb@dronecode.org.uk> In-Reply-To: <0d803d41-42b6-4725-b1c8-3e01486907fb@dronecode.org.uk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: cygwin@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2021 14:53:40 -0000 On 2021/04/11 07:33, Jon Turney wrote: > On 10/04/2021 22:37, L A Walsh wrote: >> On 2021/04/10 12:14, L A Walsh wrote: >>> On 2021/04/09 07:41, Jon Turney wrote: >>>> I think so, yes. >>> === >>> >>> That's unfortunate. Well, I wasn't sure if it was new >>> or old. At least its not some new problem. Sigh. >>> >>> Thanks for the backstory. >>>> [1] https://sourceware.org/legacy-ml/cygwin/2017-04/msg00168.html >>>> [2] https://sourceware.org/legacy-ml/cygwin/2017-04/msg00278.html >>>> [3] https://sourceware.org/pipermail/cygwin/2017-May/232564.html >> --- >> I don't know if this was tried, but the only way to really do >> it would be along the lines of detecting when windows had grabbed >> control via its time -- for cygwin to use a timer to detect when it >> lost control. Ex. in cygwin's blink routine, it would need to check > > There is no 'cygwin blink routine' - this is something that the X client > (e.g. gvim in your example) is doing, while it believe that it has focus. --- Use of "cygwin blink routine" refers to whatever timing mechanism calls some graphical routine to toggle on and off a cursor, unless you are saying that the timer routine responsible for blinking is only present in gvim, in which case X or cygwin might need their own timer routine. > >> that it still had focus, and if it had lost it for longer than 50-75ms >> (maybe configurable), assume cursor is over a Win-Window... May not >> be worth the bother, but it might catch the problem? > > There's almost certainly no need for such heuristics. Windows provides > various notification messages when the focus is moving, it's translating > those (correctly) into the model that X clients expect that is the problem. ---- I suggest a heuristic because a direct translation has been resistant to implementation, so far, but also because windows is using a heuristic to determine when to change focus. It uses a timer to give you time to move to a widget and not activate everything between the two -- like when I right click on a task on the menu bar and the options appear about .5-1" to the right of the menu bar (mine is on the left, not bottom). That means I need to move over some other "stuff" before I can get to the target. If I move too slowly, the target disappears. If windows waits too long to activate the target, I find myself moving into a window and waiting for it to become active. So the time before windows activates the target is also a configurable wait time, which is why I thought cygwin might use something similar. It may not be ideal, and not always, do I move to my target quickly enough, but it works most of the time in practical use.