[HN Gopher] A declarative desktop UI framework for Rust built on...
___________________________________________________________________
A declarative desktop UI framework for Rust built on GTK and GTK-rs
Author : tempodox
Score : 105 points
Date : 2022-05-28 09:06 UTC (13 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| varajelle wrote:
| Another declarative UI framework written in rust:
| https://github.com/slint-ui/slint
| craig0990 wrote:
| I'm always curious to see these projects, because I've been
| experimenting with a React renderer for the GJS bindings for a
| while. It's frustrating because GTK "feels like" it's so close to
| being able to support a vdom/declarative paradigm, but the devil
| is in the details.
|
| The simple use-cases like "Window > Box > Label" are easy to get
| going. The more complex widgets like Stack/Grid/TreeView ...
| aren't.
|
| This project seems to have the same issue:
| https://github.com/bodil/vgtk/issues/40
|
| This is made more difficult now GTK4 has removed the Container
| base class, so there's no longer a unified interface for adding
| children (although it had caveats in the first place).
|
| I totally get the GTK view that (presumably) specific widgets are
| more intuitive with specific add/remove APIs (like the grid - one
| doesn't really "appendChild" to a grid).
|
| It just feels like: if there was a consistent container API
| comparable to the web's appendChild approach, a vdom/declarative
| approach would require only a very light wrapper. Without it, I
| keep coming back to the idea of implementing wrapper widgets that
| expose that consistent API instead. And that's just not something
| I want to maintain - effectively duplicating each GTK widget for
| the purpose of making it fit into a tree model.
|
| It's also a problem of trying to wrap richer functionality
| (pack_start and pack_end) into a simpler set (append only) of
| course.
|
| So I don't know exactly what my point is :) Perhaps cautioning
| the reader that the simplicity of the approach comes with a
| catch.
| inamberclad wrote:
| How is this different from Relm?
| zorr wrote:
| This approach sounds interesting and I think something like this
| is what we should focus on to bring UI frameworks to new
| programming languages (in the short term).
|
| Let's not throw out all the work that went into Gtk/Qt but
| instead embrace it. Bindings/wrappers that are idiomatic in the
| target language. Maybe including a small state or declarative
| layer and lean on the framework for rendering, input events,
| windowing, accessibility, etc.
|
| Another example of this approach is TornadoFX which is a
| declarative Kotlin DSL on top of JavaFX.
| jokethrowaway wrote:
| Nice to have more options but I don't see a compelling reason to
| use gtk over qt.
|
| The api is just better and gives you more for the bang
| ericbarrett wrote:
| Licensing I suppose.
| dceddia wrote:
| I've been enjoying using Tauri [0] to develop a desktop app for
| the last few months. As someone who's been a web dev, and a
| C++/Qt dev before that, I think it strikes a nice balance. I can
| use my web skills on the UI, and do the heavy lifting in Rust,
| and it's all very fast.
|
| I'm building a video editor [1] (actually rebuilding an app that
| was originally in Swift) and I've been happy to see that the
| performance is great. I think it feels faster than some of the
| Qt-based editors I've tried. I haven't noticed JS being the
| bottleneck - way more often it's been that I'm doing something
| sub-optimal on the Rust side.
|
| Tauri still feels early in some aspects, but it's moving quickly
| and they're buttoning things up. I think it's already a strong
| contender in the space currently (mostly) owned by Electron.
|
| 0: https://tauri.studio
|
| 1: https://getrecut.com
| aorth wrote:
| I've been watching Tauri for a while. Are there any apps we can
| try out yet? Thanks.
| dceddia wrote:
| I see there are a few apps listed here, mostly open source:
| https://github.com/tauri-apps/awesome-tauri
| jallasprit wrote:
| Does this support different types of message enums so you can
| keep the enums relatively small based on context? With iced that
| has the exact same pattern, I find that I end up with an enormous
| message enum with very long keys
| mixedCase wrote:
| A more maintained alternative: https://github.com/Relm4/Relm4
| phkahler wrote:
| Why is it licensed under Apache and MIT? The underlying GTK is
| LGPL, so this is just creating extra licenses in a users
| project for no good reason.
| sigzero wrote:
| Apache or MIT "if" you make the choice. But yeah, that is
| kind of strange to do it that way.
| mixedCase wrote:
| Because the author preferred to share their code under that
| license is the only reason you actually need.
|
| Additionally, there's an added benefit if you're building
| non-(L)GPL software with it: you can just use the compiler
| defaults (statically link Relm4, dynamically link Gtk) and
| stay compliant.
| bluejekyll wrote:
| For those unfamiliar with Rust, the Rust language and a lot
| of the foundational ecosystem are dual-licensed with MIT and
| Apache. For any Rust project, this is not a surprising
| default for the licensing choice.
|
| Here's a good discussion on it: https://internals.rust-
| lang.org/t/rationale-of-apache-dual-l...
| phkahler wrote:
| This makes the most sense of all the answers. Either
| matching the GTK license, or the common Rust app licenses
| is reasonable. I think I would have gone the other way, but
| that's just me.
| skyfaller wrote:
| Do you happen to know if Relm addresses accessibility at all,
| or has plans to do so in the future? Every time I see a Rust
| GUI post, that's my first question:
| https://www.cmyr.net/blog/rust-gui-infra.html#accessibility
| mixedCase wrote:
| It's a rather light wrapper around gtk-rs, so if gtk-rs
| covers it, it should be there.
| homarp wrote:
| https://github.com/bodil/vgtk/issues/79 about the project being
| active or dead had no response so far.
| sph wrote:
| 404 now.
| vladvasiliu wrote:
| That's... interesting. I clicked the link earlier today I can
| confirm someone was asking whether the project was still
| maintained, with no answer. Can't say it inspires confidence
| to see the issue removed...
| nyanpasu64 wrote:
| It was removed literally today, according to archive.org: h
| ttps://web.archive.org/web/20220528105757/https://github.co
| ...
| phtrivier wrote:
| Given that the project had exactly one commit in the past year,
| I'm afraid the question is answered...
|
| (Which is too bad, the ideas behind the project seem sound.)
| ducktective wrote:
| A totally unscientific observation:
|
| Do Rust projects have a tenancy of becoming abandoned maybe
| due to the complexity of the language since it's hard to
| contribute? I've seen enough cases on this that prompted me
| to ask this.
| avgcorrection wrote:
| You've seen enough cases of what? People saying that it's
| too hard to contribute?
| ducktective wrote:
| No, cool projects in Github that are written in Rust but
| abandoned after some time.
| pengaru wrote:
| Can't this be explained simply by rust being a new and
| trendy language with a lot of young developers
| experimenting while they improve their skills?
| wtetzner wrote:
| There are tons of those in every language. You just see a
| lot them in Rust because people are excited to submit
| Rust projects to HN.
| pornel wrote:
| Quite the opposite in this case:
|
| https://twitter.com/bodil/status/1520404060138094592
|
| The author of this crate enjoys advanced type systems, and
| can't wait for Rust to add what you'd call "more
| complexity" in the form of higher-kinded types, generic
| associated types, and specialization (some of these
| features are available in an unfinished/experimental form
| in the nightly compiler, but may not become part of the
| language anytime soon, if ever).
| Lapz wrote:
| No , not really a lot of the time people are trying to
| tackle problems that have taken years to solve in other
| languages which isn't easy and is why you see stuff
| abandoned. This project is also pretty similar to
| https://github.com/antoyo/relm which is an active project.
| Taywee wrote:
| In my personal experience, I make and abandon a ton of Rust
| projects because it's such a fun language, and I really
| enjoy starting new projects in it. I get an idea, get
| excited about how I can model the types and relationships
| in Rust, then throw together an early prototype, then drop
| it when I've had my fun and before it turns into a job.
|
| Other languages don't have as fun a type system, so I feel
| bogged down and lose motivation before I even start writing
| code.
|
| I don't know how many others this applies to, but I have a
| lot of abandoned Rust projects because if it wasn't in
| Rust, I never would have even started writing them down
| before abandoning them.
| Macha wrote:
| I think we're just early enough in the language that the
| established libraries and their mechanisms for ensuring
| continuity just aren't there in many areas.
|
| Other languages had similar teething problems, just ask
| anyone with applications in Zope, WebPy, Pylons, Merb, JS
| frameworks not named React, EJB, MFC, etc.
| neverminder wrote:
| "early enough in the language" is really worrying at this
| point. I was there, at Mozilla London office in 2015 15th
| of May when Rust 1.0 was launched. That was 7 years ago.
| If you look at the history of languages, 7 years is a
| point of maturity for those that took off. I really hope
| Rust doesn't flame out like Scala did.
| solar-ice wrote:
| IMO, we're very much past the point at which things have
| "settled down"... as long as you're not doing web dev or
| desktop UI dev in Rust. The former will continue to
| evolve about as fast as JS-land does because it's all web
| people who have no idea what a sustainable project is,
| and the latter will take a few more years because nobody
| has really solved it in any language. (Ask your favourite
| "cross-platform" desktop UI framework what their
| accessibility story is; there is one that gets close,
| it's Qt.)
|
| But like, if you're trying to do something you'd
| otherwise do in C++? Audio/video processing, or something
| along those lines? Yeah, it's fine. The common libraries
| you choose today are likely to be maintained going into
| the future.
| pdimitar wrote:
| What makes you think it will flame out?
| Macha wrote:
| Again though, EJB, AngularJS, Backbone, Pylons were all
| things in languages that were widely accepted at the
| times those frameworks were in vogue yet still ran out of
| steam. Yet Java, JavaScript and Python are still here
| DeathArrow wrote:
| And C#, C++, C.
| ntoskrnl wrote:
| For comparison, Python 1.0 was released in 1994. 7 years
| later in 2001, Python 2.2 was released. I don't think
| many of today's popular Python packages date back that
| far.
| lelanthran wrote:
| > For comparison, Python 1.0 was released in 1994. 7
| years later in 2001, Python 2.2 was released. I don't
| think many of today's popular Python packages date back
| that far.
|
| Python is an outlier though; it was mostly ignored until
| very suddenly it took off starting around the time
| Jupyter released.
|
| Most (including I) think it took off due to how easy and
| accessible it was back then, syntax-wise. You could pick
| it up and be slightly productive in a day, be extremely
| productive in a week and essentially master it in a
| month.
|
| Go is following a similar trajectory: productive
| contributor in a week, master in a month.
|
| Rust is in the opposite direction: too many people simply
| give up on it, those that persevere report months before
| any reasonable productivity.
| Macha wrote:
| Before it's adoption with the scientific community,
| Python still had a place as "Better perl for scripting"
| and "Dynamic language for webapps if you don't like
| Ruby". e.g. Reddit, YouTube and Eve Online are notable
| apps written in Python before scientific Python was a
| thing.
|
| Reddit and Eve are interesting in being largely stuck
| with the now-dead platforms they built on too, in the
| form of web.py and Stackless Python. YouTube I presume
| the original Python application is gone in favour of a
| bunch of Go and Java microservices by now.
|
| It's interesting as someone who was in the Python for web
| development camp as Python for scientific computing took
| off as the two camps were both oblivious to the existence
| of the other in many cases.
| jsjohnst wrote:
| This is some extreme revisionist history here. The
| scientific Python community and many of the libraries
| around it go back way before Reddit, YouTube, etc.
| DeathArrow wrote:
| >"Dynamic language for webapps if you don't like Ruby"
|
| Wasn't PHP the king of dynamic laguages for Web?
| zorr wrote:
| Instead of language complexity I think it's a result of the
| specific positioning of the Rust language as a more safe
| successor to C/C++.
|
| Rewrite-in-Rust is a thing. Not only for applications but
| also for foundational libraries (crypto, http, async, etc).
| The ecosystem is still young with lots of gaps and many
| devs are experimenting with new approaches to fill those
| gaps. More new projects -> more abandoned projects.
| nicoburns wrote:
| I don't think Rust projects get abandoned any more than
| projects in other languages. I think it's just that you see
| them more because people are excited about Rust so they
| share projects even if they're abandoned.
| jjtheblunt wrote:
| typo : tenancy -> tendency
| rvz wrote:
| Depends on the use case. If it is a GUI library project
| then yes.
| formerly_proven wrote:
| The 90s called and want their WndProc back.
| sph wrote:
| If it's old it doesn't mean it's bad. The message loop model
| for GUIs is/was great.
| silon42 wrote:
| More or less. I'm thinking that a single-thread for UI model
| could fit well for Rust.
| formerly_proven wrote:
| Desktop GUIs by necessity always use a message loop under the
| hood. WndProc certainly worked and you could build GUIs with
| it (same for using CreateWindow, implementing resizing on
| foot in WM_SIZE and using resource files for dialogs - also
| subclassing for making those fancy progress bars). But it's
| also verbose and at the end of the day you have a giant
| function handling dozens of messages and passing messages
| back and forth with other wndprocs. If we want to stay on the
| message level, both the signal/slot paradigm and/or using
| coroutines are just better, especially the latter is a very
| natural fit for UIs.
| [deleted]
| overlisted wrote:
| Does anyone actually enjoy using the Elm paradigm? I personally
| can't stand the amount of boilerplate and "indirect thinking"
| that it requires.
| andsoitis wrote:
| > Does anyone actually enjoy using the Elm paradigm?
|
| Reading "Elm architecture" (https://guide.elm-
| lang.org/architecture/) it looks like classic MVC - they just
| call it Model / View / Update instead of Model / View /
| Controller.
|
| If not, the rest of my comment is invalid.
|
| > I personally can't stand the amount of boilerplate and
| "indirect thinking" that it requires.
|
| Of course, just because you use a classic paradigm it doesn't
| mean the implementation thereof is elegant. And that might be
| because according to the Elm docs programmers "stumbled" upon
| it (reinvent) instead of designing for it: "Rather than someone
| inventing it, early Elm programmers kept discovering the same
| basic patterns in their code."
| jokethrowaway wrote:
| It's nice in elm
|
| It's horrible in JS because of the boilerplate
|
| It's ok in rust, at least you have types
| danpalmer wrote:
| Yes. I honestly find it much easier to think about, easier to
| design, and eventually easier to modify and maintain.
|
| It feels like a lot of code needs to be written, but in my
| experience that's because it necessitates thinking about the
| edge cases in a way that you can try to ignore with more
| imperative UI or data flow.
|
| I've used the Elm paradigm in Elm and in Swift on iOS. Would
| definitely use it again for any data-driven complex UIs like
| apps or big web frontends.
| tazjin wrote:
| Yeah, it's nice. I don't know what it would be like in a
| language with a weak/no type system (e.g. JS) though, probably
| annoying.
| chrisco255 wrote:
| Redux is basically that. Lack of types can be slightly
| annoying, but controlling your state changes through explicit
| events tends to prevent a lot of ails.
___________________________________________________________________
(page generated 2022-05-28 23:01 UTC)