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

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

[L A Walsh]

I don't recall this always being this way as I keep running into
a problem with my input going into the wrong window.

I've noted I seem to be relying on which editor(i.e. gvim)
window in X11 has focus by noting that it has a
blinking square cursor in the window at the cursor's
current position in the edited text.

If I move the windows cursor to another editor window in X11,
the blinking cursor moves to the new window, but if I move
it to a native window, the blinking doesn't stop.

Has this always been this way?

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

[Achim Gratz]

L A Walsh writes:
> If I move the windows cursor to another editor window in X11,
> the blinking cursor moves to the new window, but if I move
> it to a native window, the blinking doesn't stop.
>
> Has this always been this way?

Windows never had "focus follows mouse" in any version I can remember.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

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

[L A Walsh]

On 2021/04/07 11:46, Achim Gratz wrote:
> L A Walsh writes:
>   
>> If I move the windows cursor to another editor window in X11,
>> the blinking cursor moves to the new window, but if I move
>> it to a native window, the blinking doesn't stop.
>>
>> Has this always been this way?
>>     
>
> Windows never had "focus follows mouse" in any version I can remember.
>   
It's been in every version since at least Win98, but required
either some special utility to set it or editing the registry.

They do have a focus follows mouse setting, but one that always raises
the the window in question, which can still duplicate the problem
of switching to a win-window where it gets focus and X11 may not
know it.

First thing I have on my desktop is 1-click to activate -- same as
web settings.  I have RSI issues and trying to double click on things
really causes the irritation level to go up quickly.  That means
I can select by hovering -- that setting is in the folder options
under Tools when you look at a folder.  Single-click to open items, and
underline icon titles consistent w/my browser.

In the Mouse or Ease-of-access settings, one can choose to activate a window
by hovering over it with the mouse.

The one that still takes a registry setting since Win98 days. is
true focus follows mouse w/o the window being raised.  There's still a
configurable delay before the focus changes -- usually 175-250ms, or the
moving your cursor across the screen would cause a bunch of windows to
raise in the default configuration.  The 175 works for me.

But it has to do with HKEY_CURRENT_USER\Control 
Panel\Desktop\UserPreferencesMask.
It's a 8-byte binary value.  I always see the low-order nibble of the first
byte set to '1'(like 0xb1). 


So that hasn't changed for me since win98 but whether or not xprograms
have blinking cursors that stop blinking or hide when you type are things
that have been added in that time, but I've never seen the cursor keep
going like I do most recently, when the focus goes off the X-window to
a Win-window.

I notice you zoomed in on windows being able to change focus by moving
the cursor to a different window w/no click involved.  Did something change
in that area in X11 where it was changed to need to see a click before
changing?

Thanks!

>
> Regards,
> Achim.
>   

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

[Lemke, Michael SF/HZA-ZIC2]

