Support for More (or Custom) Cursors?

[Webb Hinton]

Hey all, 

Just wondering, why not add more Cursors to the existing set of Cursors in FLTK? A couple that seem pretty important for a wide scope of applications include:

• Hourglass 
• Closed Hand
• Crosshairs
• Magnifying Glass

Would devs take a PR for these? Whats the thinking behind the currently available set of Cursors?

I know its not too difficult to set up a custom cursor solution by using the "None" cursor, but I would certainly welcome some more "out of the box" cursors.

[Greg Ercolano]

On 4/16/21 12:49 AM, Webb Hinton wrote:

Hey all, 

Just wondering, why not add more Cursors to the existing set of Cursors in FLTK? A couple that seem pretty important for a wide scope of applications include:

• Hourglass 
• Closed Hand
• Crosshairs
• Magnifying Glass

FLTK does have "Hourglass" as FL_CURSOR_WAIT, and "Crosshairs" as FL_CURSOR_CROSS
(See FL/Enumerations.H for all the FL_CURSOR_xxx options)

But yes, we don't have 'Closed hand' or 'Magnifying glass' AFAIK.

Apparently you can define your own cusors by supplying an Fl_RGB_Image and the x,y
position of the 'hot spot' using Fl_Window::cursor(const Fl_RGB_Image*, int, int);

Might be good if FLTK had an example showing its use.

[pvr...@btinternet.com]

One thing I missed when porting to FLTK from another windows scheme was the lack of facility to read (and save) the current cursor, so I could restore the cursor to its original state rather than assuming it would have been the default cursor.

Phil.

[Ian MacArthur]

On 16 Apr 2021, at 16:41, 'pvr... wrote:
>
> One thing I missed when porting to FLTK from another windows scheme was the lack of facility to read (and save) the current cursor, so I could restore the cursor to its original state rather than assuming it would have been the default cursor.

Yes, that’s one of those “lowest common denominator” portability issues of which I spoke... Basically, on *some* platforms there’s no easy way to ask the WM what the current cursor is, so we don't expose that ability.
If you really need it, then the best you can do is track the cursor setting in a static variable, which is kinda what the docs for the various Fl_Window::cursor(...) methods suggest “you may want to keep track of how you set it in a static variable and call this only if the new cursor is different”

Now, the obvious follow on question is whether fltk should track the current cursor; but we have not done that historically (fast and light, etc.) so it’s never been a thing before...

[Ian MacArthur]

So... after this thread, I’d said it was easy to just load a custom cursor to suit using the Fl::Window->cursor(Fl_RGB_Image*, blah...); method.

And indeed, it is (see attached) on OSX and WinXX this works just fine.
On my Ubuntu laptop, however, the custom cursor does not appear.
Which surprised me, hence posting this.

Can I ask what others see? Does this code work for you on X11 hosts? And if not, do we know why not?

Cheers,
--
Ian

[Ian MacArthur]

Meh - looks like the config / build is not detecting the Xcursor extension on my laptop... so now I need to figure out why not.

[Albrecht Schlosser]

I can confirm that it works fine if Xcursor is configured and doesn't
work (uses the standard cursor) if I disable Xcursor.

[imm]

On Fri, 23 Apr 2021 at 00:32, Albrecht Schlosser wrote:
>
> I can confirm that it works fine if Xcursor is configured and doesn't
> work (uses the standard cursor) if I disable Xcursor.
>

Thanks Albrecht.
So I went and checked, and indeed, whilst this laptop does have
Xcursor installed, the related -dev packages are missing (ditto for
Xinerama and Xfixes,)
They used to be installed here - but I wonder if I lost them when I
upgraded to Ubuntu 20.04 from 18.04 - though that would be a wee while
ago now...

Anyway, with the -dev packages installed, all is well.
ALMOST.
The cursor now works as intended, BUT this is a high-DPI display and I
am running fltk-1.4 on it as a result, so that things are actually
large enough for me to see them!

So, the cursor appears when appropriate, but is TOO SMALL and not
taking on board the DPI scaling business. I'm not sure if we knew that
would happen, TBH.
Might be one for Manolo? His understanding of the DPI scaling is way better...

[Albrecht Schlosser]

On 4/23/21 11:05 AM imm wrote:

> Anyway, with the -dev packages installed, all is well.
> ALMOST.
>

> So, the cursor appears when appropriate, but is TOO SMALL and not
> taking on board the DPI scaling business. I'm not sure if we knew that
> would happen, TBH.

Well, the normal cursors don't change their sizes either when I type
ctrl/+/-/0. Cursor style and size are another system setup and I don't
know if we can do something about this from the FLTK side.

