OpenEmux 1.10.2

OpenEmux 1.10.2

A single fix, for the mirror image of the last one: this time it was the Flatpak that could not play games.

Flatpak: no game would launch

If you installed both OpenEmux and RetroArch as Flatpaks — the setup our own install instructions recommend, and the natural one on an immutable distro like Fedora Silverblue — clicking any game failed with "No RetroArch core found", no matter the console, and no matter how many cores you had installed through RetroArch. Reported by Marc Mader in #179.

The cores were there all along. OpenEmux looks for them exactly where the RetroArch Flatpak keeps them, ~/.var/app/org.libretro.RetroArch/config/retroarch/cores — and our manifest asked for access to your home directory, assuming that covered it. It does not: Flatpak hides ~/.var/app from other applications' sandboxes even when they have access to everything else in home, precisely so one app cannot read another's private data. So OpenEmux looked in the right place and saw an empty world.

The fix

The manifest now declares a read-only grant for the RetroArch Flatpak's directory. OpenEmux can see the cores again — and only read them; it still cannot write into RetroArch's data. Installs that pair OpenEmux with a native (non-Flatpak) RetroArch were never affected.

If you don't want to wait for the update, the same grant works from the outside on any existing install:

flatpak override --user --filesystem=~/.var/app/org.libretro.RetroArch:ro io.github.guilhermefeitosa66.OpenEmux

After updating to 1.10.2 that override is no longer needed and can be dropped:

flatpak override --user --reset io.github.guilhermefeitosa66.OpenEmux

Verify what you downloaded

Every release ships a SHA256SUMS file. Download it next to your artifact and run:

sha256sum -c SHA256SUMS --ignore-missing

OK means the file is exactly what was published. Anything else means it is corrupt or has been tampered with — don't run it.

Upgrading

flatpak update brings the new permission with it — nothing to configure, and Flatpak will list the new filesystem access for you to see. Settings, playlists, artwork, save states and input profiles are all kept. The .deb, .rpm and AppImage are rebuilt for completeness but carry no behavioural change.

OpenEmux 1.10.1

OpenEmux 1.10.1

A single fix, for a bug that made games unplayable in a way that pointed nowhere near its actual cause.

Games ran far too fast

If you installed OpenEmux from the .deb, the .rpm or the AppImage, games could run at several times their normal speed — on a 240 Hz display, up to four times too fast. The Flatpak was unaffected, which made the whole thing look like a broken build.

It was not a build problem, and it was not a speed setting. It was audio.

OpenEmux ships its own copy of RetroArch, but launches it against the RetroArch configuration already on your machine. If that configuration names an audio driver the bundled RetroArch was not compiled with — pipewire is the common one, and a perfectly ordinary value on a modern desktop — RetroArch cannot honour it, falls back to ALSA, and ALSA fails on a PipeWire system. Audio never starts.

That is where the speed comes from: RetroArch keeps emulation in time using the audio clock. Take the audio away and the pacing falls through to the display's refresh rate, so a 60 fps console is driven at whatever your monitor runs at. Nothing on screen suggests audio had anything to do with it.

The Flatpak escaped this because it plays through the RetroArch Flatpak, a build that does have the pipewire driver.

The fix

OpenEmux now chooses the audio driver from what your system actually offers, instead of inheriting one from a configuration that may have been written for a different RetroArch. When a PulseAudio socket is reachable — which covers both real PulseAudio and PipeWire, since PipeWire serves the same socket — it asks for pulse, a driver present in every RetroArch build OpenEmux launches. When nothing is found, it says nothing at all and leaves your setup exactly as it was.

If you run a deliberate JACK or bare-ALSA setup, runtime.retroarch.audio_driver in ~/.openemux/config.yaml takes an explicit driver name, or inherit to go back to the previous behaviour.

Verify what you downloaded

Every release ships a SHA256SUMS file. Download it next to your artifact and run:

sha256sum -c SHA256SUMS --ignore-missing

OK means the file is exactly what was published. Anything else means it is corrupt or has been tampered with — don't run it.

Upgrading

Nothing to do, and nothing to undo. Settings, playlists, artwork, save states and input profiles are all kept. If you had previously changed an audio setting by hand trying to fix the speed, you can put it back the way you like it — OpenEmux no longer depends on it being right.

OpenEmux 1.10.0

OpenEmux 1.10.0

