Do we have the same problem in SpinWidget and others with addWidget()?

I don't know, I don't think there are any spin widgets that add other buttons after creation, or are they?

regular non-touch devices don't have front lights so not a problem there, however, yes, technically speaking it is a problem there as well.

Is the issue about non-touch or is it about FocusManager in general?

Edit: already asked and answered #14236 (comment)

In that case I suppose it should work with a regular touch device and a BT keyboard without this patch?

So can it be fixed generally in SpinWidget?
What about other widgets supporting addWidget()? Like InputDialog. If it is good, can we use the similar solution?

the issue stems from those widgets not knowing what to do when during init, focus is set on the Ok button and later on, new buttons are added to them, I believe is the widgets who are at fault here not Focus Manager as this patch demonstrates that a simple refocus snaps it back into place.

this is only a problem on hasDPad and useDPadAsActionKey and not isTouch so, yes, BT + touch device should be fine.

So can it be fixed generally in SpinWidget? What about other widgets supporting addWidget()? Like InputDialog. If it is good, can we use the similar solution?

we only move focus to the ok button on SpinWidgets, so again, not a problem elsewhere. although technically speaking, if that where to change, then probably it would be an issue...

Can you move the focus right after

I... ( [slow motion] logic slaps me in the face) hadn't thought about that, that actually might be a better way.

@Frenzie do you know why the mouse suddenly works in the emulator when running the -t flag?

Hasn't it always, with the caveat that it depends what you click on? The point is to have the same menus and focus/keyboard behavior, not to painstakingly prevent anything that "shouldn't" happen that wouldn't happen if you didn't do it. (It is to a small extent in the sense of not wasting a little bit of memory; if you're thinking of something specific I'd say you're the most likely culprit since who else has been playing with the conditions. ;-)

I remember it not working (the mouse) at all with -t, but then again my mouse experience hasn't been quite exemplary thus far, hence my asking. I haven't changed anything regarding mice though. I certainly don't remember being able to access books from FM with it though

That's just one of the places that's never put any isTouchDevice() conditions around Tap and Hold gestures afaik. It'll waste a few dozen bytes of memory and that's about it. I doubt you'd gain more than a few kilobytes at most if you went around trying to prevent all that, maybe not even a kilobyte, but I suppose it could work as a micro-optimization if @poire-z's okay with it. Nothing wrong with saving a few kB after all, just extremely low hanging fruit.

No real idea what you're talking about :)
Too many "it" in these last messages for me to guess what "it" could be :/

it could be that it was that way that it worked before or it could be that it was not that way it worked before?

🤓

No real idea what you're talking about :) Too many "it" in these last messages for me to guess what "it" could be :/

Oh, I missed this. I meant I see no particular value in preventing being able to tap on things in non-touch mode occasionally but I'm fine if someone wishes to do it to micro-optimize a few kB of memory.