Maybe you (i.e. the user creating the cursor) could scale the image
proportional to the current scaling factor before setting it.

OTOH... I wonder what "the system" does WRT cursor sizes when you move
the mouse between monitors with different scaling factors. Supposedly
they should adjust their sizes according to the scaling factors. I can't
test this on my notebook though.

[imm]

On Fri, 23 Apr 2021 at 11:02, Albrecht Schlosser wrote:
>
> > So, the cursor appears when appropriate, but is TOO SMALL and not
> > taking on board the DPI scaling business. I'm not sure if we knew that
> > would happen, TBH.
>
> Well, the normal cursors don't change their sizes either when I type
> ctrl/+/-/0. Cursor style and size are another system setup and I don't
> know if we can do something about this from the FLTK side.
>
> Maybe you (i.e. the user creating the cursor) could scale the image
> proportional to the current scaling factor before setting it.

Yes, that was what I did (attached) and that works fine, but I was
surprised by it...

>
> OTOH... I wonder what "the system" does WRT cursor sizes when you move
> the mouse between monitors with different scaling factors. Supposedly
> they should adjust their sizes according to the scaling factors. I can't
> test this on my notebook though.

No, nor can I (test with multiple monitors at different scale factors) just now.
It's a tricky one...

[Albrecht Schlosser]

On 4/23/21 12:02 PM Albrecht Schlosser wrote:
> On 4/23/21 11:05 AM imm wrote:
>>
>> So, the cursor appears when appropriate, but is TOO SMALL and not
>> taking on board the DPI scaling business. I'm not sure if we knew that
>> would happen, TBH.
>
> Well, the normal cursors don't change their sizes either when I type
> ctrl/+/-/0. Cursor style and size are another system setup and I don't
> know if we can do something about this from the FLTK side.
>
> Maybe you (i.e. the user creating the cursor) could scale the image
> proportional to the current scaling factor before setting it.

[Note: you beat me by a few minutes, but anyway...]

Attached is my take on it. I didn't test yours yet. My test will only
run with FLTK 1.4 but you can now use ctrl/+/- to zoom. I added two
17x17 px squares so you can compare cursor sizes visually.

I also changed the 'hotspot' to the center of the cursor and "scaled"
this as well, and I do always scale (copy) the image regardless of the
scaling factor.

Note that image->scale(w,h) doesn't work with cursor images (yet). I'm
pretty sure this is caused by a similar issue as the existing GitHub
issue for using scaled images as icons.
https://github.com/fltk/fltk/issues/205

[imm]

OK - thanks for that.
Cleverer than mine - I only set the cursor image scale once at start
up and that's it. Which is fine on this Linux laptop, but...

I tried this on my Win10 set up (multiple displays at different scales
of 1.0 and 1.25) and the effect there is somewhat odd, depending on
which screen I start the app on, that sets the cursor size, so
although the window resizes as it moves from screen to screen, the
cursor does not... which does look a bit odd. Not terrible, but I
guess with a bigger scale difference it might look worse.
Not sure I'm too bothered about it right now though, and as you say it
likley does relate to the scaling of icons and such across screens
more generally.
Which will not be trivial to fix, I suspect!

[Albrecht Schlosser]

On 4/23/21 1:39 PM imm wrote:
> OK - thanks for that.
> Cleverer than mine - I only set the cursor image scale once at start
> up and that's it. Which is fine on this Linux laptop, but...
>
> I tried this on my Win10 set up (multiple displays at different scales

With "this" I assume you mean your version?

> of 1.0 and 1.25) and the effect there is somewhat odd, depending on
> which screen I start the app on, that sets the cursor size, so
> although the window resizes as it moves from screen to screen, the
> cursor does not... which does look a bit odd.

Did you also try my version? Since it would always change the cursor
size depending on the scaling of the current screen it should work "as
expected". Hopefully.

> Not terrible, but I
> guess with a bigger scale difference it might look worse.
> Not sure I'm too bothered about it right now though, and as you say it
> likley does relate to the scaling of icons and such across screens
> more generally.

FYI, the scaling of icons in issue 205 is a little "special": if you
have an image you want to use as an icon, say 300x300 pixels, you need
to scale it down to a useful size, maybe 64x64. In FLTK 1.4 you have two
choices:

(1) image->copy() which will create a new image with w() == data_w() and
h() == data_h() and this works well (similar to my cursor demo version).

(2) image->scale() which works fine with image drawing functions but NOT
with window->icon() and such because this uses w() and h() internally
but accesses the raw image data which have size data_w() and data_h()
respectively, as if the array was w()*h()*d() pixels large. This
displays garbage, of course.

