What Wayland is missing is a solid, reliable toolkit for making simple graphical applications.
Every time that I start designing a GUI the process converged on designing my own GUI because there’s simply nothing that has first class support for Wayland.
I’m also slowly accepting the fact that I might have to implement one someday.
@ahoyboyhoy@system76 Iced is lacking clipboard support (and a few other minor features). A few layers of abstractions/dependencies on which they rely don’t allow easily fixing this. These dependencies include support for several proprietary platform, so a replacement needs to support these proprietary platforms too.
@whynothugo@system76@soller@mmstick may know the answer, but I wouldn't be surprised if support has been added since. All of these libraries are under heavy development it appears.
There’s a large amount of work involved, and at some point you reach a library that supports lots of proprietary environments, so you need to somehow deal with that too.
Personally, I’d replace these dependencies which have bogus abstractions with dependencies that (a) ignore the burden of non-free environment (b) provide proper abstractions. However, this runs contrary to Iced’s goals.
@whynothugo@ahoyboyhoy@system76 Keep in mind that we are not using iced directly, but libcosmic, which uses a fork of iced and has additional Wayland capabilities integrated.
@mmstick@ahoyboyhoy@system76 Oh, I was completely unaware of this. I thought libcosmic used Iced-vanilla as a dependency. I’ll have a closer look next week (after fosdem).
@whynothugo You will notice that COSMIC applets use the sctk feature instead of winit, which provides direct integration with Wayland via the smithay-client-toolkit.
However, we would prefer to use winit for desktop applications because that enables cross-platform support. To that end, we are always working on integrating these features into winit when possible, and then rebasing iced when those changes are merged there.
Add comment