8 ms·

A declarative desktop UI framework for Rust built on GTK and GTK-rs

119 points by tempodox 4y ago

homarp 4y ago
https://github.com/bodil/vgtk/issues/79 https://github.com/bodil/vgtk/issues/79 about the project being active or dead had no response so far.
- phtrivier 4y ago
  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 4y ago
    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 4y ago
      You’ve seen enough cases of what? People saying that it’s too hard to contribute?
      - ducktective 4y ago
        No, cool projects in Github that are written in Rust but abandoned after some time.
        pengaru 4y ago
        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 4y ago
        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.
        avgcorrection 4y ago
        Seems that you’ve skipped a bunch of steps in order to come up with your pet theory, then. 1. Rust projects become abandoned (observed fact) 2. Language complexity (?) 3. Hard to contribute (?) I guess that’s why you were kind of defensive when you brought it up.
    - Lapz 4y ago
      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 https://github.com/antoyo/relm which is an active project.
    - zorr 4y ago
      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.
    - Macha 4y ago
      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 4y ago
        "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.
        pdimitar 4y ago
        What makes you think it will flame out?
        Macha 4y ago
        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 4y ago
        And C#, C++, C.
        ntoskrnl 4y ago
        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 4y ago
        > 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.
    - jjtheblunt 4y ago
      typo : tenancy -> tendency
    - Taywee 4y ago
      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.
    - nicoburns 4y ago
      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.
    - rvz 4y ago
      Depends on the use case. If it is a GUI library project then yes.
    - pornel 4y ago
      Quite the opposite in this case: https://twitter.com/bodil/status/1520404060138094592 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).
- sph 4y ago
  404 now.
  - vladvasiliu 4y ago
    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 4y ago
      It was removed literally today, according to archive.org: https://web.archive.org/web/20220528105757/https://github.com/bodil/vgtk/issues/79 https://web.archive.org/web/20220528105757/https://github.co...
zorr 4y ago
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.
formerly_proven 4y ago
The 90s called and want their WndProc back.
- sph 4y ago
  If it's old it doesn't mean it's bad. The message loop model for GUIs is/was great.
  - silon42 4y ago
    More or less. I'm thinking that a single-thread for UI model could fit well for Rust.
  - formerly_proven 4y ago
    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 4y ago
  [deleted]
overlisted 4y ago
Does anyone actually enjoy using the Elm paradigm? I personally can't stand the amount of boilerplate and "indirect thinking" that it requires.
- jokethrowaway 4y ago
  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 4y ago
  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 4y ago
  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 4y ago
    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.