I got stuck doing other things but one of my comments mentions a
possible solution. Needs more work and testing.

[Ian MacArthur]

On 23 Apr 2021, at 12:55, Albrecht Schlosser wrote:
>
> On 4/23/21 1:39 PM imm wrote:
>> OK - thanks for that.
>> Cleverer than mine - I only set the cursor image scale once at start
>> up and that's it. Which is fine on this Linux laptop, but...
>> I tried this on my Win10 set up (multiple displays at different scales
>
> With "this" I assume you mean your version?

Yes - only my version I’m afraid because...

>
>> of 1.0 and 1.25) and the effect there is somewhat odd, depending on
>> which screen I start the app on, that sets the cursor size, so
>> although the window resizes as it moves from screen to screen, the
>> cursor does not... which does look a bit odd.
>
> Did you also try my version? Since it would always change the cursor size depending on the scaling of the current screen it should work "as expected". Hopefully.

... our IT unit scheduled my Win10 machine to upgrade to some or other later version. It is still doing it as I type. It’s been at it for a while...
So I didn’t get to try your version (yet), sorry.

[Ian MacArthur]

On Friday, 23 April 2021 at 21:52:22 UTC+1 Ian MacArthur wrote:

On 23 Apr 2021, at 12:55, Albrecht Schlosser wrote:
>
> Did you also try my version? Since it would always change the cursor size depending on the scaling of the current screen it should work "as expected". Hopefully.

... our IT unit scheduled my Win10 machine to upgrade to some or other later version. It is still doing it as I type. It’s been at it for a while...
So I didn’t get to try your version (yet), sorry.

So I tried Albrecht's version, and it handles the cursor scaling across displays pretty well.

But, here's a fun game you can try at home.

When you move a window from one display to another display (with a different scale factor set) then, at least for me under Win10, there's a short "beat" whilst "the system" thinks about it, and then the window rescales to the new display size.

If you are quick, you can move the cursor into the test group *before* that resize happens, and get the cursor to display at the "old" scaling factor size!

[Webb Hinton]

I was returning to this thread because I was wondering if anyone had any thoughts on how scaling the cursor image across different monitors might work, so very happy to see some examples. Any thoughts on why cursor must take an RgbImage and not an SVG?

[Greg Ercolano]

On 4/26/21 11:17 PM, Webb Hinton wrote:

Any thoughts on why cursor must take an RgbImage and not an SVG?

    All of FLTK's image formats derive from Fl_RGB_Image, including Fl_SVG_Image.
    So it should work.. does it not?

[Ian MacArthur]

On Tuesday, 27 April 2021 at 07:28:03 UTC+1 Webb wrote:

I was returning to this thread because I was wondering if anyone had any thoughts on how scaling the cursor image across different monitors might work, so very happy to see some examples. Any thoughts on why cursor must take an RgbImage and not an SVG?

Have you tried the Fl_SVG_Image type? As Greg points out, it may well Just Work if the SVG is loaded and scaled appropriately.

However, in answer to the question, the crux is basically "history" and that the cursor in a lot of systems is (or at least used to be) a sprite handled directly by the GPU hardware, and so there were (are) some constraints on how the cursor and its mask could be loaded (it basically has/had to be a pixel map, or in some cases even, literally, a bit map.)

So generally, to make it work, you need to scale and convert the image you have into a pixel map to be loaded and displayed, regardless of whether the source of the image is a pixel format or a vector format.

Also, as an aside, the convention when posting in this group is to *not* top post, but to interleave responses with the relevant citations, trimming where appropriate...

[Albrecht Schlosser]

On 4/27/21 12:12 PM Ian MacArthur wrote:
> On Tuesday, 27 April 2021 at 07:28:03 UTC+1 Webb wrote:
>
> I was returning to this thread because I was wondering if anyone had
> any thoughts on how scaling the cursor image across different
> monitors might work, so very happy to see some examples. Any
> thoughts on why cursor must take an RgbImage and not an SVG?
>
> Have you tried the Fl_SVG_Image type? As Greg points out, it may well
> Just Work if the SVG is loaded and scaled appropriately.

Yep, that's what I assume too, with two constraints:

(1) as with other image types, use copy(), not scale() to scale the image

(2) call "normalize" before using the image as the cursor

The latter is likely necessary only for SVG images but can be called on
all image types.

Both restrictions may be lifted in further FLTK 1.4 development.

Note that scale() and normalize() and the entire SVG support
(Fl_SVG_Image) are not available in 1.3.