This one is about controls. A detailed hands-on test of 1.9.2 from the community turned up something uncomfortable: on almost every console, OpenEmux was sending RetroArch no gamepad configuration at all. Games still responded, because RetroArch maps common pads by itself — which is exactly why nobody caught it. That single bug was hiding a dozen others behind it.

So this release fixes the foundation, and then builds the controller settings that should have been there all along: analog sticks that work, the hotkeys that were missing, deadzone and sensitivity for a worn stick, and control changes that reach a game while you are playing it.

Your controller is actually configured now

OpenEmux wrote only one input device's mapping — whichever was set as the profile's "input device", which defaulted to keyboard on every console. In practice that meant 30 of 31 profiles sent RetroArch nothing for the pad: no button map, no hotkeys, no analog stick.

There was never a reason to choose. RetroArch keeps keyboard and joypad bindings under separate keys, so both can be live at once without colliding. Both are now sent, always. The N64 profile that produced the report went from zero controller settings to 26, the analog stick among them — which is very likely why the stick did nothing in Super Mario 64.

The "Input device" row no longer decides what reaches the emulator. It is what it always looked like: which mapping you are currently editing.

Change your controls without losing your game

Previously, remapping a button while playing did nothing until you closed the game and opened it again — and the relaunch we offered started you over from the beginning, which is not a fix anybody wants mid-boss.

Now, saving your controls applies them to the running game and puts you back exactly where you were. OpenEmux snapshots the game to an internal slot, relaunches with the new bindings, and restores the snapshot — your own save states are never touched. If the core cannot save states, nothing is relaunched and OpenEmux tells you the change waits for the next launch, rather than gambling with your progress.

The hotkeys that were missing

Nine more actions can be bound, each with a keyboard default: rewind (w), pause (p), slow motion (o), hold to fast-forward (h), screenshot (F8), game focus (g), and disk control — eject (F9), next disk (n), previous disk (b).

Disk control is not a convenience. Without it, a two-disc PlayStation, Saturn or Mega CD game simply could not be finished from inside OpenEmux.

Save and load state hotkeys also work on a gamepad for the first time: the defaults pointed at buttons 11–15, which most controllers do not have. And Restart is now a bindable hotkey rather than a header button, so you can reset a game without reaching for the mouse.

Analog sticks, from both sides

• Play the stick from the keyboard. An N64 or PlayStation game that needs analog could not be played without a pad. The stick is now four bindable directions on i / j / k / l — WASD-shaped, but on the right hand, leaving the arrows on the D-pad.
• Let a pad's D-pad move the stick, per console, for games that only read analog.
• Forced analog-to-digital modes are offered where they are the only ones that do anything — the consoles whose cores read the stick natively.
• The stick's axes are now actually declared to RetroArch, so the analog-to-D-pad setting stops being a no-op.

Tune it to your hardware

A drifting or worn stick is one of the most common real-world controller faults, and the app offered nothing for it. Deadzone, sensitivity and the axis threshold are now settings, alongside vibration strength, input latency, game focus and the core's own button names.

You can also choose which controller the core is told is plugged in — a PlayStation boots as a digital pad, and an analog game needs DualShock selected here just as it does in RetroArch.

These are global rather than per console: a stick drifts the same on every system, and setting the deadzone thirty-one times is not a feature. Each carries RetroArch's own default, and a value you have not changed is not written at all — an untouched install produces exactly the configuration it did before.

Keyboard bindings that RetroArch can read

Keyboard bindings were stored under GTK's key names, which RetroArch cannot parse — so some keys silently never worked. They are now written as names RetroArch resolves. Restart, mute, turbo and save-slot stepping also get sensible keyboard defaults, and the RetroArch hotkeys that would have fired alongside them are cleared, so one key does one thing.

The volume slider reaches the game

Dragging the master volume did nothing while mute worked, which was a strange pair of symptoms. RetroArch reads its control channel once per frame, and a drag was firing dozens of steps into a single frame, where nearly all of them were dropped. The steps are now paced, so the slider moves the volume of the running game.

Artwork you can see and fix

Missing artwork is now visible. In the cartridge shelf a game with no art quietly rendered a blank sticker, so you could not tell it apart from one that simply had a plain label. A muted badge now marks it in every view, there is a "Only without artwork" filter in the view menu, and the empty cover carries a Search artwork… button that opens the artwork manager right where you noticed the gap.

