Bounty proposal: Paint

<aside> Strange. I’ve logged in twice today using NetSurf after reading Recent Posts and forgetting to clear cookies, yet login sticks.
Sadly it doesn’t work with Firefox on my phone. So maybe we’re halfway there? ;-) </aside>

Added: To test repeated failures on a browser that doesn’t like logging in, simply call up the Recent Posts and click/tap on anybody’s name. You’ll go to the login page as you need to log in to be able to lists the posts made by a specific user.
So you log in.
And get forwarded to the login page. Endlessly. I guess it might be a useful diagnostic as tracking down exactly why that is failing might indicate (or indeed be) the problem with forum logins?

It’s really, really odd. I’ve tried all sorts of combinations – loading an existing file, starting from scratch, resizing the window, trying other/no desktop Themes… I’d be less perplexed if it happened to other windows, but this seems to be the only one. I’ve had a quick look at the Templates files, and can’t see anything. Very strange. I’m running a pretty recent OS on the latest MacOS RPCEmu build. I’ll try to update everything to the very latest versions when I get time, but I’m puzzled at what could have such a very specific effect!

Just in case you need another RPCEmu user to chime in…

RPCEmu 0.9.1-pp3 for Mac with today’s IOMD beta ROM works as expected. The sprite file window and the sprite editor window each gets a yellow title bar when clicked.

MacOS RPCEmu

Mention of RPCEmu prompted thoughts of stuck down keys, which should be fixed in the latest Mac version, 0.9.2 patch v2. The fault did not show itself here on the Mac RPCEmu until the alt key was held down, then the Sprite file window title bar resolutely failed to go yellow but other windows did. That turns out to be nothing to with RPCEmu, the same happens on the Titanium.

Hope this may help.

Aha! That sounds like a breakthrough. Thanks.

(I’m not quite sure whether I have the latest patch, though my RPCEmu is 0.9.2.)

(I’m not quite sure whether I have the latest patch, though my RPCEmu is 0.9.2.)

That’ll be a yes.

Have you also got a Macbook with butterfly keys.

Nope – Mac Mini, with wireless Apple keyboard (older model), Mojave.

Sounds like the key sticking problem may affect my configuration still. Not a major problem – if this oddity hadn’t cropped up, I don’t think I was otherwise affected.

The fault did not show itself here on the Mac RPCEmu until the alt key was held down, then the Sprite file window title bar resolutely failed to go yellow but other windows did.

Nice work, David. Looking at the code, it looks like an Alt-click will only do anything on the Sprite File window when the Alt-click is over a sprite file name (to rename the sprite).

…although it could be a red herring as Chris’s keyboard shortcuts are working on the Sprite File window – if Alt is down when the click happens, the focus won’t be set at all, so the keyboard shortcuts wouldn’t work either!

…although it could be a red herring

Heh – maybe. If I perform an Alt-click, then the Sprite File window doesn’t get the focus at all (ie, no yellow titlebar, old window doesn’t lose yellow titlebar, keypresses don’t work), just as expected. Alt-click on a Sprite thumbnail allows renaming to work fine.

So it looks like a stuck Alt might not be the culprit, but are there any other key/click combos that the Sprite File window screens out? Shift? Alt-Shift?

So it looks like Alt might not be the culprit, but are there any other key/click combos that the Sprite File window screens out? Shift? Alt-Shift?

Unfortunately not. And anyway, in that log file you sent me it was running the correct bit of click handling code, setting the caret (which is all it does for the OS to normally change the title bar colour).

If you have logging code, it might be worth keeping an eye on the Gain_Caret event (and the corresponding Lose_Caret). These should reflect when the Wimp gives, and removes, input focus.
Might be useful to see if it is happening at all, or…if it is being given and taken away.

Note for Lose_Caret, the online documentation is not clear. The block returned relates to the window that had the input focus, not the window that now has it.

