Hacker News Reader

Comment by rafram | Hacker News Reader

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

View on HN

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

    iced is a cross-platform GUI library focused on
    simplicity and type-safety. Inspired by Elm.
    
    Disclaimer
    ––––––––––
    iced is experimental software

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!

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.

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.

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.

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.

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.

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?

Then the can just use Gnome ...

Reply on news.ycombinator.com