9 ms·

Show HN: Sauron-native – A native cross-platform GUI for Rust

255 points by ivanceras 7y ago

ivanceras 7y ago
Hi HN, This is a work-in-progress project inspired by this HN comment[0]. [0]: HN comment -(https://news.ycombinator.com/item?id=19746440 https://news.ycombinator.com/item?id=19746440)
- phtrivier 7y ago
  Referenced commentator here: I'm totaly new to Rust, but I'll definitely check it out !
- jacobush 7y ago
  Which ones of the sub-debates did you focus on solving?
  - ivanceras 7y ago
    The holy grail part.
    - nixpulvis 7y ago
      Too bad you still need to pay $$$ to get on to the App Store.
    - Dowwie 7y ago
      That's the spirit! :)
- Razengan 7y ago
  In that linked comment: > 2.1) I want to ship something that looks the same on Windows / Linux / MacOS As a user: No no no, please, no. I want apps to fit the look, feel, and idioms of the OS I'm currently in, not "look the same" on every OS. For example. macOS in particular has many builtin features that work in all apps with standard controls. Like text-to-speech, or converting selected text into all-caps, lowercase, or capitalized. Or custom services/scripts built in Automator. I may not always use these little tricks all the time, but when they fail to work in some app, it immediately feels lower quality, suspicious, and/or suggests a lazy developer. It's not pleasant to use something that ignores the special features of a platform in favor of the lowest common denominator.
  - electrograv 7y ago
    Personally, I find that most modern UIs that explicitly do not conform to an OS’s opinionated UI design style (for example: the majority of web stack UIs[1]), are often better in almost every way vs apps that do conform to OS style! When I’m using an advanced UI to do some specialized task, I generally appreciate when the UI patterns I learn on one OS transfer seamlessly to any other device and OS I may use to do the same task. But I especially appreciate that apps can choose the UI style and design to suit the task at hand, rather than some notion of conforming to OS style patterns that may or may not work in its favor. For example, I prefer that Visual Studio Code looks the same on all platforms, because I find its UI to be superior to the default style of any OS! What do you think about these thoughts? Am I alone in preferring custom UIs per app, with consistent app experience across devices? [1] For the sake of this argument, I’m not counting differences in runtime performance and efficiency, since that’s a whole other topic, and one theoretically orthogonal to the UI design.
    - Razengan 7y ago
      > Am I alone in preferring custom UIs per app Custom UIs by themselves are not the culprit. Apple itself is "guilty" of that, using special controls and styles for their own apps (including even the new Reminders in Catalina.) But if an app on macOS puts a close button in the upper-right corner of a window or panel (like Windows does) instead of the upper-left, for example, or when an iOS app uses the Android sharing icon, I feel annoyed. A worse and more practical example is when an app is missing some of the global system features I described in my previous comment, like common text field options (spelling, transformations, dictionary lookup etc.) missing from an Electron-based chat app and so on.
    - ridiculous_fish 7y ago
      1. The reason for platform UI conventions is so users can transfer knowledge between apps. Some specialized apps may want to establish their own conventions, because they are aimed at experts who will be investing a lot of time in the app. Most apps aren't in that category. 2. HTML and JS make sucky UIs regardless of how much "work pools", because the underlying APIs are limited and incomplete. For example, scrolling: there is no native support for large tables in HTML, so apps either do some janky faulting in like infinite scroll, or reimplement scrolling entirely. Cut/copy/paste/undo is another example, along with keyboard navigation in general.
