[AmrikSadhra]

I've been trying to bring up a new display on my Dragon Q6A and am repeatedly installing updated development versions, but must delete them manually each time once I've filled my list with garbage.

Until I get better at DTS development (😭), this has been a decent stopgap. I appreciate it'd be nicer to make "Manage Overlays" handle this, perhaps with a new [-] checkbox on a press of backspace to signify deletion is queued, but it didn't feel worthwile to start modifying librtui to support this.

This also unfortunately allows deletion of Radxa pre-installed overlays - I can (should?) remove this. Let me know!

[github-actions]

No linked issues found. Please add the corresponding issues in the pull request description.
Use GitHub automation to close the issue when a PR is merged

[RadxaYuntian]

I think this is not a very commonly used function, and could cause a lot of unexpected interaction. For example, if new kernel is installed, we will rebuild device tree overlay again, and the user will find their deleted overlays are showing up again.

I think the issue is in your workflow. If you are developing an overlay, you would want to optimize manually using rsetup out of your deployment flow. On Q6A, you can simply use your generated dtbo to overwrite the same file stored in /boot/efi without using rsetup. The embloader will only load the file according to the boot config stored in the /boot/efi/loader/entries/*, so there is no complex process that you have to use rsetup to do.

It is just an easy front end.

[AmrikSadhra]

Thanks for taking a look Yuntian, yes I think you're right, I can't imagine people actually making use of this in light of your comments around proper overlay development.