Yeah I’ll add some logging for that Rick. At the moment I get the caret status and read it back immediately after setting it and confirm that it is indeed set (which it seems to be given that key presses then work). I think I’m going to change the normal and focused title bar colours in the template to red and green as well. That should demonstrate it’s at least using some of the settings from that template! I also want to comment everything out until Paint is just an empty file window accepting and logging clicks.

No idea if this would cause our issue, but I’ve just noticed the Sprite File window doesn’t broadcast a ClaimEntity message to signify it has claimed the caret after setting it on a click. I’m not sure how many other RISC OS applications bother to do it either or what the implications of doing or not doing it would be.

Chris and I have agreed we’ve probably spent long enough on this bug for the time being, although it would be good to hear if anyone else encounters it in the future.

With Chris’s help and copious logging I now have a better idea of the exact symptoms:

• The title bar colours (normally grey and yellow but red and green in the below log) are definitely being set correctly for the Sprite File window from the template and they remain correct across multiple calls to Wimp_GetWindowInfo, which rules out corruption or misconfiguration there.
• Wimp_SetCaretPosition successfully sets the caret for the Sprite File window insofar as it then receives key events and all subsequent calls to Wimp_GetCaretPosition return the Sprite File window’s handle.
• What’s broken is that for Chris, bit 20 of the window flags (“Window has input focus”), is never 1 for his Sprite File window, with the visible effect that his title bar never changes colour. On my own system all calls to Wimp_GetWindowInfo return bit 20 set whenever it has the caret.

You can see this information in the below log. The window handle of the Sprite File window is 538260793.

c.main,2276: spritefile_event_handler Event: 6
c.main,2393: Button event received.
c.main,191: (caret debug) Sprite File window has title bar colour: 11 focused colour: 10.
c.main,193: (caret debug) Window flags, has focus?: 0
c.main,2435: Single click received on sprite file window. m.bbits: 1024
c.main,2099: main_pick sprite: (472, 1286)
c.main,2133: Sprite 1 x 0, 1
c.main,2448: Read caret pos before setting. Existing focused window: 538262041 Clicked on window: 538260793
c.main,2455: About to call set caret pos for window: 538260793
c.main,2476: Reading back caret pos. Current window: 538260793 Clicked on window: 538260793
c.main,191: (caret debug) Sprite File window has title bar colour: 11 focused colour: 10.
c.main,193: (caret debug) Window flags, has focus?: 0
c.main,2484: Left click on grey background. Going to clear selection.
c.menus,1260: menus_insdel_frig
c.main,3650: Help_Process
c.main,3167: Background_Events
c.main,3171: Got Icon bar event 17
c.main,3173: Got Wimp Message 15
c.sprwindow,509: sprwindow_event_handler: event type 1, main_window 0x86394, w 0x20153A19
c.psprite,1272: psprite_read_size
c.menus,1260: menus_insdel_frig
c.main,2276: spritefile_event_handler Event: 6
c.main,2393: Button event received.
c.main,191: (caret debug) Sprite File window has title bar colour: 11 focused colour: 10.
c.main,193: (caret debug) Window flags, has focus?: 0
c.main,2435: Single click received on sprite file window. m.bbits: 1024
c.main,2099: main_pick sprite: (304, 1272)
c.main,2133: Sprite 0 x 0, 0
c.psprite,280: read_psprite_info: (spriteno + 1) 1
c.psprite,285: name is "newsprite"
c.psprite,176: psprite_hasmask "newsprite": true
c.psprite,147: psprite_haspal "newsprite": false
c.main,2448: Read caret pos before setting. Existing focused window: 538260793 Clicked on window: 538260793
c.main,2455: About to call set caret pos for window: 538260793
c.main,2476: Reading back caret pos. Current window: 538260793 Clicked on window: 538260793
c.main,191: (caret debug) Sprite File window has title bar colour: 11 focused colour: 10.
c.main,193: (caret debug) Window flags, has focus?: 0