vbsteven 7y ago
Interesting project, I’ll be checking this out soon. I’ve been experimenting with several gui libraries in Rust lately and so far the GTK3 bindings seem to be the most promising for building native GUIs in Rust. With native I mean GTK/Qt style fast/performant widgets that do not necessarily use platform-specific widgets. This project seems to use GTK as one of its backends. I’m curious to see how the multiple backends architecture will influence the library design as GTK, html and TUI are vastly different.
- krapht 7y ago
  Could you say why you disliked the QT Rust bindings?
  - vbsteven 7y ago
    I have to spend some more time on it but due to lack of getting started documentation or examples it was hard to get a Hello World project running. On the GTK-rs side the documentation [1] is much better and I was up and running with a sample project in a few minutes. [1]: https://gtk-rs.org/ https://gtk-rs.org/
    - slezyr 7y ago
      Oh, wow. It looks horrible[1] in some cases. Even worse than most C++/Boost constructions. [1]: https://gtk-rs.org/docs-src/tutorial/upcast_downcast https://gtk-rs.org/docs-src/tutorial/upcast_downcast
      - nicoburns 7y ago
        Yeah, existing GUI libraries tend to make heavy use of inheritance, which Rust doesn't support very well. I have high hopes for a Rust-native GUI library being the goto cross-platform UI library at some point. But that's probably still 2-5 years off at this point.
  - ssokolow 7y ago
    While i'm not vbsteven, I can probably give a useful answer to your question. As a KDE user, QML is about as useful to me as GTK+ when it comes to feeling native, so bindings built around those APIs are out. rust-qt-binding-generator (the one maintained by KDE people) is fundamentally designed around the assumption that you're comfortable writing parts of your program in C++. (It's designed for embedding Rust pieces in a project with its own build automation, like CMake, and where hand-written C++ will still be used for part of the process of talking to Qt.) rust-qt comes the closest to what I want (something where, as long as I don't touch the `unsafe` keyword and I only pick trustworthy dependencies, I can't accidentally introduce memory-unsafety into my project.) but "Creating custom signals from Rust code." is still on the TODO list and its development seems to have run out of steam. So far, my solution has been to use Rust to write a cleanly encapsulated backend, use rust-cpython to expose it to Python, and then use PyQt5 (because I haven't started a new Qt project since PySide2 matured) to build a frontend, producing a QML-esque development experience for the QWidget APIs... though I'd still much rather have strong compile-time checks for the entire project.
rapsey 7y ago
These projects always stop (or make no useful progress) at the really difficult/tedious work of abstracting cocoa and win32 API.
- phtrivier 7y ago
  Isn't this abstraction already done (at least partly) by gtk ? (Or are you thinking of another level of abstraction - otherwise gtk would be enough ?)
  - rapsey 7y ago
    No gtk draws its own widgets.
  - rvz 7y ago
    When it comes to using only GTK+ for the cross-platform use-case, it already has the Cocoa and Win32 back-ends built in via the GDK, which that API is abstracted to GTK+ so that work is already done. It maybe enough to solve the Rust GUI problem on Win/Mac/Linux, however the drawback to using GTK+ is that it will look out of place on other platforms other than Linux, because of the GNOME _look and feel_ it brings. I think the author might have to support GTK+ theming options to counter this issue then? If not then perhaps using GTK+ for Linux and using the win32 and cocoa crates separately and abstracting that might be something worth looking at?
    - danieldk 7y ago
      however the drawback to using GTK+ is that it will look out of place on other platforms other than Linux, because of the GNOME _look and feel_ it brings. It is not worse than electron in that respect ;). But some small Rust Gtk+ utility that I have for personal uses a whopping 7564KB of resident anonymous memory.
      - jakevn 7y ago
        Personally, my issue with Electron is that, in practice, it is hugely inefficient. The up-side to Electron, IMO, is that it doesn't try to straddle the uncanny valley of native GUIs. In GTK, usually everything _looks_ like a normal GUI, but behaves/looks just a little (or, often times, a lot) bit different than what is expected.
PunksATawnyFill 7y ago
Can someone tell us what advantages Rust offers over other recent languages like Swift?
Multicomp 7y ago
This ui framework, if not abandoned by the tedium of win32 api integration, will make me sit up and actually try Rust for the first time. The TUI in particular looks great. 2020 was already slated for Rust for me but this may make me start dabbling in it a few months early (assuming I can find up to date leaning materials) Tldr great job, please don't give up on the hard part of win32 and macos but this has a great foundation feature set.
- ivanceras 7y ago
  The core architecture is not done yet. I put this out in the open in the hope it will get more contributions, since I will be working on to a next project. An enthusiast would certainly be able to play with it and maybe experiment with the core architecture.
  - rapsey 7y ago
    So you scratched your itch, now you are hoping someone else does the actual work.
    - ivanceras 7y ago
      Exactly, isn't that what opensource is meant for?
      - rapsey 7y ago
        I think most would disagree opensource being meant as a dumping ground.
        ivanceras 7y ago
        So, would you rather have me hoard this into my local workspace until forgotten? Or release it in the open since I will be working on a project that actually pays money. At least if somebody will be building something similar he/she can look up at this code and maybe make a derivative out of it.