- andsoitis 4y ago
  > Does anyone actually enjoy using the Elm paradigm? Reading "Elm architecture" (https://guide.elm-lang.org/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 4y ago
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 4y ago
  Licensing I suppose.
jallasprit 4y ago
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 4y ago
A more maintained alternative: https://github.com/Relm4/Relm4 https://github.com/Relm4/Relm4
- phkahler 4y ago
  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 4y ago
    Apache or MIT "if" you make the choice. But yeah, that is kind of strange to do it that way.
  - mixedCase 4y ago
    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 4y ago
    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-licensing/8952/2 https://internals.rust-lang.org/t/rationale-of-apache-dual-l...
    - phkahler 4y ago
      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 4y ago
  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 https://www.cmyr.net/blog/rust-gui-infra.html#accessibility
dceddia 4y ago
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 https://tauri.studio 1: https://getrecut.com https://getrecut.com
- aorth 4y ago
  I've been watching Tauri for a while. Are there any apps we can try out yet? Thanks.
  - dceddia 4y ago
    I see there are a few apps listed here, mostly open source: https://github.com/tauri-apps/awesome-tauri https://github.com/tauri-apps/awesome-tauri
inamberclad 4y ago
How is this different from Relm?
craig0990 4y ago
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 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.
varajelle 4y ago
Another declarative UI framework written in rust: https://github.com/slint-ui/slint https://github.com/slint-ui/slint
- yencabulator 4y ago
  GNU GPLv3 or commercial license isn't very usable :-(

119 points by tempodox 4y ago

https://github.com/bodil/vgtk/issues/79 https://github.com/bodil/vgtk/issues/79 about the project being active or dead had no response so far.

phtrivier 4y ago
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 4y ago
  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 4y ago
    You’ve seen enough cases of what? People saying that it’s too hard to contribute?
    - ducktective 4y ago
      No, cool projects in Github that are written in Rust but abandoned after some time.
      - pengaru 4y ago
        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 4y ago
        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.
      - avgcorrection 4y ago
        Seems that you’ve skipped a bunch of steps in order to come up with your pet theory, then. 1. Rust projects become abandoned (observed fact) 2. Language complexity (?) 3. Hard to contribute (?) I guess that’s why you were kind of defensive when you brought it up.
  - Lapz 4y ago
    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 https://github.com/antoyo/relm which is an active project.
  - zorr 4y ago
    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.
  - Macha 4y ago
    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 4y ago
      "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.
      - pdimitar 4y ago
        What makes you think it will flame out?
      - Macha 4y ago
        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 4y ago
        And C#, C++, C.
      - ntoskrnl 4y ago
        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 4y ago
        > 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.
  - jjtheblunt 4y ago
    typo : tenancy -> tendency
  - Taywee 4y ago
    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.
  - nicoburns 4y ago
    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.
  - rvz 4y ago
    Depends on the use case. If it is a GUI library project then yes.
  - pornel 4y ago
    Quite the opposite in this case: https://twitter.com/bodil/status/1520404060138094592 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).
sph 4y ago
404 now.
- vladvasiliu 4y ago
  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 4y ago
    It was removed literally today, according to archive.org: https://web.archive.org/web/20220528105757/https://github.com/bodil/vgtk/issues/79 https://web.archive.org/web/20220528105757/https://github.co...

zorr 4y ago

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.

formerly_proven 4y ago

The 90s called and want their WndProc back.

sph 4y ago
If it's old it doesn't mean it's bad. The message loop model for GUIs is/was great.
- silon42 4y ago
  More or less. I'm thinking that a single-thread for UI model could fit well for Rust.
- formerly_proven 4y ago
  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 4y ago
[deleted]

overlisted 4y ago

Does anyone actually enjoy using the Elm paradigm? I personally can't stand the amount of boilerplate and "indirect thinking" that it requires.

jokethrowaway 4y ago
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 4y ago
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 4y ago
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 4y ago
  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.
andsoitis 4y ago
> Does anyone actually enjoy using the Elm paradigm? Reading "Elm architecture" (https://guide.elm-lang.org/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 4y ago

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 4y ago
Licensing I suppose.

jallasprit 4y ago

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 4y ago

A more maintained alternative: https://github.com/Relm4/Relm4 https://github.com/Relm4/Relm4

phkahler 4y ago
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 4y ago
  Apache or MIT "if" you make the choice. But yeah, that is kind of strange to do it that way.
- mixedCase 4y ago
  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 4y ago
  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-licensing/8952/2 https://internals.rust-lang.org/t/rationale-of-apache-dual-l...
  - phkahler 4y ago
    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 4y ago
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 https://www.cmyr.net/blog/rust-gui-infra.html#accessibility

dceddia 4y ago

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 https://tauri.studio 1: https://getrecut.com https://getrecut.com

aorth 4y ago
I've been watching Tauri for a while. Are there any apps we can try out yet? Thanks.
- dceddia 4y ago
  I see there are a few apps listed here, mostly open source: https://github.com/tauri-apps/awesome-tauri https://github.com/tauri-apps/awesome-tauri

inamberclad 4y ago

How is this different from Relm?

craig0990 4y ago

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 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.

varajelle 4y ago

Another declarative UI framework written in rust: https://github.com/slint-ui/slint https://github.com/slint-ui/slint

yencabulator 4y ago
GNU GPLv3 or commercial license isn't very usable :-(