I feel attacked ;)

The above said, it wasn’t hard to find a project using XDG and a JSON mapping file (basically your idea fleshed out in python) to get where you want to go if XDG is enough: https://github.com/JonTheNiceGuy/usbrowser

You’re not going to like this answer - there’s a bunch of different ways depending on the app(s) and the desktop environment. The Arch wiki goes over it in detail: https://wiki.archlinux.org/title/Default_applications

I would guess that focusing on the XDG spec and covering Gnome, KDE and Xfce (Xfce can be replaced with anything else like Cinnamon that comes with Mint, “non Gnome or KDE”) is the best plan of attack for what matters to 80%+ of the population.

Al, we need to optimize. Speed and efficiency to prevent Ctrl+C.

Write 16MB of zeros to the beginning of the boot device to overwrite the boot blocks (16MB being extra cautious, 8MB is fine) and if you want to double the roulette fun, have it fork in parallel and do the same thing to the EFI partition (if you have one). Extra credit: fork a 3rd time and write 16MB to the end of the disk, nuking the backup GPT structure sitting there. This can all be a fun inline “one-liner” to appeal to cut & pasters. curl pipe bashers.

It’ll happen so fast there’s no stopping it, their only way out now is to get the running system saved off that disk while it’s mounted.[1] But your nuke is invisible, how long until they find out trying to reboot? Devious Al, you’re just devious.

[1] there is a way to recover if you build identical machines, like VMs or VPSes - a tool such as gdisk can pull the table(s) off one to a file, which can be pushed onto another. We’ve recovered $customer mistakes at $ITjob doing this before, it works. It might not boot properly, but it can contain enough filesystem boundary information to be able to recover a partition manually (rescue).

por qué no los dos?

I would assume your system is using systemd (I don’t use Kubuntu specifically); the laptop lid is (now in 2026) controlled by the systemd infrastructure - it’s a matter of setting a config option and this should fix you up. Arch as usual has the best wiki on the subject:

https://wiki.archlinux.org/title/Power_management#ACPI_events

You’re probably looking at HandleLidSwitch* options. There’s still nothing wrong with the manual disable to /proc/acpi/wakeup to cover your bases (layers of the onion), I’m fighting with a “modern” laptop that only has s2idle and it’s terrible compared to S3 - I’m in ACPI wakeup hell and still trying to figure out what’s causing it.