alkonaut 7y ago
Good to see more alternatives in this space. If I can make one big app design request it would be this: Don’t assume that apps can always create their own windows. This has been a snag for winit and several others. Allow creating a GUI given an existing window handle. See e.g. https://github.com/rust-windowing/winit/issues/159 https://github.com/rust-windowing/winit/issues/159 If you create a rust ui framework that supports the VST windowing/event loop model and just supports one GUI backend on Win32/MacOS, then many people in the audio plugin community would be very happy.
deleted 7y ago
[deleted]
wokwokwok 7y ago
It runs on wasm in a browser; not really mobile support. ...and the author is abandoning it to move on to other things? /shrug Didn’t solve any of the actually hard problems of a cross platform or rust based UI imo.
- ivanceras 7y ago
  I'm not really abandoning it. It's just that I will be spending much less time than I used to, since I am accepting a full-time job to work on something that is not related to this project.
  - rco8786 7y ago
    Same thing, friend.
- api 7y ago
  I pimp this project any chance I get: https://github.com/andlabs/libui https://github.com/andlabs/libui We're considering using it for the next generation of the ZeroTier desktop UI. Unfortunately no mobile support (but we already have native mobile UIs), but it looks like the best contender for a cross platform UI lib that is light and fluffy and simple. Rust bindings should be trivial. There are high quality Go bindings here: https://github.com/andlabs/ui https://github.com/andlabs/ui
  - itronitron 7y ago
    >> a cross platform UI lib that is light and fluffy and simple Can you comment on whether you evaluated Java Swing or Java FX as a cross platform UI lib for your needs? I am curious to hear others thoughts on the matter.
    - auggierose 7y ago
      Definitely not light and fluffy ...
faitswulff 7y ago
For anyone else looking to get an overview of available GUI options in rust, there's https://areweguiyet.com/ https://areweguiyet.com/
- chrisweekly 7y ago
  Thanks! Great resource; bookmarked.
- raphlinus 7y ago
  One of those efforts is druid. I'm deliberately choosing not to make a lot of noise on social media yet, but I suggest people actively looking for native GUI in Rust take a closer look. Our team (currently two people funded full time, a GSoC student, plus a growing, dedicated community) is solving the hard problems, and we're on the hook for delivering a basic font editor by the end of the year. The webpage and demos don't look impressive yet, but this is because we're currently focusing on building out the core.
  - inferiorhuman 7y ago
    Druid and OrbTk have definitely caught my attention. The challenge for me is that while I have relatively simple needs for now (buttons, text, table widgets), I would like to do things not represented by the examples. With the (understandable) paucity of documentation it's difficult to be productive. My current challenge is to swap out different top-level views as I navigate to different parts of the app. This may may be something best suited to something like Cursive.rs, but I'm still holding out hope that the GUI toolkits will mature at a reasonable clip. It's really quite refreshing to see something more portable and lightweight than Electron gain traction. So far the only major detractor I've seen is that the project uses Zulip for chat/messaging and it's put behind a registration wall.
  - mrec 7y ago
    Is that 2+1GSoC team focussed purely on druid, or is it the xi team working on druid as part of that project?
