Mouse cursor disappearing

[Srinivas Nayak]

Hello,

I am using fltk to make a gui based program.

I have several buttons in a group and a box.

Sometimes my cursor is disappearing from the box.

But cursor is visible on button group area.

What might be happening?

How should I track what I am missing?

I shall be grateful for your help.

Sincerely,

Srinivas Nayak 

[Albrecht Schlosser]

On 3/17/22 15:12 Srinivas Nayak wrote:
> I am using fltk to make a gui based program.
> I have several buttons in a group and a box.
> Sometimes my cursor is disappearing from the box.
> But cursor is visible on button group area.
>
> What might be happening?

Hard to say w/o seeing your code and GUI layout.

What does "sometimes" mean in this context? Is there anything specific
happening, user interaction, window resizing, ... ?

> How should I track what I am missing?

The first thing you should do is check if all your widgets (Fl_Group,
button, box) are entirely included in their parent's space (x/y/w/h).
Otherwise strange things can happen.

It is possible to have widgets change the cursor on FL_ENTER and
FL_LEAVE events but this would need derived classes and their handle()
methods. Are you doing anything like this? Can you describe how complex
your GUI is and how you created it?

Although it's also very unlikely to cause such effects, please tell us
on which platform you're working and which FLTK version and download
source you are using (if Git, please specify the Git version/hash). Did
you build FLTK yourself or is it included in an OS distribution (if yes,
which one)?

I can't suggest anything else w/o more info about your program.

[Srinivas Nayak]

Dear Albrecht,

Many thanks for your reply.

You correctly pointed out the issue.

"It is possible to have widgets change the cursor..."

I have a input box and shortcut escape key callback.

In this callback I am destroying the input box, but window stays.

I noticed, after a very careful observation that,

while I type something, if I press escape key, mouse cursor disappears.

After a lot of search, I found, exactly a similar case.

https://groups.google.com/g/fltkgeneral/c/Pqi3w8F4iPU/m/o-TGKFOpBQAJ

Ian proposes to restore the cursor for entire window.

I did the same in escape callback, and the issue disappeared!

Thank you so much for your valuable time and reply.

Sincerely,

Srinivas Nayak

--
You received this message because you are subscribed to a topic in the Google Groups "fltk.general" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/fltkgeneral/Ph_Yk6e7BdY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to fltkgeneral...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/2519b1aa-e52b-d281-883d-866c1874cd1f%40online.de.

[Albrecht Schlosser]

On 3/17/22 20:20 Srinivas Nayak wrote:

Dear Albrecht,

Many thanks for your reply.

Welcome.

You correctly pointed out the issue.

"It is possible to have widgets change the cursor..."

I have a input box and shortcut escape key callback.

In this callback I am destroying the input box, but window stays.

Interesting, I wouldn't have hoped that you can find it so quickly.

I noticed, after a very careful observation that,

while I type something, if I press escape key, mouse cursor disappears.

After a lot of search, I found, exactly a similar case.

https://groups.google.com/g/fltkgeneral/c/Pqi3w8F4iPU/m/o-TGKFOpBQAJ

Ian proposes to restore the cursor for entire window.

I did the same in escape callback, and the issue disappeared!

Great that you could solve the issue for your program.

This is interesting - I mean, it would be great if we could fix this in the FLTK library itself. I'm not sure if this can be done (easily), but I'd like to give it a try.

Now that you know what exactly happened, could you please post a minimal reproducer code (complete program) including the solution, marked in a comment or with a short description?

If we had such a small program we could test and maybe fix the issue. I could probably create such a program myself, but then this would be a process of trial and error (starting with your description).

Thank you so much for your valuable time and reply.

Thanks as well, looking forward to see your reproducer code if you can create and post it.

[Srinivas Nayak]

Dear Albrecht,

Many thanks for your mail.

I am very happy that you want to fix this issue in FLTK.

Here I am attaching the test code. It is a minimal one.

Kindly let me know if I can help you more. Let's improve FLTK.

