9 ms·

Pretty cool project, seems like it's becoming more realistic to write cross platform native desktop applications with OS-specific GUIs in Rust. It's not too fa

Pretty cool project, seems like it's becoming more realistic to write cross platform native desktop applications with OS-specific GUIs in Rust. It's not too far from the write-once-run-everywhere philosophy of React native, Electron and similar. One could write their UI state and application logic once while maintaining 3 entry points using the various platform GUI bindings (gtk-rs, cacao, win32?) to represent the UI state. This has the advantage of a project feeling natural to the platform while still allowing for code reuse between platforms - though you would still need to rewrite widgets/components for each platform independently. Something that isn't talked about much in the GUI world (outside of mobile development) is how essential multi-threading is to a great application experience. After all, you can't horizontally scale a client device so it's important that an application is able to maximize its use of the available hardware. Rust's borrow checker/ownership model eliminates dangerous multi-threaded code which makes it practical to write highly efficient GUI applications. Could be good for projects like cross-platform terminal emulators or code editors.

hot_gril 3y ago
The GUI bindings are usually the hard part.
- heavyset_go 3y ago
  Speaking of, does anyone know how Qt bindings for Rust are these days? Last time I looked, there were several awkward Rust APIs for Qt, suffering in part from the fact that Qt's API is inheritance-based.
  - ThePhysicist 3y ago
    I think it's pretty difficult mapping the Qt memory management model to Rust, for the same reason we haven't seen working Golang bindings for Qt either. I have some experience with the Python bindings (PySide or PyQt) and both of them use pretty extensive wrapper generator frameworks specially developed for the task (SIP in the case of PyQt, Shiboken in the case of PySide), coming up with something like that is not an easy task at all. And Python is a language that was pretty much intended to act as a foreign function wrapper around low-level languages, while Rust & Golang are not primarily intended to be wrappers for other languages.
    - foldr 3y ago
      > https://github.com/therecipe/qt https://github.com/therecipe/qt Do these not work? (Not a rhetorical question - I haven’t tried them.)
      - c4mpute 3y ago
        They used to work until the big modules change a few golang releases ago. Now, nothing works anymore unless you exhume a sufficiently old golang compiler. The project also seems dead since 2020 or so, a current fork is https://github.com/bluszcz/cutego/ https://github.com/bluszcz/cutego/ But I haven't tried that one.
        foldr 3y ago
        I see what you mean about this particular project, but more generally, you can certainly use pre-modules Go code with current Go compilers. See e.g. https://github.com/golang/go/issues/37797 https://github.com/golang/go/issues/37797 (a case of someone not RTFMing, but the response illustrates how it's done). If you just want to pretend modules never happened, then export GO111MODULE=off and use the latest Go compiler.
        c4mpute 3y ago
        In most cases, these things would work, but not here. Tried everything, nothing works except using a pre-modules-compiler. In general, golang seems to work best with golang-only projects. As soon as there are other languages in the mix, like C++ here, things get very ugly very fast.
        foldr 3y ago
        Ah, I think I misinterpreted what you meant by "nothing works anymore". I thought you were saying that no old Go projects were usable with new Go compilers. I believe you that this particular project may not work with the current toolchain.
  - sbt567 3y ago
    There is a recent article about this on r/rust https://blog.logrocket.com/build-desktop-app-qt-rust/ https://blog.logrocket.com/build-desktop-app-qt-rust/