nautilus12 7y ago
Since its a front end component and front end people are used to looking at gorgeous front ends and since you took the effort to make it functional (well done!) you should take the little bit of extra effort to also make it look pretty so it resonates with your audience. :). Rust is more a system language so you want to avoid that stigma from the outset.
whatshisface 7y ago
For Rust programmers that want to write GUIs, I highly recommend gtk-rs. It does not have the easiest-to-read documentation in the world but it is a good wrapper of gtk and it suffices for production use. Although it has not reached 1.0 yet, the changes to the API are slow and mostly happen in esoteric corners, so the development cost of keeping up is not noticeable. Further, since cargo has good versioning, it won't update and surprise you.
- ssokolow 7y ago
  In the GTK+ 2.x era, I would have agreed with you. GTK+ was either the basis for or easily themeable to feel reasonably native under any Linux desktop environment and, because of the applications which depend on it, pretty much everyone is likely to have it already installed. Unfortunately, in the GTK+ 3.x era and beyond, the perspective of many KDE users is that hell has frozen over because GTK+ has supplanted MacOS as the GUI with the most alien feel to it. (Plus, the LXDE developers started a transition to GTK+ 3.x, got fed up, and decided that their upgrade path from GTK+ 2.x would be Qt 5. They then merged with Razor-Qt to form LXQt.) Personally, what rubs me the wrong way the most is the various ways in which it explicitly goes against what HCI research recommends because the GNOME people just liked it better their way. (And I've read quotes by the devs showing that they now see GTK+ as GNOME's toolkit first and other desktops are on their own if they don't want to ride along... which explains things like how long it took them to stabilize the GTK+ 3.x theming APIs.) I still might consider it if the gtk3-mushrooms patchset for making GTK+ 3.x less alien weren't a single-person, amateur effort that's only packaged for Archlinux. (https://github.com/krumelmonster/gtk3-mushrooms https://github.com/krumelmonster/gtk3-mushrooms)
  - whatshisface 7y ago
    The advantage that Rust's GTK bindings have over Rust's Qt bindings is great enough to counteract any advantage that Qt has over GTK. That's because GTK has an (XML?) schema that allows bindings and documentation to be autogenerated to a large extent. Binding to Qt from Rust is in comparison very difficult (not to mention the fact that Qt's idiosyncratic programming model naturally conflicts with Rust's militant ownership concepts). Edit: To be clear, I'm not comparing the relative merits of different GUI options, I'm saying that GTK is the only option that you really have in Rust today.
crimsonalucard 7y ago
What's the "best" solution out there for GUI's? Looking for varying opinions of people who dabbled in several frameworks.
- yoz-y 7y ago
  Personally I’d say: separate data and interface logic to the maximum possible level and then write a truly native interface for each platform that matters to you. This does not apply if your application has so many custom controls that being native does not matter that much (for example a music creation software or a highly advanced raster editor)
  - crimsonalucard 7y ago
    Of course, I'm talking about frameworks for rust that have already done this for me.
wayneftw 7y ago
I want a multi process GUI architecture that lets me send messages to a native rendering process from a bundled sub-process which can be written in any language. Is it a bad idea? I don’t see anybody trying this…
- olah_1 7y ago
  possibly the elixir project Scenic? https://github.com/boydm/scenic https://github.com/boydm/scenic
- pradn 7y ago
  Funny enough, Chrome Embedded Framework runs multiple processes to render the GUI. The main event loop is running in the host process, but there's others for GPU operations, etc.
- hawski 7y ago
  It's a nice idea. One possible implementation could use a Unix domain socket to communicate between client and server. Or even regular sockets to support network transparency. We can call the server X and after eleven versions end up where we are already. X11 and wide idea of terminals go in hand. It's a problem of abstraction and platforms evolving. So I think, that you either end up with something like Web front-ends of today or something more structured, but far simpler like various TUIs or maybe Tcl/Tk with it's windowing shell wish. I think that some middle ground is possible, but hard and shifting quite fast.
  - thequux 7y ago
    I have liked the idea of NeWS for a very long time. Sadly NeWS was born and died long before it was viable: postscript has always been difficult to write a VM for and unfriendly to application programmers, machines were significantly slower, and NeWS itself was very much vendor-locked. However, things are different now. We could embed Lua or WASM into the display server, and you'd have a much more programmer-friendly platform that can run efficiently enough to feel snappy. We have more memory, so you don't need to share toolkits between applications. Maybe it's time to revive the concept.
- 7y ago
yoz-y 7y ago
I may be missing something. I read native and cross platform, project is about TUIs, HTML and GTK... maybe I have my definitions wrong.
- giancarlostoro 7y ago
  Those are some of the outputs possible, TUI is cross-platform, so is GTK and HTML. I don't know why they put them under "supported backends" it would be clearer if he just put "supported output interfaces". If you dig into his "/examples" directory it's all Rust code.
  - yoz-y 7y ago
    Yes but I’d consider neither of those “native”. Except HTML which is native to the web. TUIs are native not GUIs by definition.
mseidl 7y ago
Did my dog Melkor make you?

255 points by ivanceras 7y ago

Hi HN, This is a work-in-progress project inspired by this HN comment[0]. [0]: HN comment -(https://news.ycombinator.com/item?id=19746440 https://news.ycombinator.com/item?id=19746440)

phtrivier 7y ago
Referenced commentator here: I'm totaly new to Rust, but I'll definitely check it out !
jacobush 7y ago
Which ones of the sub-debates did you focus on solving?
- ivanceras 7y ago
  The holy grail part.
  - nixpulvis 7y ago
    Too bad you still need to pay $$$ to get on to the App Store.
  - Dowwie 7y ago
    That's the spirit! :)
Razengan 7y ago
In that linked comment: > 2.1) I want to ship something that looks the same on Windows / Linux / MacOS As a user: No no no, please, no. I want apps to fit the look, feel, and idioms of the OS I'm currently in, not "look the same" on every OS. For example. macOS in particular has many builtin features that work in all apps with standard controls. Like text-to-speech, or converting selected text into all-caps, lowercase, or capitalized. Or custom services/scripts built in Automator. I may not always use these little tricks all the time, but when they fail to work in some app, it immediately feels lower quality, suspicious, and/or suggests a lazy developer. It's not pleasant to use something that ignores the special features of a platform in favor of the lowest common denominator.
- electrograv 7y ago
  Personally, I find that most modern UIs that explicitly do not conform to an OS’s opinionated UI design style (for example: the majority of web stack UIs[1]), are often better in almost every way vs apps that do conform to OS style! When I’m using an advanced UI to do some specialized task, I generally appreciate when the UI patterns I learn on one OS transfer seamlessly to any other device and OS I may use to do the same task. But I especially appreciate that apps can choose the UI style and design to suit the task at hand, rather than some notion of conforming to OS style patterns that may or may not work in its favor. For example, I prefer that Visual Studio Code looks the same on all platforms, because I find its UI to be superior to the default style of any OS! What do you think about these thoughts? Am I alone in preferring custom UIs per app, with consistent app experience across devices? [1] For the sake of this argument, I’m not counting differences in runtime performance and efficiency, since that’s a whole other topic, and one theoretically orthogonal to the UI design.
  - Razengan 7y ago
    > Am I alone in preferring custom UIs per app Custom UIs by themselves are not the culprit. Apple itself is "guilty" of that, using special controls and styles for their own apps (including even the new Reminders in Catalina.) But if an app on macOS puts a close button in the upper-right corner of a window or panel (like Windows does) instead of the upper-left, for example, or when an iOS app uses the Android sharing icon, I feel annoyed. A worse and more practical example is when an app is missing some of the global system features I described in my previous comment, like common text field options (spelling, transformations, dictionary lookup etc.) missing from an Electron-based chat app and so on.
  - ridiculous_fish 7y ago
    1. The reason for platform UI conventions is so users can transfer knowledge between apps. Some specialized apps may want to establish their own conventions, because they are aimed at experts who will be investing a lot of time in the app. Most apps aren't in that category. 2. HTML and JS make sucky UIs regardless of how much "work pools", because the underlying APIs are limited and incomplete. For example, scrolling: there is no native support for large tables in HTML, so apps either do some janky faulting in like infinite scroll, or reimplement scrolling entirely. Cut/copy/paste/undo is another example, along with keyboard navigation in general.

vbsteven 7y ago

Interesting project, I’ll be checking this out soon. I’ve been experimenting with several gui libraries in Rust lately and so far the GTK3 bindings seem to be the most promising for building native GUIs in Rust. With native I mean GTK/Qt style fast/performant widgets that do not necessarily use platform-specific widgets. This project seems to use GTK as one of its backends. I’m curious to see how the multiple backends architecture will influence the library design as GTK, html and TUI are vastly different.

krapht 7y ago
Could you say why you disliked the QT Rust bindings?
- vbsteven 7y ago
  I have to spend some more time on it but due to lack of getting started documentation or examples it was hard to get a Hello World project running. On the GTK-rs side the documentation [1] is much better and I was up and running with a sample project in a few minutes. [1]: https://gtk-rs.org/ https://gtk-rs.org/
  - slezyr 7y ago
    Oh, wow. It looks horrible[1] in some cases. Even worse than most C++/Boost constructions. [1]: https://gtk-rs.org/docs-src/tutorial/upcast_downcast https://gtk-rs.org/docs-src/tutorial/upcast_downcast
    - nicoburns 7y ago
      Yeah, existing GUI libraries tend to make heavy use of inheritance, which Rust doesn't support very well. I have high hopes for a Rust-native GUI library being the goto cross-platform UI library at some point. But that's probably still 2-5 years off at this point.
- ssokolow 7y ago
  While i'm not vbsteven, I can probably give a useful answer to your question. As a KDE user, QML is about as useful to me as GTK+ when it comes to feeling native, so bindings built around those APIs are out. rust-qt-binding-generator (the one maintained by KDE people) is fundamentally designed around the assumption that you're comfortable writing parts of your program in C++. (It's designed for embedding Rust pieces in a project with its own build automation, like CMake, and where hand-written C++ will still be used for part of the process of talking to Qt.) rust-qt comes the closest to what I want (something where, as long as I don't touch the `unsafe` keyword and I only pick trustworthy dependencies, I can't accidentally introduce memory-unsafety into my project.) but "Creating custom signals from Rust code." is still on the TODO list and its development seems to have run out of steam. So far, my solution has been to use Rust to write a cleanly encapsulated backend, use rust-cpython to expose it to Python, and then use PyQt5 (because I haven't started a new Qt project since PySide2 matured) to build a frontend, producing a QML-esque development experience for the QWidget APIs... though I'd still much rather have strong compile-time checks for the entire project.

rapsey 7y ago

These projects always stop (or make no useful progress) at the really difficult/tedious work of abstracting cocoa and win32 API.

phtrivier 7y ago
Isn't this abstraction already done (at least partly) by gtk ? (Or are you thinking of another level of abstraction - otherwise gtk would be enough ?)
- rapsey 7y ago
  No gtk draws its own widgets.
- rvz 7y ago
  When it comes to using only GTK+ for the cross-platform use-case, it already has the Cocoa and Win32 back-ends built in via the GDK, which that API is abstracted to GTK+ so that work is already done. It maybe enough to solve the Rust GUI problem on Win/Mac/Linux, however the drawback to using GTK+ is that it will look out of place on other platforms other than Linux, because of the GNOME _look and feel_ it brings. I think the author might have to support GTK+ theming options to counter this issue then? If not then perhaps using GTK+ for Linux and using the win32 and cocoa crates separately and abstracting that might be something worth looking at?
  - danieldk 7y ago
    however the drawback to using GTK+ is that it will look out of place on other platforms other than Linux, because of the GNOME _look and feel_ it brings. It is not worse than electron in that respect ;). But some small Rust Gtk+ utility that I have for personal uses a whopping 7564KB of resident anonymous memory.
    - jakevn 7y ago
      Personally, my issue with Electron is that, in practice, it is hugely inefficient. The up-side to Electron, IMO, is that it doesn't try to straddle the uncanny valley of native GUIs. In GTK, usually everything _looks_ like a normal GUI, but behaves/looks just a little (or, often times, a lot) bit different than what is expected.