Cover sync also gained a last-resort fuzzy pass for titles that no exact match reaches — Aero Fighters (Sonic Wings) now tries both halves — and the sync summary names the games that missed instead of only counting them.

Covers no longer stall the interface. Decoding ran on the main thread with one unbounded thread per ROM, which saturated a single core and made a large library feel stuck. Decoding now happens off the main thread on a bounded pool.

Every icon ships with the app

Screenshots from users showed blank buttons and empty menu entries. The interface asked the desktop's icon theme for around sixty symbolic icons, and themes that do not inherit from Adwaita — Mint-Y, Papirus, Breeze — simply do not have them.

All of them are now bundled inside OpenEmux and used as a fallback: your desktop's theme still wins wherever it has the icon, and nothing can be missing where it does not. The build now fails if an icon is ever left out, in all four package formats.

Around the app

• Settings is one click from the header, instead of only through the menu, and a console's page can jump straight to its controller settings.
• Set a console's default core and shader from the sidebar, without opening Settings at all.
• Context submenus open on hover rather than needing a click, and the ROM menu has been tidied.
• The window opens at 80% of your screen instead of a fixed box, so it fits laptops and large displays alike.

Language and first run

The five stub translations — Spanish, French, German, Japanese and Chinese — are complete, and changing the language now updates every part of the interface immediately, including the window behind the dialog. "Preferences" is called Settings, matching the rest of GNOME.

The Welcome Assistant was rebuilt around a real misunderstanding: people were reading "New collection" as the way to import ROMs. Collections are now playlists everywhere, importing has its own labelled button, the empty library page leads with drag-and-drop, and the first slide carries a language picker — because someone who cannot read that slide cannot find Settings either.

Verify what you downloaded

Every release ships a SHA256SUMS file. Download it next to your artifact and run:

sha256sum -c SHA256SUMS --ignore-missing

OK means the file is exactly what was published. Anything else means it is corrupt or has been tampered with — don't run it.

Upgrading

Nothing to do. Settings, playlists, artwork and input profiles are all kept.

Your existing input profiles are migrated once to pick up the new hotkey defaults, and — this is the one worth knowing — your gamepad will now be configured by OpenEmux where it previously fell back to RetroArch's own mapping. If a pad behaved a certain way before and you preferred it, Settings → Input is now the place that decides.

Thanks

This release exists because @mozertdev worked through 1.9.2 in detail on Diolinux Plus and wrote up everything that was wrong with it — including the gamepad bug that was hiding behind RetroArch's autoconfig. Most of what is above traces back to that report.

OpenEmux 1.9.2

OpenEmux 1.9.2

One change, and the honest reason for it: this was meant to be part of 1.9.1 and missed the build.

The artwork Import tab

Opening a game's artwork manager and going to Import used to split the height between a drop hint and the image you had just dropped, with the edit controls on one row and Save as on another.

• The image gets the whole area. The drop invitation steps aside once there is an image, and a trash button in its top corner clears it when you want to try another one.
• The controls are one row — crop, flip, rotate, reset, and the destination the image will be saved as — instead of two toolbars competing for the eye. Crop and Reset carry icons like the transforms already did.

Everything else in this release is 1.9.1: the context-menu crash fix, per-ROM artwork sync as a background action with the manager on its own menu entries, search results laid out on the library's grid with a check on the picked image, and a cancel button for a running search. If you are coming from 1.9.0, the 1.9.1 notes cover all of it.

Upgrading

Nothing to do. Settings, playlists, artwork and input profiles are all kept.

Verify what you downloaded

sha256sum -c SHA256SUMS --ignore-missing

OK means the file is exactly what was published. Anything else means it is corrupt or has been tampered with — don't run it.

OpenEmux 1.9.1

OpenEmux 1.9.1

A patch release on top of 1.9.0, built around one crash and the artwork work it exposed.

The crash

Picking an entry in a game's context menu could take the whole app down — the report that started this was Sync label… on a SNES game, which closed OpenEmux with a segmentation fault and no message.

The action ran from inside the click, while the menu was still coming down: it opened a window, the grid dropped the popover in the same pass, and GTK crashed laying the main window out, still holding a pointer focus that pointed into a menu whose surface had just been destroyed.