riceart 3y ago
> Something that isn't talked about much in the GUI world (outside of mobile development) is how essential multi-threading is to a great application experience. Yes it is. Heavyweight desktop GUI applications like DAWs or CAD or image/video editing are old established technology. > This has the advantage of a project feeling natural to the platform while still allowing for code reuse between platforms Having written cross platform native applications: This is a pain in the ass to do well - and there isn’t a particular reason this hasn’t been doable in C/C++ since forever - Rust isn’t some silver bullet. “Abstracting” away the native GUI/UX seems to be a common pitfall for junior devs - how hard can it be they think - then they learn why Qt exists. > It's not too far from the write-once-run-everywhere philosophy of React native, Electron and similar. Electron is about as far removed from the philosophy of targeting platform native toolkits as one can get.
- apatheticonion 3y ago
  I do have a naive view on native GUI development because I have little real experience in it - I very much appreciate your insight. > “Abstracting” away the native GUI/UX seems to be a common pitfall for junior devs I would like to know more about what you mean here; my description of a "virtual UI" that you bind to from the native toolkit is an abstraction to the UI - but it's not an abstraction like Flutter which tries to merge all native widgets into abstracted widgets. My concept still requires you to write multiple native entry points using the UI kits of the target platforms. ` (GTK entry || Cacao entry || Win entry) => Virtual UI => application logic ` The idea is that the virtual UI would be an in-memory representation of the UI (have virtual buttons, labels, etc). It would be the job of the entry to correctly represent/bind to that virtual UI with the relevant presentation tool kit. The output binary would be specialised to the platform/UI kit used in the source entry point. It seems sensible on the surface to decouple the UI from the native presentation as it minimizes the requirements of the native side to constructing the UI and binding to the virtual UI - but I would love to hear your thoughts. I have not tested this architecture outside of web development but I imagine adding new UI targets (like web assembly, QT, etc) would be easier as it wouldn't require any changes to the virtual UI or application logic and would be a matter of creating a new entry point representing the UI for the new target. > then they learn why Qt exists Does QT feel native on MacOS, Windows and Gnome? > Yes it is [talked about] Could be my personal echo chambers talking here - but multithreading is almost never spoken about and/or often intentionally disregarded in modern web/electron applications. It sucks because so many applications are written using Electron or other similar web wrappers. > there isn’t a particular reason this hasn’t been doable in C/C++ since forever - Rust isn’t some silver bullet Not dismissing this, I was more impressed that Rust offers a thread safety guarantee through its ownership model making it interesting from a contributor scalability standpoint. I was thinking that it might make it easier to have more engineers working on a high performance GUI project because it would be significantly harder to break. As an example; I could imagine if a company assigned a team of TypeScript/JavaScript developers with different experience levels onto a GUI project written in something like Go, there would be a lot of thread safety issues and seniors would spend a lot of time combing PRs for thread safety issues. Rust, while perhaps not as simple from a syntax/types/symbols standpoint, offers an interesting development modality for these sorts of projects. I would expect that it would result in a more hands off contributor experience. > Electron is about as far removed from the philosophy of targeting platform native toolkits as one can get. Sorry I wasn't describing Electron as targeting platform native decorations - just that it promises an OS agnostic UI framework (write once run anywhere) at the expense of a diminished native experience and poor performance. My point was that it might be interesting to explore the idea that a multi-entry native toolkit application fulfils the same "write once run 'anywhere'" promise but without the downsides.
olliej 3y ago
You can't write good UI apps with cross platform code. The basic idioms of each platform are different. You can write your core application logic once and share it, but you need to have the interaction with the actual UI/window manager be per-platform. The reason electron apps are so bad on Mac is not that the core application logic is bad, it's that a whole bunch of basic Mac platform behaviors are broken. "modern" cross platform UI toolkits are no better than Java. To paraphrase Ford: "you can do any platform you like, as long as it's windows". [edit: to be very clear, I include "catalyst" in the cross platform toolkits that make noticeably worse apps on Mac. Trying to share a single interface "language" for different platforms just leads to what is at best mediocre UI.]
- lost_tourist 3y ago
  You can write "good enough" ones though, and I've been doing it for years.