PunksATawnyFill 7y ago

Can someone tell us what advantages Rust offers over other recent languages like Swift?

Multicomp 7y ago

This ui framework, if not abandoned by the tedium of win32 api integration, will make me sit up and actually try Rust for the first time. The TUI in particular looks great. 2020 was already slated for Rust for me but this may make me start dabbling in it a few months early (assuming I can find up to date leaning materials) Tldr great job, please don't give up on the hard part of win32 and macos but this has a great foundation feature set.

ivanceras 7y ago
The core architecture is not done yet. I put this out in the open in the hope it will get more contributions, since I will be working on to a next project. An enthusiast would certainly be able to play with it and maybe experiment with the core architecture.
- rapsey 7y ago
  So you scratched your itch, now you are hoping someone else does the actual work.
  - ivanceras 7y ago
    Exactly, isn't that what opensource is meant for?
    - rapsey 7y ago
      I think most would disagree opensource being meant as a dumping ground.
      - ivanceras 7y ago
        So, would you rather have me hoard this into my local workspace until forgotten? Or release it in the open since I will be working on a project that actually pays money. At least if somebody will be building something similar he/she can look up at this code and maybe make a derivative out of it.

alkonaut 7y ago

Good to see more alternatives in this space. If I can make one big app design request it would be this: Don’t assume that apps can always create their own windows. This has been a snag for winit and several others. Allow creating a GUI given an existing window handle. See e.g. https://github.com/rust-windowing/winit/issues/159 https://github.com/rust-windowing/winit/issues/159 If you create a rust ui framework that supports the VST windowing/event loop model and just supports one GUI backend on Win32/MacOS, then many people in the audio plugin community would be very happy.