[By the way, I am using the Msys2/MinGW-w64 environment on Windows 10.

And I am using FLTK 1.3.7 https://www.fltk.org/pub/fltk/1.3.7/fltk-1.3.7-source.tar.gz]

Sincerely,

Srinivas Nayak

[Srinivas Nayak]

Dear  Albrecht,

        //if mouse cursor is on the input box, it becomes I cursor.
        //when we type into input text box, mouse cursor I disappears.

I would recommend not to hide the cursor when we type in the input box.

Mouse cursor will remain alway visible...

If it is on the input box, I cursor, else arrow pointer.

Will it cause any usability issue?

Sincerely,

Srinivas Nayak

[Albrecht Schlosser]

On 3/18/22 19:48 Srinivas Nayak wrote:

Dear  Albrecht,

        //if mouse cursor is on the input box, it becomes I cursor.
        //when we type into input text box, mouse cursor I disappears.

I would recommend not to hide the cursor when we type in the input box.

Mouse cursor will remain alway visible...

If it is on the input box, I cursor, else arrow pointer.

Dear Srinivas,

thank you very much for the code and your suggestions. I'll look into it and see how we can hopefully improve it.

My thoughts about this issue was to take care of resetting the cursor to what it was before even if the widget gets deleted but I'm not at all sure if this can always be done.

Will it cause any usability issue?

I can't tell yet but I'll see. Having two cursors (or cursor-like input markers) might be confusing.

Input from others would be appreciated as well.

[Ian MacArthur]

I don't think I'd been keen on changing our current behaviour - it's been "this way" for 30-odd years, and was made like this so that it matches the extant behaviour of other toolkits.

The principle, of course, being that of being the "least surprising" for the end users, who are accustomed to the current behaviour from their general experience with other applications.

Further, having two visible cursors, as suggested in this case, makes it less obvious where the active focus lies - and would likely be disastrous on any WM that has a "focus-follows-mouse" policy (though I recognize that those are less common now than they once were; and I imagine many younger devs have never even seen such a thing!)

The underlying issue here - that if you destroy an input box whilst it has the active focus, then the cursor may be left in an invalid state - seems to be something of an edge case, since I think I've only seen queries about this twice in the last couple of decades.

It may be enough to put something in the docs that says you may have to restore the cursor explicitly if you destroy an Fl_Input or similar text widget whilst it has the focus?

"Restoring" the cursor "automatically" when the Fl_Input widget is deleted might not be trivial, as it may not be obvious what form to set it to - it might not always be FL_DEFAULT_CURSOR. Though setting it to that might be better than nothing, of course...

[Srinivas Nayak]

Dear Ian,

Thanks a lot for your input.

>> having two visible cursors, as suggested in this case...

Looks like there is a misunderstanding here.

I am not proposing to have two cursors on screen.

Let's look at the test application I shared.

Let's create an input box. I have given it focus as soon as it got created.

What I observe on Windows is:

We will see a black I bar coming inside the input box.

It tells us that, input box got focus!

[If the input box has no focus, this I bar doesn't come.]

Now let's move our mouse around the input box. we will see,

1. when mouse hovers outside the input box, cursor is an arrow pointer.

2. When mouse hovers over the input box, cursor changes from arrow pointer to I cursor.

Well and good. We have no problem here. Note that the black I bar inside the input box is still there, waiting for input...

Now, after hovering, let's leave the mouse over the input box.

We will see mouse cursor changed to I cursor.

Now, if we start typing, suddenly the hovering mouse cursor disappears, but the black I bar inside input box remains as is.

Here I am saying, do we really need to make that hovering I cursor disappear ?

Hope, I explained it. Can I help more?

Sincerely,

Srinivas Nayak

--
You received this message because you are subscribed to a topic in the Google Groups "fltk.general" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/fltkgeneral/Ph_Yk6e7BdY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to fltkgeneral...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/6ff93198-317d-4d4d-8df1-1b586c3a02e5n%40googlegroups.com.

[Srinivas Nayak]

Dear All,

Here is a simple application I created.

A Simple, Powerful, Free, Brainstorming Whiteboard
https://github.com/snayaksnayak/iMage/releases/download/v1.0/iMage_v1.0.zip

Kindly have a look at it.

I Hope, you can use it.

Sincerely,

Srinivas Nayak

[Srinivas Nayak]

Dear All,

Here is a Simple, Powerful, Free, Brainstorming Whiteboard Application created using FLTK.

https://github.com/snayaksnayak/iMage/releases/download/v1.0/iMage_v1.0.zip

iMage is a simple, powerful, free brainstorming whiteboard. It is best for illustrating an idea pictorially. It can be used as a diagramming or drawing tool. Using only the Escape key and Left mouse button, any kind of drawings can be created quickly on iMage. Drawings can be saved and later edited. iMage always tries not to lose any drawings created by you. Being a small and simple tool it needs no installation. Needs no extra libraries. Needs no more than 1.5 MB! iMage has most intuitive interface. While explaining your ideas to others, iMage never wastes your time in drawing things.

Kindly visit and comment.

Sincerely,

Srinivas Nayak

[Bill Spitzak]

Fltk does know what the cursor has been set to, and could probably put it back to the default cursor on any mouse movement if it is invisible.

--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/6ff93198-317d-4d4d-8df1-1b586c3a02e5n%40googlegroups.com.

[imm]

On Tue, 22 Mar 2022, 17:38 Bill Spitzak wrote:

Fltk does know what the cursor has been set to, and could probably put it back to the default cursor on any mouse movement if it is invisible.

Hi Bill,

Oh, right: I wasn't sure.

Particularly, I was worried about hitting some weird edge case, and "restoring" the cursor to the wrong shape.

Like... The cursor enters a group, and the handle() changes it to some non-default shape.

Then the user enters some text into a Fl_Input (cursor changes to I-beam.) Meanwhile, the mouse moves a bit whilst the user is typing, leaving the inner group.

The Fl_Input is dismissed, and the cursor needs to restore some shape... But the last "valid" shape we selected was for the inner group, but we left that group, potentially without triggering the handle () because the Fl_Input had the focus... So we get the wrong shape?

I do not know.

--
Ian
From my Fairphone FP3

[Srinivas Nayak]

Hi,

Just a thought.

Can we comment out  window()->cursor(FL_CURSOR_NONE); from below code?

Why do we make cursor disappear here?

Fl_Input.cxx

----------------

int Fl_Input::handle(int event) {

...

    case FL_KEYBOARD:

...

      } else {
        if (active_r() && window() && this == Fl::belowmouse())
          window()->cursor(FL_CURSOR_NONE);
        return handle_key();
      }

...

}

Sincerely,

Srinivas Nayak

--
You received this message because you are subscribed to a topic in the Google Groups "fltk.general" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/fltkgeneral/Ph_Yk6e7BdY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to fltkgeneral...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/CAGFM6dYqpnYePMRr2T0r7dyK7ctGmeDWCw6KwSM7VJwWOmcosA%40mail.gmail.com.

[Ian MacArthur]

On Monday, 4 April 2022 at 16:38:54 UTC+1  Srinivas Nayak wrote:

Hi,

Just a thought.

Can we comment out  window()->cursor(FL_CURSOR_NONE); from below code?

Probably not a good idea - what this is doing is creating the behaviour the majority of users expect, from their experience with other applications, and the principle of least surprise thus requires we do the same.

 

Why do we make cursor disappear here?

Basically because it's the "normal" thing for a UI toolkit to do in this circumstance, and we must do the least surprising thing for the largest number of users - most of whom are presumed to be less experienced in these matters than a developer such as you might be.

I recognize it's not the behaviour that suits your use case, but the needs of the many, etc...

Basically, this bit of code only becomes an issue in your case when you are destroying the widget whilst the cursor is hidden - but since you have full control over when the input widget is deleted, it does seem like it wouldn't be that hard for you to explicitly restore the cursor at the point you know you have deleted the input widget?

[Srinivas Nayak]

Dear Ian,

This is the perfect possible explanation of the matter.

I am thankful for your time and insight you presented.

I agree with you. Since most users expect the mouse

to be hidden in such cases. It better not be altered.

Yes, I was able to solve the issue in my code.

As you said, it is not hard when we have

control on when the widget gets deleted.

I am happy that I was able to spot the FLTK code.

Maybe it is due to nicely written code in the FLTK source.

Sincerely,

Srinivas Nayak

--
You received this message because you are subscribed to a topic in the Google Groups "fltk.general" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/fltkgeneral/Ph_Yk6e7BdY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to fltkgeneral...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/647a5b76-37d9-460f-865b-18d41fdefe96n%40googlegroups.com.