RetroFE forums

It looks like the problem is SDL related, and has to do with keyboard functionality rather than window focus. When I launch an xterm, and launch an SDL program from there (like MAME or RetroFE), and then close that program, my keyboard doesn't work. If I launch a non-SDL program like Firefox in stead, no such problem occurs. It's as if the SDL program grabs the keyboard, and refuses to release it even after it's closed down. Very very odd. It works perfectly well when I use KDE, just not when I don't use a window manager.

I remember that issue as well, but that was different. In that case, two SDL programs were fighting for input focus. In this case the emulator properly grabs focus when it is started, but RetroFE does not take focus back when I close the emulator. Since there's no window manager I cannot grab focus manually (via mouse or alt-tab) either. So far it's baffling.

That doesn't sound like something I touched recently. 😀

Which code did you compile exactly?

No worries; if I add it for the database fields I'll add it for all database fields.

I think those messages should be (changed to) INFO messages. Those are optional files that do not need to be there.

Thank you for the changes by the way. It's great that RetroFE will also be working on MAC-OS. Next step is to have someone do a Windows build to make sure everything still compiles on that OS; I may need to change some code in the hierarchical rom directory support for that.

Normal procedure is to merge my latest code with your branch, double check, and then do a pull request. Version 0.7.20 is fine, but for the future I'd prefer it if you leave the version numbering to me.

I'm aware of the crash, but I haven't been able to reproduce it yet, so I haven't been able to debug the problem yet either. It's on the todo list though, but if you feel like debugging it before I have time, please feel free. I'd appreciate the help in this regard.

I had a closer look; I think I may have found a way to speed things up. I've made some changes to the code that seem to work for me, but I'll do a few more tests before releasing it to the public.
Basically what it currently does is load all art when a new menu item is selected, but the wheel art doesn't need to be reloaded when a wheel was just spinning (new items are automatically added already). With normal wheel art that shouldn't cause much delay, but with box art, like Aeon Nox uses, that can be quite a lot of MBs to read from the HDD/SDD. I've removed the reloading of menu art, and that does appear to speed things up a bit. As said: I'll do some more testing.

Thanks, Agent47. 😀
We do our best.

Sent from my SM-G920F using Tapatalk