[VanTodi]

So it's the vision of a single person and another UI library is being born. I'm being sceptical at this, cause it looks like the same problem with JS and all the frameworks: I can't find anything that has all the features I want, so I start a new one, which potentially never becomes stable. I'm not a Rust developer (yet) and have a background in PHP and JS, so I'm glad if some vets can elaborate on the GUI problem with other programming languages.

[CGamesPlay]

I've recently been having some success with a fail-fast version of this. Quick example: I wanted a utility component library for React, and none of the ones I looked at seemed promising. So I built my own, focusing exclusively on the consumer API and seeing what was possible. I pretty quickly ruled that my dream API wasn't possible, but I figured out why and what trade offs were going into it. Then I want back to the available libraries with a much better understanding of the underlying problems, and identified one that most closely resembled what I thought was precisely what I wanted. This approach has worked for several of the dependencies I've adopted lately and I have found that I now spend a lot less time fighting with my dependencies because I'm trying to pigeonhole them into a place where they can't fit.

[ebiester]

I think what's interesting here is that the author is trying to build a foundational component upon which other developers can leverage. The author is trying to build something that other GUIs will want to integrate (e.g. Druid and Xilem).

And I think it's fair for someone to put together a proof of concept as a research proposal. They may not make it far in and of itself, but it may become an inspiration for someone else.

[PoignardAzur]

I think there's good hope for that approach too.

GUI crate maintainers have expressed interest in AccessKit; so far three crates have started using it (egui, rui, iced in a PR).

This suggests to me that these maintainers are interested in the idea of pooling work and that they're willing to use other people's work instead of NIH-ing their own library. (Though that doesn't mean Masonry is what anybody will settle on.)

[PoignardAzur]

> I can't find anything that has all the features I want, so I start a new one, which potentially never becomes stable

The "potentially never stable" part is fair to worry about, but I disagree with the "start a new one" part.

While I do want to work on another UI library (Panoramix), this isn't what this post announces. The goal of Masonry is to promote code reuse. In my ideal scenarios, other libraries such as Xilem, Iced, SlintUI, etc... might come to rely on Masonry as their backend.

In fact, the "xkcd 927" problem is why I started Masonry in the first place: because I saw there were a lot of Rust GUI frameworks, but there was no crate that gave you a base to build a GUI framework from.

[VanTodi]

I really hope you succeed. Sounds like it's a missing part of the eco system and your plan and thought sounds great to me.

[darthrupert]

This happens on every moderately successful language platform. The difference is that mentioning Rust makes this front-page material somehow.

[mlindner]

Rust doesn't have a good GUI story yet. It makes it to the front-page because people are looking for a good one.

https://www.areweguiyet.com/