I'm using this project (have for a long while) and nested menus open when hovered over in the menu that opens when right clicking on the page. Nested menus in the burger menu (top right) still need to be clicked on.
Well, the downside to this is that you have to compile your own kernel. Totally speculative, but I think most people (who update their kernel frequently) don't do that.
You, struanr and struanr's [3] link are mixing up two different methods used to boot a kernel as an EFI application. It's a common mistake, you'll find it made a lot on the internet.
One method is EFISTUB, which is to use the kernel config CONFIG_EFI_STUB to compile the kernel as a UEFI application. That's what struanr's [1] is about. This method does not bundle the initramfs so the initramfs must be present separately on the ESP so that the kernel EFI process can find it. If you plan to use Secure Boot you can sign the kernel but not the initramfs, and AFAIK there's no way to make the kernel verify the integrity of the initramfs in any other way. So using this method defeats the purpose of Secure Boot.
The other method is to use an external UEFI stub like the one provided by systemd-boot, etc. In this case you use a tool like dracut / ukify (new in systemd v253) to create a UEFI application using an externally provided stub (systemd-boot in dracut and ukify's case, I also remember seeing a tool that used gummiboot's stub) plus a regular kernel plus the initramfs. The initramfs becomes a PE section and the stub sets up the kernel cmdline to use it. The UEFI application is thus self-contained, and signing it lets Secure Boot guarantee correctness of both the kernel and the initramfs. This is what struanr's comment and their [2] and [3] links are about, even though their comment and [3] link claim to be about EFISTUB.
Note that a lot of distributions enable CONFIG_EFI_STUB by default anyway, so even for the first method you may not have to compile your own kernel.
I can't find any documentation about how to do that with CONFIG_EFI_STUB. Arch wiki, Gentoo wiki and the kernel docs all talk about specifying the initramfs as an ESP file path. Are you sure you didn't make a UKI (the second method) ?
Yes, they're sure. The kernel config option CONFIG_INITRAMFS_SOURCE lets you specify the path to either a directory or a .cpio archive. The contents of that will then be embedded into the kernel image itself during build. You end up with one binary containing the kernel code and the initramfs, and if you also enabled CONFIG_EFI_STUB, that one binary happens to also be an EFI application and you can digitally sign it for UEFI Secure Boot (or hash it and enroll the hash into the firmware instead, if you want to avoid the hassle of public/private keys -- but if you're rebuilding regularly, it works out to be the opposite; signing with a trusted key is a lot less hassle than constantly enrolling new kernel image hashes).
Excellent! I've been waiting for this feature for a few years now. So far I've used sndcpy[1] by the same developer, but since video had to be recorded separately, it was a bit of a pain syncing audio and video together.
This was precisely my experience as well. It was magnified by the burden of having to rewrite various zsh scripts and parts of my config that I've cultivated over a decade. I thought Nushell was _neat_, but not neat or useful enough spend time migrating my stuff.