Menu entries now close the menu first and run the action once that teardown is over. This was never specific to artwork — every context-menu entry took the same path — so the fix covers all of them.

Crashes below Python cannot be caught, only recorded. OpenEmux now writes the native stack into its log on the way down, and logs unhandled exceptions from background threads, so the next one arrives as a report instead of a blank terminal.

Sync and manage are two different things

Sync cover… and Sync label… opened the artwork manager, which is not what they say. They are the quick action now: click one and that game's artwork is fetched in the background, through the same provider chain the library-wide sync uses. Because asking for one game by hand usually means what it has is wrong, the fetch replaces artwork already on disk rather than skipping it.

The manager gets entries of its own — Manage cover… and Manage label… — for when you want to look through what the providers have, or import your own.

The artwork manager

• Results are laid out on the library's own grid, at its largest zoom, with the console's cover proportions. Judging a cover from a 160px thumbnail was never going to work.
• The picked image is marked with a check stamped on the artwork itself, so what Save will apply is not left to a thin outline.
• A running search can be cancelled. The provider chain can take a while, and closing the window was previously the only way out.
• An imported image gets the whole area. The drop zone steps aside once there is an image, with a trash button in the corner to clear it and pick another.
• The edit controls are one row — crop, flip, rotate, reset and the save destination — instead of two competing toolbars.

Upgrading

Nothing to do. Settings, playlists, artwork and input profiles are all kept.

Verify what you downloaded

sha256sum -c SHA256SUMS --ignore-missing

OK means the file is exactly what was published. Anything else means it is corrupt or has been tampered with — don't run it.

OpenEmux 1.9.0

OpenEmux 1.9.0

The biggest release so far, and it pulls in three directions at once: making the shelf yours, letting you act on many games instead of one, and putting the running game under your control without leaving the emulator window. It also ships OpenEmux as a Flatpak for the first time.

Colour your collection

Cartridge view draws every game inside its console's shell — and now that shell has a colour. Right-click a game → Cartridge color and pick from a palette of twelve, on top of the original art.

Real shelves were never one colour: special editions, regional runs and Pokémon-style carts came in red, yellow, gold and clear plastic. Use it for that, or as your own filing system — one colour for "finished", one for favourites, one for hacks. The choice is remembered per game, follows a rename, and is dropped when the game is deleted.

The palette covers the full hue circle at even spacing, so any two picks are told apart at thumbnail size, and every tone is desaturated enough to read as moulded plastic rather than a UI accent. Adding a colour is a pure art change: drop a new SVG next to the console's frame and it appears in the menu.

Select many, act once

Building a selection now works the way it does everywhere else on your desktop:

• Mouse — Ctrl+click toggles a game, Shift+click takes the range, Ctrl+Shift+click adds a range to what you already have, and dragging across empty space rubber-bands over whatever it sweeps.
• Keyboard — Shift+arrows extend the range from wherever you are standing, Ctrl+arrows move without selecting, Ctrl+Space toggles, Ctrl+A takes everything the search is currently showing and Ctrl+Shift+A clears.
• Gamepad — hold Ⓐ on a game to enter selection mode: Ⓐ toggles, a trigger held with the D-pad extends a range, Ⓨ selects all or none, Ⓧ opens the actions, Ⓑ leaves. On-screen hints explain it as you go, so nothing has to be memorised.
• List view — a checkbox on every row, and a header checkbox that selects everything shown, with an indeterminate state when only some are.

Select-all always respects the active search, and changing console clears the selection, as before.

Artwork, under your control

Per-ROM artwork manager — Sync cover… (or Sync label… in cartridge view) opens a window that searches every enabled provider by name or by ROM hash and shows you what each one actually has, each result labelled with where it came from. Pick the one you like. An Import tab takes an image from your computer by drag-and-drop or file chooser, with crop, flip, rotate and reset — your original file is never modified.

Providers are now a list you order. Preferences → Library shows each source with move-up/down and an on/off switch: the topmost enabled one is tried first, the rest are fallbacks. Your existing cover-source setting carries over untouched.

A new source: the OpenEmux mirror. The project now hosts its own box-art set, so there is a fallback fully under OpenEmux's control rather than only third-party servers. Fresh installs try it first, then libretro, then ScreenScraper — the one that needs credentials and has a daily quota comes last.

Cover sync also got two fixes worth naming: syncing labels no longer skips games that merely have box art, and downloads keep their real file format instead of being renamed to .png.