- criddell 3y ago
  Cross platform toolkits are a way of getting something good enough, quickly. Our standards may be different, but I would say you can get something good. You likely won’t get something great though. I agree with your statement about modern toolkits being no better than Java, but Java is pretty good. I’d have no problem starting a new project with it today. All that said, I’d much rather have a well written native application than a well written cross platform application.
  - pjmlp 3y ago
    If anything, many of them are much worse in capabilities. https://www.oreilly.com/library/view/filthy-rich-clients/9780132413930/ https://www.oreilly.com/library/view/filthy-rich-clients/978...
- amelius 3y ago
  Can you give an example of something can only be done in a native app? And why wouldn't a hybrid approach work? I.e. the majority of the code using the cross platform toolkit, and a small amount of code per platform using the native API.

hot_gril 3y ago

The GUI bindings are usually the hard part.

heavyset_go 3y ago
Speaking of, does anyone know how Qt bindings for Rust are these days? Last time I looked, there were several awkward Rust APIs for Qt, suffering in part from the fact that Qt's API is inheritance-based.
- ThePhysicist 3y ago
  I think it's pretty difficult mapping the Qt memory management model to Rust, for the same reason we haven't seen working Golang bindings for Qt either. I have some experience with the Python bindings (PySide or PyQt) and both of them use pretty extensive wrapper generator frameworks specially developed for the task (SIP in the case of PyQt, Shiboken in the case of PySide), coming up with something like that is not an easy task at all. And Python is a language that was pretty much intended to act as a foreign function wrapper around low-level languages, while Rust & Golang are not primarily intended to be wrappers for other languages.
  - foldr 3y ago
    > https://github.com/therecipe/qt https://github.com/therecipe/qt Do these not work? (Not a rhetorical question - I haven’t tried them.)
    - c4mpute 3y ago
      They used to work until the big modules change a few golang releases ago. Now, nothing works anymore unless you exhume a sufficiently old golang compiler. The project also seems dead since 2020 or so, a current fork is https://github.com/bluszcz/cutego/ https://github.com/bluszcz/cutego/ But I haven't tried that one.
      - foldr 3y ago
        I see what you mean about this particular project, but more generally, you can certainly use pre-modules Go code with current Go compilers. See e.g. https://github.com/golang/go/issues/37797 https://github.com/golang/go/issues/37797 (a case of someone not RTFMing, but the response illustrates how it's done). If you just want to pretend modules never happened, then export GO111MODULE=off and use the latest Go compiler.
        c4mpute 3y ago
        In most cases, these things would work, but not here. Tried everything, nothing works except using a pre-modules-compiler. In general, golang seems to work best with golang-only projects. As soon as there are other languages in the mix, like C++ here, things get very ugly very fast.
        foldr 3y ago
        Ah, I think I misinterpreted what you meant by "nothing works anymore". I thought you were saying that no old Go projects were usable with new Go compilers. I believe you that this particular project may not work with the current toolchain.
- sbt567 3y ago
  There is a recent article about this on r/rust https://blog.logrocket.com/build-desktop-app-qt-rust/ https://blog.logrocket.com/build-desktop-app-qt-rust/

riceart 3y ago

> Something that isn't talked about much in the GUI world (outside of mobile development) is how essential multi-threading is to a great application experience. Yes it is. Heavyweight desktop GUI applications like DAWs or CAD or image/video editing are old established technology. > This has the advantage of a project feeling natural to the platform while still allowing for code reuse between platforms Having written cross platform native applications: This is a pain in the ass to do well - and there isn’t a particular reason this hasn’t been doable in C/C++ since forever - Rust isn’t some silver bullet. “Abstracting” away the native GUI/UX seems to be a common pitfall for junior devs - how hard can it be they think - then they learn why Qt exists. > It's not too far from the write-once-run-everywhere philosophy of React native, Electron and similar. Electron is about as far removed from the philosophy of targeting platform native toolkits as one can get.