My personal view is that it’s an obscure bug in the WindowManager, because there’s very little left that could be wrong within Paint, and the RISC_OSLib functions are quite thin wrappers around the SWIs.

I’m not sure how many other RISC OS applications bother to do it either or what the implications of doing or not doing it would be.

Me, for one. I’d never heard of it before (ClaimEntity doesn’t exactly say “You’ve claimed the caret” does it?).

Furthermore, what’s the point of this? With the exception of specifically pushing the caret into your own window, much of the caret handling behaviour is handled automatically by the Wimp; which ought to be sending the appropriate LoseCaret/GainCaret messages for interested tasks.

<looks at StrongHelp> Ah, I see. It isn’t part of the original WindowManager spec as described in the PRMs (or, indeed, the WindowManager at all). It’s a part of the clipboard mechanism. No idea what happens if the message isn’t sent. I guess this is to work around the deficiency that the LoseCaret event doesn’t tell you where it has gone, only that you’ve lost it.
I don’t support clipboard (can’t see it’s much use in Manga) so… I’ll leave it as it is.

I guess this is to work around the deficiency that the LoseCaret event doesn’t tell you where it has gone, only that you’ve lost it.

Why not just call Wimp_GetCaretPosition? It returns the handle of the window that now has it.

No idea if this would cause our issue, but I’ve just noticed the Sprite File window doesn’t broadcast a ClaimEntity message to signify it has claimed the caret after setting it on a click. I’m not sure how many other RISC OS applications bother to do it either or what the implications of doing or not doing it would be.

IIRC the original specs for the clipboard, the idea was that only a single window should have something selected and the message allows other applications/windows to clear their existing selection. This extends at a global level the behaviour of some applications like the Filer or Zap.
Personally, I find the idea stupid and only ever take into account the clipboard flag of that message.

Another Paint bug…

Using Paint 2.31 on RISC OS 5.27 (01 Mar 2020 build).

If “Artist-friendly colours layout” is ticked, saving a 256-colour palette file will produce …interesting… results when that palette file is dragged back to the sprite.

What appears to be happening is that the palette file gets saved in the order the colours appear in the colour picker, not colour number order. Trying to use this palette file elsewhere will “work” (in the sense that all 256 colours have been saved) but dragging the palette file back to the source sprite will scramble the colours in that sprite.

Workaround: Untick “Artist-friendly colours layout” before saving a palette.

Minor feedback: When using Ctrl + scrollwheel to zoom out it’s possible for the window to shrink and no longer lie under the mouse, so you have to keep chasing it around the screen. It would probably be better if the window position + scroll offsets were adjusted to make sure the pixel that’s underneath the mouse stays in the same place on screen (both for zooming in & zooming out). I think that’s basically the same way that most other software handles scrollwheel-based zooming.

What appears to be happening is that the palette file gets saved in the order the colours appear in the colour picker, not colour number order. Trying to use this palette file elsewhere will “work” (in the sense that all 256 colours have been saved) but dragging the palette file back to the source sprite will scramble the colours in that sprite.

I’ve not had time to check the actual code yet, but it sounds the process we came up with for “Edit Palette” which optionally uses the artist-friendly palette order, is getting wrongly applied to a palette you haven’t edited. Can you confirm that this was a default palette that you hadn’t edited?

I had made one or two alterations to the default palette then saved it. Things only went seriously wrong when I dragged the saved palette file onto the source sprite window.

I had made one or two alterations to the default palette then saved it. Things only went seriously wrong when I dragged the saved palette file onto the source sprite window.

Please can we continue this discussion in the bug thread.

Hi everyone, I could do with a little bit of help please testing an issue that Chris has spotted. If you’re running a recent beta image, please can you run Paint and tell me when you click on the working area of the Sprite File window, whether its title bar changes from grey to yellow to indicate acquisition of the input focus?

It was possible that RPCEmu on the Mac might have been a factor. Not here it isn’t at least, the Sprite file window title bar does go yellow.

*fx0
RISC OS 5.27 (08 Mar 2020)
*