Command the running game

Enabling RetroArch's control channel means OpenEmux can finally talk to a game in progress:

• Volume — a slider and a mute button in the header while a game runs, remembered for the next launch. Prefer the keyboard? Volume up, volume down and mute are now bindable hotkeys.
• Save states — OpenEmux keeps them in its own per-console folder, and the ROM's context menu has a Load state list showing every slot with the date and time it was saved (empty ones are shown as empty). Pick one and the game starts from there. Which slot the save/load hotkeys act on is a setting, and stepping between slots is bindable too.

Saving and loading stay on RetroArch's hotkeys, where they belong — reaching for the mouse mid-game was never going to be an improvement.

Controls that fit your hands

• The analog stick can drive the D-pad, so both work at once with no re-mapping. On per console, and off by default for the consoles whose pads use the stick natively (N64, PlayStation, PSP, GameCube, Saturn) so a game never loses its analog.
• Turbo / autofire — bind a Turbo modifier and hold it with any button to auto-fire, with adjustable period, duty cycle and mode per console. It stays unbound until you want it.
• The input mapping is now split into Game Controls and System Hotkeys, so the buttons a game reads are no longer mixed in with the frontend's own actions.

Around the library

• The view mode switcher moved into the header as three buttons — cover grid, cartridge grid, compact list — one visible click each, collapsing back into the menu on narrow windows.
• Newly imported games fetch their artwork automatically, labels only for the consoles that have a cartridge to put them on.

OpenEmux as a Flatpak

The Flatpak is back and is now a first-class release format. Two ways in:

# The repository — updates arrive with `flatpak update`
flatpak install -y flathub org.libretro.RetroArch
flatpak remote-add --if-not-exists --no-gpg-verify openemux \
  https://guilhermefeitosa66.github.io/openemux-flatpak/repo
flatpak install -y openemux io.github.guilhermefeitosa66.OpenEmux

Or grab the single-file OpenEmux-1.9.0.flatpak below and flatpak install -y ./OpenEmux-1.9.0.flatpak. Games are played through the RetroArch Flatpak, which manages its own cores.

Verify what you downloaded

Every release from now on ships a SHA256SUMS file. Download it next to your artifact and run:

sha256sum -c SHA256SUMS --ignore-missing

OK means the file is exactly what was published. Anything else means it is corrupt or has been tampered with — don't run it.

Upgrading

Nothing to do. Settings, playlists, artwork and input profiles are all kept. Your cover-source choice is carried into the new provider list, existing input profiles leave the new hotkeys unbound until you bind them, and save states you already had are found in place.

OpenEmux 1.8.0

OpenEmux 1.8.0

A release about the first five minutes. New users now get a guided tour instead of a blank library, and cover art starts filling in on its own — no account, no configuration. Everything an existing install already had is untouched; the new pieces are there to make the start smoother.

A proper welcome

The first time OpenEmux opens, a Welcome Assistant now walks you through the essentials: importing ROMs, adjusting how each console's shelf looks, syncing cover art, applying shaders, the keyboard shortcuts, and driving the whole thing from a gamepad.

• It is a set of illustrated slides with a topic list on the side, so you can read it front to back or jump straight to the one thing you care about.
• Back / Next, a page indicator, and full keyboard and gamepad navigation — the same as the rest of the app.
• A Show on startup checkbox sits at the bottom: leave it on to see the tour again next launch, or turn it off once you are settled.

It is reopenable any time from the main menu, and from Preferences → System, which also carries a matching Show on startup switch and a button to launch the tour on demand.

Cover art out of the box

ScreenScraper is a richer art source than the libretro thumbnails — it matches by ROM hash rather than filename and carries cartridge-label scans — but until now using it meant requesting a developer account and pasting credentials into Preferences.

Official builds of OpenEmux now bundle the developer credential, so ScreenScraper works out of the box: pick it as a cover source and covers start resolving, no setup required.

• The old developer-credential fields are gone from plain view — they now live behind an Advanced disclosure, for the rare case of overriding the built-in credential with your own developer account.
• Adding your own ScreenScraper account (username + password) is still worthwhile and encouraged: it draws on your own daily quota rather than the shared one, for faster, more reliable scraping.

A steadier sidebar