[-- Attachment #1: Type: text/plain, Size: 667 bytes --]

On April 7, 2021 8:47 PM Achim Gratz wrote:
>L A Walsh writes:
>> If I move the windows cursor to another editor window in X11,
>> the blinking cursor moves to the new window, but if I move
>> it to a native window, the blinking doesn't stop.
>>
>> Has this always been this way?
>
>Windows never had "focus follows mouse" in any version I can remember.
>

It has had it since Windows95 or so and it is my default setting on 
any PC I use. Attached is a little program I wrote a long time ago that 
turns the feature on or off. Compile with `gcc xmouse.c` or mingw.

Something like this was included in the Windows PowerToys as xmouse.exe.

Michael

[-- Attachment #2: xmouse.c --]
[-- Type: text/plain, Size: 2413 bytes --]

#define WINVER 0x0500
#include <windows.h>
#include <stdio.h>
 
/* gcc -mno-cygwin -mwindows  ... */
 
void ErrorExit(LPTSTR lpszFunction, DWORD dw) 
{ 
    LPVOID lpMsgBuf;
    LPVOID lpDisplayBuf;
    //DWORD dw = GetLastError(); 
 
    FormatMessage(
        FORMAT_MESSAGE_ALLOCATE_BUFFER | 
        FORMAT_MESSAGE_FROM_SYSTEM,
        NULL,
        dw,
        MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),
        (LPTSTR) &lpMsgBuf,
        0, NULL );
 
    lpDisplayBuf = LocalAlloc(LMEM_ZEROINIT, 
        strlen(lpMsgBuf)+strlen(lpszFunction)+40); 
    wsprintf(lpDisplayBuf, 
        "%s failed with error %d: %s", 
        lpszFunction, dw, lpMsgBuf); 
    MessageBox(NULL, lpDisplayBuf, "Error", MB_OK); 
 
    LocalFree(lpMsgBuf);
    LocalFree(lpDisplayBuf);
    ExitProcess(dw); 
}
 
 
 
int WINAPI WinMain (HINSTANCE hInst, HINSTANCE hPrev, LPSTR lpCmd, int nShow) {
//int main (void) {
 
   BOOL xmouse = FALSE;
 
   DWORD status;
 
   if( !(status=SystemParametersInfo( SPI_GETACTIVEWINDOWTRACKING,
                                      0,
                                      &xmouse,
                                      0
                                     )) ) {
      ErrorExit("Get mouse status",status);
   }

   if( !(status=SystemParametersInfo( SPI_SETACTIVEWNDTRKZORDER,
                                      0,
                                      (PVOID)FALSE,
                                      SPIF_UPDATEINIFILE || SPIF_SENDWININICHANGE
                                    )) ) {
      ErrorExit("Set mouse status",status);
   }

   if( !(status=SystemParametersInfo( SPI_SETACTIVEWNDTRKTIMEOUT,
                                      0,
                                      (PVOID)100,
                                      SPIF_UPDATEINIFILE || SPIF_SENDWININICHANGE
                                    )) ) {
      ErrorExit("Set mouse status",status);
   }

   xmouse = !xmouse;
   if( !(status=SystemParametersInfo( SPI_SETACTIVEWINDOWTRACKING,
                                      0,
                                      (PVOID)xmouse,
                                      SPIF_UPDATEINIFILE || SPIF_SENDWININICHANGE
                                    )) ) {
      ErrorExit("Set mouse status",status);
   }
   printf( "X mouse is now %s.\n", xmouse ? "on" : "off" );
 
   return 0;
}

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

[Andrey Repin]

Greetings, Achim Gratz!

> L A Walsh writes:
>> If I move the windows cursor to another editor window in X11,
>> the blinking cursor moves to the new window, but if I move
>> it to a native window, the blinking doesn't stop.
>>
>> Has this always been this way?

> Windows never had "focus follows mouse" in any version I can remember.

It has it in every version starting Windows 95/NT4.

@Linda: try http://joelpurra.com/Projects/X-Mouse_Controls/


-- 
With best regards,
Andrey Repin
Thursday, April 8, 2021 14:18:15

Sorry for my terrible english...

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

[Jon Turney]

On 07/04/2021 01:27, L A Walsh wrote:
> I don't recall this always being this way as I keep running into
> a problem with my input going into the wrong window.
> 
> I've noted I seem to be relying on which editor(i.e. gvim)
> window in X11 has focus by noting that it has a
> blinking square cursor in the window at the cursor's
> current position in the edited text.
> 
> If I move the windows cursor to another editor window in X11,
> the blinking cursor moves to the new window, but if I move
> it to a native window, the blinking doesn't stop.
> 
> Has this always been this way?

I think so, yes.

See [1] et seq. for a discussion of what I think is the same problem, 
where the Cygwin X server doesn't notify X windows of a focus loss when 
the focus moves to a non-X window.

Unfortunately, my attempts at fixing this just introduced more problems 
(see [2],[3] et seq.), and so were reverted.

[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

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

[Thomas Wolff]

Am 09.04.2021 um 16:41 schrieb Jon Turney:
> On 07/04/2021 01:27, L A Walsh wrote:
>> I don't recall this always being this way as I keep running into
>> a problem with my input going into the wrong window.
>>
>> I've noted I seem to be relying on which editor(i.e. gvim)
>> window in X11 has focus by noting that it has a
>> blinking square cursor in the window at the cursor's
>> current position in the edited text.
>>
>> If I move the windows cursor to another editor window in X11,
>> the blinking cursor moves to the new window, but if I move
>> it to a native window, the blinking doesn't stop.
>>
>> Has this always been this way?
>
> I think so, yes.
>
> See [1] et seq. for a discussion of what I think is the same problem, 
> where the Cygwin X server doesn't notify X windows of a focus loss 
> when the focus moves to a non-X window.
Hmm, when I start xterm -bc and click out of xterm (e.g. mintty or 
Thunderbird), the cursor stops blinking for me.

>
> Unfortunately, my attempts at fixing this just introduced more 
> problems (see [2],[3] et seq.), and so were reverted.
>
> [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
> -- 
> Problem reports:      https://cygwin.com/problems.html
> FAQ:                  https://cygwin.com/faq/
> Documentation:        https://cygwin.com/docs.html
> Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple

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

[L A Walsh]

On 2021/04/09 07:41, Jon Turney wrote:
> 
> I think so, yes.
===
	That's fine, I guess I hadn't noticed it before --
had about 3-X and maybe 2 native and couldn't figure out why I
occasionally had typing going to the wrong window when I realized I
had been relying on the blinking for the active window...oi!  

> 
> See [1] et seq. for a discussion of what I think is the same problem, 
> where the Cygwin X server doesn't notify X windows of a focus loss when 
> the focus moves to a non-X window.
> 
> Unfortunately, my attempts at fixing this just introduced more problems 
> (see [2],[3] et seq.), and so were reverted.
===

	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

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

[L A Walsh]

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
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?

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

[L A Walsh]

On 2021/04/09 08:12, Thomas Wolff wrote:
> Hmm, when I start xterm -bc and click out of xterm (e.g. mintty or 
> Thunderbird), the cursor stops blinking for me.
>   
---
That's the key difference "click out of xterm" -- in pointer follows
focus, no clicking is used.  The active window becomes the one under
the cursor (in my case) 175ms later.

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

[Jon Turney]

On 09/04/2021 16:12, Thomas Wolff wrote:
> 
>> See [1] et seq. for a discussion of what I think is the same problem, 
>> where the Cygwin X server doesn't notify X windows of a focus loss 
>> when the focus moves to a non-X window.
> Hmm, when I start xterm -bc and click out of xterm (e.g. mintty or 
> Thunderbird), the cursor stops blinking for me.

If you read [1], you'll see that mentions this behaviour is only seen 
with some X clients, and xterm is explicitly mentioned as one for which 
it works correctly.

(I think perhaps the problem is with X clients which implement the 
WM_TAKE_FOCUS protocol, but I don't seem to have made that connection in 
my contemporaneous notes, so perhaps it's more complex than that)

>> Unfortunately, my attempts at fixing this just introduced more 
>> problems (see [2],[3] et seq.), and so were reverted.
>>
>> [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

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

[Jon Turney]

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.

> 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.

Re: 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.

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

[Achim Gratz]

Andrey Repin writes:
>> Windows never had "focus follows mouse" in any version I can remember.
>
> It has it in every version starting Windows 95/NT4.

The last time I tried it it didn't quite work, though.  Specifically it
does "focus strictly follows mouse" and it had problems with raising
unwanted windows in the past.  Again AFAIR…

> @Linda: try http://joelpurra.com/Projects/X-Mouse_Controls/

So I've tried it again… it works better than I remembered.  The ability
of typing into windows that are partially overlapped by another one
probably means I will keep it enabled despite the other problems, but
I'm still sitting on the fence about that.  There are still (less)
problems of the sort that I've had before, but I still see random
Windows getting auto-raised (and briefly taking then losing focus) with
the mouse not even near them (often it's actually on the other screen)
and some applications still needing a click to activate keyboard input
or input to the correct place.  Also some types of keyboard-activated
input fields do not get focus when they open because they get created
away from the mouse pointer, so while formerly they'd be ready to get
input as soon as they pop up, you now have to move the mouse there,
which kind of defeats the purpose.  Also I'd really like a lazy focus
follow that doesn't remove the focus as long as the mouse pointer
doesn't enter another window, but apparently that can't be set up
either.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

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

[L A Walsh]

On 2021/04/08 04:19, Andrey Repin wrote:
> It has it in every version starting Windows 95/NT4.
> @Linda: try http://joelpurra.com/Projects/X-Mouse_Controls/
>   
---
Just had the occasion to need it, since had to re-inst W7.
Unfortunately, it immediately dumps core.  Very odd.

Dependency walker tries and issues an immediate failure:
00:00:00.000: Failure starting the process. The request is not supported 
(50).

That looks suspiciously like MS's latest strike against
Win7, telling people it's incompatible with newer SW.

At least reinst'ing W7 gave me a chance to catch Adobe's SW
timebomb destroying my Photoshop CS5 exploding as it happens
and their fans telling me how it was crazy for me
to expect old SW to work on a newer HW as an excuse for
why PS5 would stop working after getting a newer
Graphix card to replace an older one that died ...
for some reason, TWICE NOW, upgrading Win7-Ult to itself
has restored PS5's ability to work with NVidia's latest
hardware.  Now, after re-inst'ing Win7 on itself to repair
a prob, PS5 works again w/latest Nvidia HW -- at least until
I reconnect my desktop to the internet and allow Adobe to
re-download their malware and kill it again (something I've
seen happen about 4 times now with a 5th time in the making).


Sigh...

Used to be SW timebombs were a criminal act.  Then they became
a Corporate way of doing business...

*double sigh*....