X11 blinking cursor in text window like 'gvim' - only halts if moved-over another X11-win

[L A Walsh]

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.