Moving the pointer down the console list used to make the rows twitch — the per-console options button appeared on hover and nudged everything below it. The list now holds still: only the highlight and that button's fade change under the cursor, never the layout.

Upgrading

Nothing to do. Existing installs keep their settings; the Welcome Assistant simply won't reappear if you have already turned it off, and cover sources you have already chosen are unchanged. If you had previously entered ScreenScraper developer credentials by hand, they still work and now sit under Advanced.

OpenEmux 1.7.0

OpenEmux 1.7.0

Four features that move the same choices out of config files and into the interface: which shader a game runs, which core runs it, how each console's shelf is laid out, and how the library is grouped. Every one of them still has a sensible default, so an untouched install looks and behaves exactly as it did — the new controls are there when you want to diverge, and invisible when you don't.

A shader per game

Shaders have been per console for a while — a CRT mask for the 16-bit machines, an LCD look for the handhelds — which is the right granularity most of the time. It is the wrong one for the odd game that renders at a different resolution than the rest of its console, or the FMV-heavy title that wants no shader at all.

Right-click a game and there is now a Shader submenu:

• The same list Preferences offers for that console, honouring the Show all shaders switch.
• Use console setting (…) is the default and shows, in parentheses, what it currently resolves to — so you know what you are changing away from.
• Disabled is a distinct choice: "no shader for this one game" is exactly what this is for.

The choice is remembered, follows a rename, and is dropped when you delete the game. Changing a console's shader in Preferences never disturbs a game that carries its own.

A core per console, and per game

Until now the only way to influence which libretro core ran a game was to hand-edit config.yaml. Both levels are in the interface now.

Per console — a new Cores page in Preferences, one row per console, listing the cores you actually have installed plus an Automatic entry at the top. Automatic is the default and stores nothing; the row's subtitle tells you which core it resolves to, and a console with no core installed says so rather than offering an empty list. The picker reads each core's .info file, so you pick Snes9x, not snes9x_libretro.so.

Per game — a Core submenu on the ROM context menu, listing only the cores that can run that system. Automatic clears the override and returns the game to the console decision.

Choose a core that needs a BIOS you do not have and OpenEmux warns you. A per-game override whose core is later uninstalled quietly falls back to the console — or automatic — choice instead of failing the launch.

A layout per console, per view

View mode, sort order and zoom were one global setting for the whole library. But the right presentation differs by console: cartridges for the systems whose shelf art is good, covers for the ones where it is poor or missing; a large zoom for a short Favorites page, a tight one for a 400-game console.

They are now a global default that any page can override. The header layout menu names the page you are on — Layout for: SFC — and a Use the global layout toggle switches between following the global default and giving that page its own. Following global, the controls change the global default, so it can still be set from anywhere; overridden, they change only that page. No control in the menu is ever a switch that appears to do nothing.

The sidebar's console context menu gained a Layout ▸ shortcut with the same options, the fast route when setting several consoles in a row.

Existing configurations keep exactly the layout they have today — every page follows global until you deliberately break consistency.

Custom collections

The sidebar could group games two ways: All, and one row per console. Favorites was the only grouping you defined, and it was a single unnamed bucket.

Now you can make as many named collections as you like — Fighting spanning SNES, Mega Drive and PlayStation; Racing; To finish; Kids — each mixing consoles the way All does.

• Create one from the New collection button at the bottom of the sidebar, or by right-clicking empty sidebar space.
• Add to collection on a game's context menu lists every collection, with New collection… to create one and add the game in a single step. It works on a whole multi-game selection at once, and shows a check for collections a game is already in.
• Remove from this collection while viewing one — this never touches the file on disk, unlike Delete.
• Rename and delete a collection from its own sidebar menu; deleting asks first and makes clear the games themselves survive.

Collections persist across restarts, follow renamed or moved games, drop deleted ones, and are reachable by keyboard and gamepad like everything else in the sidebar.

Upgrading

Nothing to do. Every new setting defaults to the behaviour you already had: shaders and cores stay on Automatic / the console setting, every page follows the global layout, and you have no collections until you make one.

OpenEmux 1.6.0

OpenEmux 1.6.0

Your library, arranged the way you want it: three layouts, six sort orders and a zoom control, all one click from the toolbar instead of buried in a settings dialog. OpenEmux also speaks your language on first launch now, and the controller finally reaches every part of the interface — including the button that was, until this release, impossible to bind.

Choose how the library looks