apatheticonion 3y ago
I do have a naive view on native GUI development because I have little real experience in it - I very much appreciate your insight. > “Abstracting” away the native GUI/UX seems to be a common pitfall for junior devs I would like to know more about what you mean here; my description of a "virtual UI" that you bind to from the native toolkit is an abstraction to the UI - but it's not an abstraction like Flutter which tries to merge all native widgets into abstracted widgets. My concept still requires you to write multiple native entry points using the UI kits of the target platforms. ` (GTK entry || Cacao entry || Win entry) => Virtual UI => application logic ` The idea is that the virtual UI would be an in-memory representation of the UI (have virtual buttons, labels, etc). It would be the job of the entry to correctly represent/bind to that virtual UI with the relevant presentation tool kit. The output binary would be specialised to the platform/UI kit used in the source entry point. It seems sensible on the surface to decouple the UI from the native presentation as it minimizes the requirements of the native side to constructing the UI and binding to the virtual UI - but I would love to hear your thoughts. I have not tested this architecture outside of web development but I imagine adding new UI targets (like web assembly, QT, etc) would be easier as it wouldn't require any changes to the virtual UI or application logic and would be a matter of creating a new entry point representing the UI for the new target. > then they learn why Qt exists Does QT feel native on MacOS, Windows and Gnome? > Yes it is [talked about] Could be my personal echo chambers talking here - but multithreading is almost never spoken about and/or often intentionally disregarded in modern web/electron applications. It sucks because so many applications are written using Electron or other similar web wrappers. > there isn’t a particular reason this hasn’t been doable in C/C++ since forever - Rust isn’t some silver bullet Not dismissing this, I was more impressed that Rust offers a thread safety guarantee through its ownership model making it interesting from a contributor scalability standpoint. I was thinking that it might make it easier to have more engineers working on a high performance GUI project because it would be significantly harder to break. As an example; I could imagine if a company assigned a team of TypeScript/JavaScript developers with different experience levels onto a GUI project written in something like Go, there would be a lot of thread safety issues and seniors would spend a lot of time combing PRs for thread safety issues. Rust, while perhaps not as simple from a syntax/types/symbols standpoint, offers an interesting development modality for these sorts of projects. I would expect that it would result in a more hands off contributor experience. > Electron is about as far removed from the philosophy of targeting platform native toolkits as one can get. Sorry I wasn't describing Electron as targeting platform native decorations - just that it promises an OS agnostic UI framework (write once run anywhere) at the expense of a diminished native experience and poor performance. My point was that it might be interesting to explore the idea that a multi-entry native toolkit application fulfils the same "write once run 'anywhere'" promise but without the downsides.

olliej 3y ago

You can't write good UI apps with cross platform code. The basic idioms of each platform are different. You can write your core application logic once and share it, but you need to have the interaction with the actual UI/window manager be per-platform. The reason electron apps are so bad on Mac is not that the core application logic is bad, it's that a whole bunch of basic Mac platform behaviors are broken. "modern" cross platform UI toolkits are no better than Java. To paraphrase Ford: "you can do any platform you like, as long as it's windows". [edit: to be very clear, I include "catalyst" in the cross platform toolkits that make noticeably worse apps on Mac. Trying to share a single interface "language" for different platforms just leads to what is at best mediocre UI.]

lost_tourist 3y ago
You can write "good enough" ones though, and I've been doing it for years.
criddell 3y ago
Cross platform toolkits are a way of getting something good enough, quickly. Our standards may be different, but I would say you can get something good. You likely won’t get something great though. I agree with your statement about modern toolkits being no better than Java, but Java is pretty good. I’d have no problem starting a new project with it today. All that said, I’d much rather have a well written native application than a well written cross platform application.
- pjmlp 3y ago
  If anything, many of them are much worse in capabilities. https://www.oreilly.com/library/view/filthy-rich-clients/9780132413930/ https://www.oreilly.com/library/view/filthy-rich-clients/978...
amelius 3y ago
Can you give an example of something can only be done in a native app? And why wouldn't a hybrid approach work? I.e. the majority of the code using the cross platform toolkit, and a small amount of code per platform using the native API.