Idea: AI-assisted “compatibility mediator” for legacy apps/games (paths/filesystem/API translation)

Brainstorm
1

Hi KDE team,

I’m a KDE user planning a longer-term move to Linux on my main PC, and I’ve been thinking about a recurring pain point for desktop Linux adoption: legacy software (especially older Windows games) that break due to filesystem/path conventions, timing issues, and API transitions.

My thought: an optional “compatibility mediator” layer, possibly AI-based (not necessarily KDE-specific, but possibly integrated via KDE tooling) that could assist legacy applications by:

  • Translating path conventions (drive letters, forbidden characters like :) into modern filesystem representations.

  • Assisting with legacy app assumptions (case-insensitivity expectations, hard-coded paths).

  • Potentially brokering calls and configuration for compatibility stacks (Wine/Proton, DXVK/VKD3D), reducing manual prefix tweaking.

  • Providing a user-facing UI for common compatibility “fixes” and diagnostics (what’s failing and why), ideally with safe defaults and clear logging.

I realise this crosses into Wine/Proton territory and may be outside KDE’s scope. I’m mainly interested in whether KDE has any relevant initiatives (e.g., UI tooling around compatibility, better diagnostics, integration with Flatpak/Portals, etc.) or whether there’s a place to discuss such an idea with the right upstream projects.

If there’s an appropriate mailing list / issue tracker / discussion forum for this kind of cross-project desktop UX idea, I’d appreciate a pointer.

Thanks for your time and for all the work you do.

Best regards,
Jonathan

2

I feel like for Windows apps this is entirely Wine/Proton territory. And Wine already manages path translation correctly I believe.

For Linux apps that’s literally just a standard well known problem for software development in general, but specifically strong in C/C++ land; traditionally fixed by altering the software’s source code if possible. It’s a hard problem to fix, which is why there’s only compatibility workarounds like library injection or containers.

Neither of these need LLMs. You can write your own app to manage running legacy apps through wrappers with a self-contained database of correct fixes for specific software. There is in fact software that has attempted this before. Said app can be in Qt, in which case it might use KDE libraries, so that would tangentially be KDE related.

Flatpak portals are a bit more elaborate to address.