feat: open links and copy

[Skizzy24]

Make that you can open links from the app description and copy the app package or app description.

[adhirajsinghchauhan]

iced has no support for this, and it won't come anytime soon: iced-rs/iced#36.

There's two ways to copy text if using iced:

1. TextInput but with overridden styles (it's a text input field, so we'll need to to make it look like normal text)
2. Manage selection state ourselves

I don't like (1) because its just ugly to do. A GUI toolkit doesn't support (normal) text selection? Yuck. And then there'd be accessibility concerns, with screen readers for example, but I have no idea if iced even handles that at all.

(2) would increase the amount of code we'd need to maintain, with little actual benefit.

[Frigyes06]

Yeah, this is really a missing feature in iced rather than UAD-ng. It'll have to be a wontfix until we make a new ui or iced implements copiable text

[MathewJake365]

This feature is very useful. And without this we have to type package names and long links by looking at them. Please make this happen.

[Frigyes06]

See: iced-rs/iced#36

[mtxadmin]

It's really weird that such an essential function as copying text is ignored by Iced's devs for years.

Did you think to rewrite this GUI on a different framework, instead of Iced?

[adhirajsinghchauhan]

Iced has more problems than just not supporting text-copy. For example, it still does not have any concept of accessibility. It may not be important to you or me, but it is important to someone out there.

Anyway, while there may be another framework that supports everything we think we want, it will certainly be lacking in other areas where iced shines. It's less about a framework problem, and more just that Rust, as a language, was never really meant for GUIs. It's great for systems programming, and other parallels where memory safety is essential, but outside of that? It's nothing special.

Over time Rust GUIs may have parity with Qt (C++/Python), but even then, they simply cannot compare to the vast featureset of web-based GUIs . Devs who work on web UIs never have to worry about compromising in that respect. Sure, some folks would argue that Electron (web) and familiars add a lot of bloat, and aren't the best for performance, but most people don't care about the difference between 10MB and 100MB size, or 20MB RAM and 350MB, or 1% CPU usage and 5%.

(side note: Compose is looking real great over on the Kotlin/Java side of things, but once again there is a compromise on binary size)

However, in this project it is essential that size & performance is prioritized. After all, it's a debloater tool. Would be odd if its binary is itself bloated. So, we don't really have a choice. We either make the monumental effort to switch over to Qt, or stick with Rust + iced.

I think it's time we bite the bullet and just implement any of the hacky workarounds I mentioned to get this issue resolved. We can't wait for frameworks to do what we want; we'll have to do it ourselves (and maybe contribute upstream). As for which dev is motivated to do that, well, we'll have to see.