deleted 7y ago

[deleted]

wokwokwok 7y ago

It runs on wasm in a browser; not really mobile support. ...and the author is abandoning it to move on to other things? /shrug Didn’t solve any of the actually hard problems of a cross platform or rust based UI imo.

ivanceras 7y ago
I'm not really abandoning it. It's just that I will be spending much less time than I used to, since I am accepting a full-time job to work on something that is not related to this project.
- rco8786 7y ago
  Same thing, friend.
api 7y ago
I pimp this project any chance I get: https://github.com/andlabs/libui https://github.com/andlabs/libui We're considering using it for the next generation of the ZeroTier desktop UI. Unfortunately no mobile support (but we already have native mobile UIs), but it looks like the best contender for a cross platform UI lib that is light and fluffy and simple. Rust bindings should be trivial. There are high quality Go bindings here: https://github.com/andlabs/ui https://github.com/andlabs/ui
- itronitron 7y ago
  >> a cross platform UI lib that is light and fluffy and simple Can you comment on whether you evaluated Java Swing or Java FX as a cross platform UI lib for your needs? I am curious to hear others thoughts on the matter.
  - auggierose 7y ago
    Definitely not light and fluffy ...

faitswulff 7y ago

For anyone else looking to get an overview of available GUI options in rust, there's https://areweguiyet.com/ https://areweguiyet.com/