A View Mode button sits in the header, next to search:

• Cover Grid — box art on a grid
• Cartridge Grid — the shelf look, still the default
• Compact List — one game per row: thumbnail, title and platform

The cartridge frame used to be a switch inside Preferences, which is the wrong place for something you change while looking at your games. The Preferences row is still there and still works — it just mirrors the toolbar now.

Zoom the artwork

The same menu holds a − 100% + stepper, or use Ctrl+plus, Ctrl+minus and Ctrl+0. Six steps from 50% to 200%, remembered between sessions.

Zoom does not just scale the covers: the gaps between cards move with them, so zooming out gives you more games and a tighter grid, not the same sparse layout with smaller pictures. At 200% three columns of large art; at 50%, eight.

Sort the library

Six orders, behind Sort by in the same menu:

Name (A-Z) / (Z-A)	case-insensitive, so lowercase titles are not exiled after the Z's
Recently played	see below
Recently added	when your copy of the file appeared, not when the ROM was made
File size	largest first
Platform	grouped by console, alphabetical inside each

The choice applies to every page — each console, Favorites and All — and is remembered.

Recently played needed something OpenEmux never recorded: it now stamps each launch in ~/.openemux/play_history.json. Nothing is uploaded anywhere, renaming a game carries its history with it, and deleting one forgets it. The order starts out flat, of course, and fills in as you play.

It starts in your language

OpenEmux opened in English no matter what your desktop was set to. It now reads your session's locale on first launch and picks the closest translation it ships: pt_BR and pt_PT both get Portuguese, es_MX gets Spanish, fr_CA gets French, zh_TW gets 简体中文, and anything unsupported still gets English.

Your own pick always wins: choose a language in Preferences and it stays chosen. If you never picked one — which includes every existing install still sitting on the English default — OpenEmux now follows your desktop.

Remapping a controller works

Assigning B on an Xbox pad used to close the configuration dialog instead of storing the binding, because the interface was still reading that button as "go back". Any button whose meaning overlaps with UI navigation had the same problem, which made the pad essentially unconfigurable from within OpenEmux.

The remapping dialog now takes the controller for itself while it waits. Navigation goes quiet — held directions stop repeating too — and comes back the moment the mapping is stored or cancelled.

The controller reaches the rest of the interface

Select opens the main menu, so Preferences, Keyboard Shortcuts and About are finally reachable without a mouse. Press it again to close it.

The right analog stick steers as well as the left one. The triggers deliberately do not: a resting trigger reads as a held direction on most pads.

Focus comes back where you left it. Closing a dialog or a menu could leave the window with nothing focused at all, which on a controller is a dead end — every direction resolves against nowhere. Close Preferences with B now and you are back on the same game you opened it from.

You can see where you are. GTK only draws focus rings once it decides you are using a keyboard, and focus moved by a gamepad did not always qualify. While you are on a pad or the keyboard, the rings stay visible.

Also in this release

• List rows share one thumbnail column, so titles line up down the page whatever shape each console's box art is.
• All and Favorites no longer force their own name ordering over the one you chose.

Upgrading

Nothing to do. Your existing settings carry over: the cartridge switch becomes the matching view mode, and the language behaviour is described above.

OpenEmux 1.5.2

OpenEmux 1.5.2

A fix for the AppImage, where every game in a console's library showed an empty
placeholder instead of its cartridge and cover art. The .deb and .rpm are
unaffected — nothing else changed.

What went wrong

Compositing a cover into a cartridge frame hands a cairo drawing context to the
SVG renderer, and that crossing needs the GObject-introspection ↔ cairo bridge
(python3-gi-cairo). It was never bundled. Running from source, or from the
.deb/.rpm, it comes from the system, which is why this only ever showed up
in the AppImage.

Worse, the failure raised an error the renderer did not catch, on the thread
that loads cover art. That killed the whole card update, so the game lost its
plain cover too and fell back to the generic placeholder — a missing frame
should only have cost the cartridge, not the artwork.

Both are fixed: the bridge is bundled, and a cartridge that cannot be
composited now degrades to the plain cover.

The check that was missing

The build verified the pieces — image loaders present, Rsvg bindings present
— and every one of them passed while the bundle could not actually draw a
cartridge. It now composites a real frame inside the finished AppImage and
fails the build if nothing comes out, which reproduces this exact bug.