I'm excited that they push Iced [1], a Rust-based cross-platform UI framework. Probably not the Rust framework which I would've betted on as the most promising one, but with the broad support and larger adoption I hope it will catapult it into the mainstream, we really need a good UI library that's not a web renderer. I was also quite excited about GPUI [2] but there seems to be very little activity in the repo for now (hard to judge though, I imagine they're just busy hacking on the editor).
I wanted to write a desktop app with Rust for a while and considered Tauri, Flutter (via rust-flutter-bridge) or a native framework like Iced, I think with the larger adoption it might make sense to go with Iced, though it's probably still much more experimental than frameworks like Flutter.
I assume this means accessibility is roughly zero. I'm sure it was a ton of fun for the engineers to write with something exciting and new, but the downsides of using a half-baked UI framework are significant.
I tried Halloy [1], an IRC client that's listed as the first showcase app on Iced's site. It's pretty, but it doesn't even support triple-click selection or context menus. There is no menubar on macOS.
Iced is very nice for an upstart UI framework - I don't want to minimize the amount of work that they've put into it, and how cool it is that they've gotten so far - but shipping a desktop environment based on it is shortsighted.
[1]: https://github.com/squidowl/halloy
What library that addresses your complaints do you think they should have used instead of iced?
GTK? Qt? They're not exciting, but they sure do work.
And then it would be just another minimalist desktop environment trying to compete with Gnome.
Well, sure? Is that not what this already is? They could even write their GTK or Qt apps in Rust if they wanted to!
Using a native toolkit built for Rust has massive productivity benefits when writing programs in Rust. Last I checked the GTK bindings for Rust were rough at best, I don't even know if they exist for QT.
The people using the DE don't care what programming language it's written in, so it's absurd to ask users to accept a rough/inferior/buggy/inaccessible system because an experimental UI library was more enjoyable for the developers.
Then the can just use Gnome ...
They won't have to accept anything if the developer never writes code in the first place... this is a ridiculous argument. How do you think most open source desktop software gets made?
These are both terrible on macOS and Windows (they look ugly and are hard to build), and very poorly integrated in other languages than C/C++.
Way worse choices in my opinion.
I don't think COSMIC is gonna be ported to OSX and Windows. In fact you can quote me on that, I'd rate the chances of me being wrong at infinitesimal.
Hard disagree. I can't even tell the difference the majority of the time, and I work with Qt every day (and love it)... probably most other people can't tell either. I never found it hard to build, and as far as other languages go, I have had great success using it from both Python and Swift rather easily. I don't think there are any better choices for a stable and mature framework with anywhere near the feature set.
Halloy has context menus. https://images2.imgbox.com/20/05/yOa1IrVS_o.png
Iced has accessibility listed as the first item on its roadmap after the upcoming 0.13 release. https://whimsical.com/roadmap-iced-7vhq6R35Lp3TmYH4WeYwLM
You're misjudging an experimental library for not having every feature you could ever want before an 1.0 released without doing your diligence. The docs literally open with
https://docs.iced.rs/iced/Not text editing context menus like any native app.
As I said, Iced looks awesome. But it's also, as you said, experimental. Using an experimental library for a DE could be a huge mistake, no matter how promising the roadmap is. Ideally you'd wait for the project to ship some of the non-negotiable things on the roadmap (accessibility, system menus, RTL text, keyboard navigation...) before tying your fortunes to it.
I think native context menus are out of scope for iced and probably to be addressed upstream by winit. patches welcome.
at the risk of sounding like a fanboy, I encourage you to try to use iced as a library first to see how powerful it is in terms of performance, ergonomics and overall just the quality of its design. hecrj is a prolific coder and I'm confident I'm not alone in this assessment. I'm pretty bullish on the path ahead for the library given those fundamentals, and I can't speak for the COSMIC team but I imagine that assessment probably overlaps with theirs.
I mean text editing context menus (right-click a text field -> Undo, Redo, Cut, Copy, Paste). Iced, or at least Halloy, doesn't have those at all.
You can definitely implement all of that in iced. The `text_editor` widget offers cut, copy, paste off-the-shelf and undo/redo would be a matter of keeping a stack of the "input changed" messages and popping off changes to undo/redo them.
The library is pretty low level so there's a bit of legwork that the developer needs to do in order to implement things that you get for free in, say, a browser. It's a tradeoff, but I think one that tends to provide more advantages than disadvantages.
Based on [1] it looks like System76 does actually think about accessibility, but it's not upstreamed yet.
[1]: https://github.com/iced-rs/iced/issues/552#issuecomment-2180...
That's encouraging!
Discord chat, Expat licence, GitHub repository... perhaps we also need a good UI library that manifests a greater desire to cultivate user rights. I'd say that's just as important as technological advancement, if not more.
sad reality when such HN comments get downvoted
I think this is a very shallow take. I'm a GPL proponent and have worked on/released GPLed software for a good 20 years, now, and I think it's distasteful to judge how people choose to license the work that they do for free, and effectively "donate" to society.
I do wish more things were covered under licenses with strong "copyleft", but I don't begrudge anyone the ability to license their hard work however they please.
Why should that be distasteful?
Google gives us Chrome for free. Does that make it distasteful to question their decisions around using our data because they’ve made it free?
Individuals donating their time and effort to the public, whether that excludes for-profit use or not, is better than them not doing it.
At least I think that's what the person you replied to is trying to get at.
Can we stop with these drive-by comments on every project that uses a permissive open source license? You are certainly welcome to create your own UI framework under the GPL if you want. The contributors have chosen MIT and that is a perfectly valid decision.
Why should the choice of licence not be a fair concern to express in the comments? I'm not questioning the validity of the authors' decision per se, but the considerations and priorities behind it, and whether they ought to be different for a project of this type. I don't see how this side is less important or interesting to consider than the technical one (on which comments seem quite commonplace, and rightly so, in my view).
If my actual opinion interests you, I might lean towards the LGPL, rather than the GPL. I find both of them more beneficial than any of the MIT licences for a UI framework, but strong copyleft might do more to hamper widespread adoption and interest in the project, which seem an important factor as well.
It's a valid concern, but consider that some persons put a lot of effort into making open source software and then share it to be nice, or for the public good.
So to people chime in and complain that it's not good enough can seem obnoxious and/or ungrateful.
Are their discord channels indexed by search engines?
What "user rights"? Free software is a gift, not a right.
Free Software is the idea that users should have a right to the code of the products they purchase.
Only for free as in freedom, not as in beer.
Great idea, let us know when you release!
In the time it takes to downvote this comment, you could duplicate the repository on your preferred hosting service and change the license! Be the change you wish to see in the world!
It seems super productive as well. Modern Rust is ergonomic. Take a look at some of the community PRs being merged in to Cosmic and you can see how good a developer experience it is. Compared to c/c++/qt/gtk it is a breath of fresh air.
Iced is also super themeable which is a really nice change compared to GTK. Check out https://cosmic-themes.org as an example!
What exactly does it do better for them ability than GTK? It’s been a while since I’ve used desktop Linux, but there were lots of GTK themes back then. https://www.gnome-look.org/browse?cat=135&ord=latest suggests there are plenty now.
Is it more capable? Easier to create? I don’t think it’s obvious just from the theme store.
I suppose I misspoke a little. GTK has a stylesheet that can be modified. In fact the Cosmic appearance settings has an option to apply the current Iced theme to GTK apps.
Gnome does not expose this at all (except for the built in dark mode) and they actively discourage any kind of theming. Gnome 47 will finally support accent colors, which they reluctantly implemented after it became a freedesktop standard and most distros were patching it in anyway.
If you theme apps without testing there is always the change that you break apps with complex or custom widgets. It is kind of sad seeing your app looking and behaving like crap due to some random them that the distro apply to all GTK-based apps without doing any testing or validation.
Which is why the approach iced/libcosmic is taking is great. It's mostly just changing colors and some border radius. As a user, I can make my GUI match my text editor/terminal and I'm happy. It's not like the old days of GTK2.x with pixbuf themes making everything crazy (although that was fun). After all this is desktop linux, people tend to gravitate to it because they want to be able to tweak things.
I mean even OSX has had accent colors for years, ffs.
It's not clear to me what are the real benefits though.
This can still break apps though, as it's impossible to test all possible color themes to see if the app has enough contrast with all of them.
This is what I particularly don't get though. Compared to GTK this seems to be more limited. Granted, GTK does not officially support custom style sheets and lately they have become harder to set, but the option is there and people have been making themes that completly change how some widgets look like. All of that seems fundamentally impossible here.
There is a xdg portal to set accent colors (from a limited testable set of colors) since some months. I wonder if libcosmic supports that or if you're forced to manually set a theme.
You can still do whatever you want in ~/.config/gtk-4.0/gtk.css, including importing other stylesheets. This also works for libadwaita apps. What the Gnome devs and the https://stopthemingmy.app/ people don't want is for Ubuntu or Manjaro to ship a themed/patched stylesheet in the system that breaks their apps, and they have gotten their way.
Isn't that what you can do in Gnome/GTK4/Adwaita as well?
KDE and KFrameworks already provides such an ability. Either way, great to see more options!
To me, this is a big argument as to why devs should be making heavy use of parameterized values their UIs, as opposed to hardcoding things. An app making as much use of parameterized values as possible will not only remain decent looking and usable under most themes (except for themes that are badly built — nothing can help there), but also play much more nicely with accessibility settings like font size, font weight, colorblindness modes, etc.
I will caveat this by saying I haven’t worked with GTK and don’t know how well-tooled it is in this regard. If GTK doesn’t offer any/many parameterized values, then that’s on GTK, not app devs. They’re pretty well supported in macOS/AppKit, iOS/UIKit, and Android/Compose though and should be a cornerstone of any modern UI framework.
That’s not a silver bullet.
You can have a logo for your app that is coloured green. Then the user is using an all-green theme that happens to match the shade of your image and the logo is basically invisible.
That’s just easiest counter-example I could come up with.
Totally true that it's not possible to catch all edge cases, but I don't think it's a strong enough reason to rule out user theming/customization altogether, plus as mentioned parameterization should be done anyway for good accessibility.
GTK, frankly, has been going downhill when it comes to customization (including, but not limited to, themeing) for at least a decade now. Many GTK themes out there today do not support GTK4 (the page you linked to is confusing; even though it's the "GTK3/4 Themes" category, many don't support GTK4).
GTK has more and more become a stripped-down toolkit that requires you to write or use a "platform library" (like libadwaita) in order to do useful things. Judging by the deprecations in GTK4, as well as statements from GTK developers, GTK5 will be even more stripped-down. This just makes it harder for non-GNOME projects to use it.
On top of that, each major GTK release comes with drastic changes to how classes of widgets work, which for smaller teams could mean years of work to migrate to the new version. I don't begrudge the GTK developers their ability to make all of these sorts of changes; after all, I'm not paying them for any kind of support or feature set. But it's still frustrating for smaller teams that don't realistically have the ability to take on the maintenance burden of an entire UI toolkit.
I am building an app [0] with GPUI. I think it’s very ergonomic, but it’s missing so much stuff that you would expect in a GUI library. There isn’t even a text input element. I would be lying if I wasn’t thinking about jumping off.
I gotta say, Iced doesn’t appear to scratch the same itch though. The only one that comes close to what I want is Vizia [1].
[0] https://github.com/MatthiasGrandl/loungy [1] https://github.com/vizia/vizia
Looks like TextInput was just added in the last week: https://github.com/iced-rs/iced/blob/master/widget/src/text_...
I was talking about GPUI. In comparison Iced is way more mature.
iced has had TextInput for 5 years now. https://github.com/iced-rs/iced/commit/63cd0fd8eb1eebae8de7d...
Mind going into a bit more depth on "scratch that itch"? I've been debating Iced vs GPUI, would love any deeper thoughts you have on the subject. Performance and UX are probably my largest concerns, fwiw.
Loungy and Helix-gpui were my inspirations to look into GPUI, so i'd love your thoughts :)
My biggest reason for wanting to switch away from GPUI is because there is barely any momentum in making it a general purpose framework. Zed team is mostly just focusing on Zed usecase and the end user is left implementing basic functionality themselves.
On top of that you are stuck with their async runtime of choice (smol), while Iced supports both tokio and smol. This is annoying when you have some tokio dependencies, of which there are a lot.
I played around with Iced a bit now. I like it a lot. The only issues that keep me from porting are:
1. I can’t replicate the GPUI popup window with winit. I am currently trying to patch winit to make it possible, but am a bit lost. 2. I do like the tailwind like syntax for styling components in GPUI a lot. It just fits my mental model a lot better than Iced.
That said I think Iced is the cleaner framework of the two and if you are designing a traditional windowed application, I would recommend it in a heartbeat.
I spent months mulling over whether to go with iced, Dioxus, Tauri, Flutter, Yew, Slint, Egui, Relm4, Ribir, even ratatui.... and probably more I'm forgetting
iced wins by a landslide.
it's just hard to learn at first but mostly because you start "not thinking with portals" and struggle. 9 out of 10 times I was just holding it wrong when I struggled.
Did you review GPUI at all?
I'm also having this debate. Performance, stability and longevity are my biggest concerns. GPUI seems so focused on Performance that it's really attractive, but it's also a UI lib second to the App that it's written for, Zed. So i'm a bit flummoxed on if it's worth investing time and effort into.
Iced is my comparison, just not sure how the performance can compare to GPUI.
I did not try GPUI but iced's performance is so blazing fast I doubt it will be an issue for you.
For Cosmic there is 'libcosmic' its a wrapper around iced that adds a bunch of useful stuff.
I've been enjoying Slint[0] lately. It is inspired by QML but is entirely implemented in Rust. From what I understand, it also transpiles the .slint files into Rust.
[0]: https://slint.dev