chrisweekly 7y ago
Thanks! Great resource; bookmarked.
raphlinus 7y ago
One of those efforts is druid. I'm deliberately choosing not to make a lot of noise on social media yet, but I suggest people actively looking for native GUI in Rust take a closer look. Our team (currently two people funded full time, a GSoC student, plus a growing, dedicated community) is solving the hard problems, and we're on the hook for delivering a basic font editor by the end of the year. The webpage and demos don't look impressive yet, but this is because we're currently focusing on building out the core.
- inferiorhuman 7y ago
  Druid and OrbTk have definitely caught my attention. The challenge for me is that while I have relatively simple needs for now (buttons, text, table widgets), I would like to do things not represented by the examples. With the (understandable) paucity of documentation it's difficult to be productive. My current challenge is to swap out different top-level views as I navigate to different parts of the app. This may may be something best suited to something like Cursive.rs, but I'm still holding out hope that the GUI toolkits will mature at a reasonable clip. It's really quite refreshing to see something more portable and lightweight than Electron gain traction. So far the only major detractor I've seen is that the project uses Zulip for chat/messaging and it's put behind a registration wall.
- mrec 7y ago
  Is that 2+1GSoC team focussed purely on druid, or is it the xi team working on druid as part of that project?

nautilus12 7y ago

Since its a front end component and front end people are used to looking at gorgeous front ends and since you took the effort to make it functional (well done!) you should take the little bit of extra effort to also make it look pretty so it resonates with your audience. :). Rust is more a system language so you want to avoid that stigma from the outset.

whatshisface 7y ago

For Rust programmers that want to write GUIs, I highly recommend gtk-rs. It does not have the easiest-to-read documentation in the world but it is a good wrapper of gtk and it suffices for production use. Although it has not reached 1.0 yet, the changes to the API are slow and mostly happen in esoteric corners, so the development cost of keeping up is not noticeable. Further, since cargo has good versioning, it won't update and surprise you.

