Mouse size?

IIRC in the past although the style/shape of the mouse pointer could be changed there was a maximum limit set for its size.

I find the standard pointer too small these days. So it occurred to me to ask: is there now a way to get a bigger mouse pointer?

I think there’s a program (!Pointer?) which causes it to scale up to double size, but I can’t quite remember.

Yes there is one I started it using it when my eye sight was getting worse with the cataract.

Its called !Pointer available from:
https://www.bapfish.org.uk/software.htm

So it occurred to me to ask: is there now a way to get a bigger mouse pointer?

APDL file b112.
“Pointers” is the whole “disk” – there are a number of different items, some of which are strange but there’s a few larger than standard arrow based options.

Thanks for the, erm, pointers to the pointers. :-)

!Pointer is OK, but still gives the blue appearance wheras one of the alternatives from b112 is better as it is closer to the black/white scheme I prefer for Linux. I’d like to edit this but can’t work out how to tweak the appearance! Simply editing the sprites file doesn’t do it. Must be doing something wrong.

black/white scheme

Does this do what is wanted?

REM >ptr_col

REM Joe Taylor [iyonix-support] Re: Mouse pointer colour
REM 10 Aug 2007 16:13
REM The words at 68, 72 and 76
REM are colour numbers of the form &BBGGRR00
REM which determine Pointer-colours 0,1 and 2.

DIM palette% 80
SYS "Wimp_ReadPalette",,palette%
palette%!68=&FFFFFF00              :  REM pointer edge
palette%!72=0            :  REM pointer body
REM palette%!76=&FF00
SYS "Wimp_SetPalette",,palette%
END

As near as I can tell, ptr_default file for the design and the mouse_pal for the colour pallette used.

Swap the bits in from one of the other pointer applets to prove it to yourself.

Yes, the BASIC prog does change the colours of the mouse pointer provided by !Pointer. So that is, for me, a great step forwards. However I’ve also become puzzled by the way that the ‘APDL’ examples seem to do this differently. I can’t see all the details as the code is ‘absolute’. However !Pointer lacks a distinct palette file whereas the !Gem3 example – which is my ‘best’ from the APDL – does. I can see that !Paint can export a palett file, but not how to load and edit one.

And although the above BASIC prog changes the colours I’ve not yet tried to integrate than with !Pointer. Can !Paint edit palette files in isolation? I didn’t get it to load one when I tried. And I’ve not tried, but guess that if I saved the content of ‘palette%’ as a file it would be a palette file which would work?

I’ve now turned the above basic into a BASIC file inside !Pointer that the app then runs before the main code. This seems to work nicely in terms of result. :-)

However my curiosity remains about being able to do this via palette editing of a palette file which can then be loaded. Is there a “how to make a mouse” guide somewhere? And is what !Pointer gives as ‘Big’ really as big as the WIMP allows?

Thanks for the help/info. I’m now much happier with the result, but still curious… :-)

Can !Paint edit palette files in isolation?

Not sure, but even if it can, it won’t be what you need here.

And I’ve not tried, but guess that if I saved the content of ‘palette%’ as a file it would be a palette file which would work?

Nope.

The Wimp palette files are a collection of VDU 19 commands (as with the Paint ones), but it seems that they must conform to a very specific format: 16 colours, 1 border colour, then 3 pointer colours¹.

To make one, you need to crib from Joe Taylor’s code to read the current palette in, then write out the bits that you don’t want to change before adding in the pointer colours.

The format of the colour words is &B0G0R0LL, but for the purposes of setting the pointer colours you can treat the parameter as being &BBGGRR00.

file% = 0
ON ERROR PROCerror : PRINT REPORT$;" at line"; ERL : END

REM Get the existing Wimp palette
DIM palette% 79
SYS "Wimp_ReadPalette",,palette%

REM Create a file to write.
filename$ = "PaletteFile"

file% = OPENOUT(filename$)

REM Output the 16 Wimp colours and the border colour.
FOR i% = 0 TO 15
  PROCwrite_entry(file%, &10, i%, palette%!(i% * 4))
NEXT i%

PROCwrite_entry(file%, &18, 0, palette%!(16 * 4))

REM Pointer Edge
PROCwrite_entry(file%, &19, 1, &FFFFFF00)

REM Pointer Border
PROCwrite_entry(file%, &19, 2, &00)

REM Pointer "Third Colour"
PROCwrite_entry(file%, &19, 3, &FF00)

CLOSE#file%
SYS "OS_File", 18, filename$, &FED

END

DEF PROCwrite_entry(file%, mode%, colour%, value%)
LOCAL red%, green%, blue%

red% = (value% >> 16) AND &FF
green% = (value% >> 8) AND &FF
blue% = (value% >> 24) AND &FF

BPUT#file%, &13
BPUT#file%, colour%
BPUT#file%, mode%
BPUT#file%, red%
BPUT#file%, green%
BPUT#file%, blue%
ENDPROC

DEF PROCerror
IF file% <> 0 THEN CLOSE#file%
ENDPROC

¹ I’ve not checked the source to see what other options (if any) are available. There’s limited documentation, as Wimp palette files were last seen in RISC OS 3.11 (or its updates).

I’ve not checked the source to see what other options (if any) are available.

OK, so I was bored enough to look at the source code¹, which is here

It seems that it must be a 20 colour palette (16 Wimp colours, 3 mouse and 1 border), or nothing. It can either be a “modern”¹ Palette file (in which case it must be 120 bytes long and have the first 16 entries starting with &13, n, &10 for the VDU 19, n, 16... commands and the rest taken on trust), or an “old-style”² file of 60 bytes which presumably contains 20 three byte triplets. The second is taken completely on trust…

¹ All weekend plans having been cancelled thanks to the new lockdown in Leeds, announced 4pm yesterday and into force at midnight.

² It’s all relative, I guess. I’d describe the whole thing as “old-style” myself.

1. A great opportunity to get more RISC OS stuff done
2. Well it’s new as nothing else replaced it given that people stopped using 16 colour desktops a long time ago (apart from the amusement on seeing how bad images look, and to be able to play with wacky palettes).

I’m pleased with the improvement in what I’ve now obtained WRT pointer appearance, so real thanks to people for that! However it does make me feel that it would be nicer if:

1) Even bigger pointers could be used.

2) The sprites for them could, indeed, have more colours.

3) That it could be a matter of essentially making a modern sprite (with transparency) and the user selecting or loading this in a more user-friendly manner. i.e. even having a selection ‘pre loaded’ for a user to choose from.

At present it remains rather arkane. Not as bad ye olde Keyboard handlers, though. 8-]