ssokolow 7y ago
In the GTK+ 2.x era, I would have agreed with you. GTK+ was either the basis for or easily themeable to feel reasonably native under any Linux desktop environment and, because of the applications which depend on it, pretty much everyone is likely to have it already installed. Unfortunately, in the GTK+ 3.x era and beyond, the perspective of many KDE users is that hell has frozen over because GTK+ has supplanted MacOS as the GUI with the most alien feel to it. (Plus, the LXDE developers started a transition to GTK+ 3.x, got fed up, and decided that their upgrade path from GTK+ 2.x would be Qt 5. They then merged with Razor-Qt to form LXQt.) Personally, what rubs me the wrong way the most is the various ways in which it explicitly goes against what HCI research recommends because the GNOME people just liked it better their way. (And I've read quotes by the devs showing that they now see GTK+ as GNOME's toolkit first and other desktops are on their own if they don't want to ride along... which explains things like how long it took them to stabilize the GTK+ 3.x theming APIs.) I still might consider it if the gtk3-mushrooms patchset for making GTK+ 3.x less alien weren't a single-person, amateur effort that's only packaged for Archlinux. (https://github.com/krumelmonster/gtk3-mushrooms https://github.com/krumelmonster/gtk3-mushrooms)
- whatshisface 7y ago
  The advantage that Rust's GTK bindings have over Rust's Qt bindings is great enough to counteract any advantage that Qt has over GTK. That's because GTK has an (XML?) schema that allows bindings and documentation to be autogenerated to a large extent. Binding to Qt from Rust is in comparison very difficult (not to mention the fact that Qt's idiosyncratic programming model naturally conflicts with Rust's militant ownership concepts). Edit: To be clear, I'm not comparing the relative merits of different GUI options, I'm saying that GTK is the only option that you really have in Rust today.

crimsonalucard 7y ago

What's the "best" solution out there for GUI's? Looking for varying opinions of people who dabbled in several frameworks.

yoz-y 7y ago
Personally I’d say: separate data and interface logic to the maximum possible level and then write a truly native interface for each platform that matters to you. This does not apply if your application has so many custom controls that being native does not matter that much (for example a music creation software or a highly advanced raster editor)
- crimsonalucard 7y ago
  Of course, I'm talking about frameworks for rust that have already done this for me.

wayneftw 7y ago

I want a multi process GUI architecture that lets me send messages to a native rendering process from a bundled sub-process which can be written in any language. Is it a bad idea? I don’t see anybody trying this…

olah_1 7y ago
possibly the elixir project Scenic? https://github.com/boydm/scenic https://github.com/boydm/scenic
pradn 7y ago
Funny enough, Chrome Embedded Framework runs multiple processes to render the GUI. The main event loop is running in the host process, but there's others for GPU operations, etc.
hawski 7y ago
It's a nice idea. One possible implementation could use a Unix domain socket to communicate between client and server. Or even regular sockets to support network transparency. We can call the server X and after eleven versions end up where we are already. X11 and wide idea of terminals go in hand. It's a problem of abstraction and platforms evolving. So I think, that you either end up with something like Web front-ends of today or something more structured, but far simpler like various TUIs or maybe Tcl/Tk with it's windowing shell wish. I think that some middle ground is possible, but hard and shifting quite fast.
- thequux 7y ago
  I have liked the idea of NeWS for a very long time. Sadly NeWS was born and died long before it was viable: postscript has always been difficult to write a VM for and unfriendly to application programmers, machines were significantly slower, and NeWS itself was very much vendor-locked. However, things are different now. We could embed Lua or WASM into the display server, and you'd have a much more programmer-friendly platform that can run efficiently enough to feel snappy. We have more memory, so you don't need to share toolkits between applications. Maybe it's time to revive the concept.
7y ago

yoz-y 7y ago

I may be missing something. I read native and cross platform, project is about TUIs, HTML and GTK... maybe I have my definitions wrong.

giancarlostoro 7y ago
Those are some of the outputs possible, TUI is cross-platform, so is GTK and HTML. I don't know why they put them under "supported backends" it would be clearer if he just put "supported output interfaces". If you dig into his "/examples" directory it's all Rust code.
- yoz-y 7y ago
  Yes but I’d consider neither of those “native”. Except HTML which is native to the web. TUIs are native not GUIs by definition.

mseidl 7y ago

Did my dog Melkor make you?