14 ms·

Speedy Desktop Apps with GTK and Rust

226 points by luu 7y ago

fasterdom 7y ago
Is anybody working on bringing reactivity to GUI development? After working with Vue/React, doing GUI apps "the old way" feels like writing quick-sort in assembly language.
- rohan1024 7y ago
  Check out flutter
- baybal2 7y ago
  I've been in involuntarily involved in webdev for quite a few years. I will give everything to get that quick and easy manner of building GUIs in GTK+ to the web. I wrote my first GTK+ program in my high school years in 2014-2015, and I can't think of any native toolkit ever approached the ease of work of GTK.
  - baybal2 7y ago
    Typo, my school years were a decade earlier :)
  - Narishma 7y ago
    > I can't think of any native toolkit ever approached the ease of work of GTK. Which other native UI toolkits do you have experience with to make that claim?
    - baybal2 7y ago
      Been working on Windows side with every Microsoft's take on GUI library, Android, tried Qt (before QML,) and am involuntarily dealing with all those Web toolkits on almost every project involving web.
- vnorilo 7y ago
  Microsoft and others have MVVM frameworks, such as WPF, which have reactive data binding. Qt Quick also, but I haven't tried it myself. That said, it is not that similar to React or Vue because the "DOM"s are so different.
  - baybal2 7y ago
    Try to use WPF from anything other than dotnet. It will be hard, given that you will have to hack its main loop to work with an external code. I'm not sure if that was ever done.
    - pjmlp 7y ago
      It works from any language that speaks COM.
      - baybal2 7y ago
        Any real world examples?
        pjmlp 7y ago
        Probably not the way you are thinking. - Write the WPF view code in any .NET language and expose the classes to COM as COM Callable Wrapper (https://docs.microsoft.com/en-us/dotnet/framework/interop/com-callable-wrapper https://docs.microsoft.com/en-us/dotnet/framework/interop/co...) - Similar way, but using Windows HWND messages instead, https://docs.microsoft.com/en-us/dotnet/framework/wpf/advanced/walkthrough-hosting-wpf-content-in-win32 https://docs.microsoft.com/en-us/dotnet/framework/wpf/advanc... - Or if using Windows 10, given that UWP is COM vNext, and Microsoft is merging both worlds, use XAML Islands, https://docs.microsoft.com/en-us/windows/apps/desktop/modernize/using-the-xaml-hosting-api https://docs.microsoft.com/en-us/windows/apps/desktop/modern...
- awestroke 7y ago
  https://github.com/maps4print/azul https://github.com/maps4print/azul
- rpeden 7y ago
  Microsoft very actively works on React Native for Windows, and last I checked there were decent RN desktop ports for Linux and MacOS. So that's one potential option.
  - pjmlp 7y ago
    Given that they were even measuring the performance against Electron, there is some small hope that eventually VSCode gets rewritten in it.
    - Const-me 7y ago
      I don't think they care about performance a tiny bit. Here's very simple to implement change which saves dozens of MB of IO bandwidth every startup: https://github.com/Microsoft/vscode/issues/61343 https://github.com/Microsoft/vscode/issues/61343 "We will very likely not do this."
      - pjmlp 7y ago
        Then check BUILD 2019 talk about React Native for Windows. Electron gets a couple of jabs, including a very nice bar comparison chart.
- ubercow13 7y ago
  Maybe https://github.com/revery-ui/revery/blob/master/README.md https://github.com/revery-ui/revery/blob/master/README.md
- robto 7y ago
  I know about revery[0] and cljfx[0], though I haven't had the chance to use them in anger. These both seem like very nice approaches to me - I'm partial to cljfx because I've been utterly spoiled by the clojure/script development experience, but I've also come to enjoy the typescript environment and revery seems to another step along that road. [0]https://github.com/revery-ui/revery https://github.com/revery-ui/revery [1]https://github.com/cljfx/cljfx https://github.com/cljfx/cljfx
  - geokon 7y ago
    Be sure to also check out fn-fx. I've tried both but haven't really done anything complex enough to bring out which one is a clear winner https://github.com/fn-fx/fn-fx https://github.com/fn-fx/fn-fx Fn-fx is a more complex beast and no one seems to really know how it all works internally except the creator who isn't maintaining it.. so unfortunately it's in a semi unmaintained state. But the interface was a bit cleaner when I tried it
    - robto 7y ago
      cljfx is actually inspired on fn-fx, and presents a much cleaner and more usable api, just by comparing the docs. I'm pretty sold on data-based apis instead of macro-based ones, though, so maybe it's just catering towards my preferred style of development.
      - geokon 7y ago
        oh okay. you sound more knowledgeable than me, so thanks for the input. I'll stick to cljfx then. I found it clunkier to mix with Java code, so I was considering switching back to fn-fx
- kbumsik 7y ago
  Actually reactivity in GUI (maybe declarative GUI programming is a more accurate form?) is also "the old way" in the GUI development. I mean it is already done a decade ago, even before react. Try QML. The view is automatically updated when a signal is triggered or its state changes. You will notice that it is surprisingly simpler than React. React got so popular because React implemented it very nicely in the web browsers, not because it brought new concepts.
  - sunebeck 7y ago
    Oh, I see - I take my comment back then :-)
  - realharo 7y ago
    Last time I looked at QML (a few years ago), you couldn't just use any data in your UI directly, you had to wrap it in clunky models. When using C++, looks like you have to use things like QAbstractListModel https://qmlbook.github.io/ch16-qtcpp/qtcpp.html#a-simple-model https://qmlbook.github.io/ch16-qtcpp/qtcpp.html#a-simple-mod... Even without C++, there are things like ListModel and ListElement https://qmlbook.github.io/ch07-modelview/modelview.html https://qmlbook.github.io/ch07-modelview/modelview.html This is a far cry from React where you just use language-native data structures directly (you only need to do mutations in specific ways). As far as I can tell, you also can't just use native language constructs like functions/ifs/.map, etc. to compose the UI elements. Instead you have containers like Repeater. It seems very different to me compared to React, like built around a significantly different philosophy.
    - asveikau 7y ago
      Your comment seems to just be highlighting the fact that inspecting types at runtime is non-idiomatic at best in C++ or similar languages, so it would make sense to require a specific data structure or format. Even defining what a "native" type is seems like it would be fraught. I guess the c++ way would be to accept begin and end iterators - but of what type?
      - 7y ago
- floatboth 7y ago
  https://github.com/antoyo/relm https://github.com/antoyo/relm
- FreezerburnV 7y ago
  JavaFX actually has a lot of reactive elements in its design. Basically every attribute of any GUI element are an “observable” type which allow you to register handlers for doing stuff when the internal value changes.
  - walkingolof 7y ago
    JavaFX is great and looks fantastic, surprised it’s not used more
    - FreezerburnV 7y ago
      There seems to be a perception that anything running on the JVM is going to be slow and look bad. Considering I work with Java every day in a gigantic Swing application, (IntelliJ IDEA, if you didn’t guess) and it has great performance for all the things it’s doing for me, that seems to be an old holdover from early days of Java. Also enterprise apps, which of course are going to be bad and slow. At least the JVM has real threads for background work which don’t take another 100MB of RAM like an electron background worker :)
      - walkingolof 7y ago
        Yea, its hard to wash out a stain like that, in general, JIT:d JVM based applications performs as good or better than AOT application, but do still need more memory.
        FreezerburnV 7y ago
        The “or better” tagged into JVM applications really needs to go away. Realistically, most JVM applications do not have as good performance as native ones. Yes, it’s possible to run better, but it’s very hard to create code that JITs to something faster than a thing written in C/C++/Rust/etc. You have to basically write code that looks like C to make it run as fast or faster, because there’s real overhead that comes with a lot of things in the JVM. You don’t just write standard Java or Scala and suddenly it’s as fast as C++, in general. It’s still heckin blazing fast, to be fair, but not AS heckin blazing fast. (As long as you aren’t just going insane with objects, at least, such as huge lists of integer objects)
- pjmlp 7y ago
  Yes, about 10 years ago with WPF, QML, JavaFX.
  - fasterdom 7y ago
    I've used WPF extensively 10 years ago. It's nowhere near as easy to create a complex GUI as Vue/HTML/CSS. And that just for functionality. If we talk about looks, WPF is very clunky to theme.
    - turrini 7y ago
      There is QML and it can compile natively for many platforms. With the same source code, my applications are natively compiled to: Linux, Windows, MacOS, Android, iOS, QNX, Browser (WebAssembly / WebGL Streaming) And you are free to theme it as you like, one example: https://imgur.com/Ti02n6Y https://imgur.com/Ti02n6Y
    - pjmlp 7y ago
      I happen to have the opposite view, specially with Blend and component libraries into the mix. CSS had to get WPF grid design in order to not be a poor table sibling in what concerns layouts. While WPF is backed by DirectX, CSS requires playing with Z order, so that some browsers might eventually put the rendering into the GPU, but one needs to take care because space is limited. While I can render anything down to pixel level control, if I wish to do so, I am still waiting for Houdini and worlets to actually become available. And the whole template language with events and theming for low level customisation of control behaviours? Nowhere to be seen.
      - fasterdom 7y ago
        Using Blend feels to me like using Word to create HTML pages - the resulting output is horrible. CSS layout was indeed a struggle many years ago, but now with flexbox I never failed to put stuff exactly where I wanted, and I barely understand it. And the new shiny thing, CSS Grid, is supposedly even better at controlling layout.
    - 7y ago
- c-smile 7y ago
  Sciter ( https://sciter.com https://sciter.com ) and Sciter/Rust for that matter: https://github.com/sciter-sdk/rust-sciter https://github.com/sciter-sdk/rust-sciter It adds single 5mb DLL to the equation. Yet it allows to build native applications where UI structure is defined by HTML, style by CSS and reactivity by script or by Rust (or by C++, Go, Python, etc.) "Sciter makes GUI programming genuinely fun!" https://sciter.com/forums/topic/attach-detach-behavior/#post-61347 https://sciter.com/forums/topic/attach-detach-behavior/#post...
  - amelius 7y ago
    What HTML/CSS rendering engine does it use? And in case it has its own implementation, then how good and up to date is the HTML/CSS support?
    - c-smile 7y ago
      It uses its own HTML/CSS engine designed by myself to be embeddable from ground up. Check this: https://sciter.com/10-years-road-to-sciter/ https://sciter.com/10-years-road-to-sciter/ As of HTML: most of HTML5 constructs (I participated in HTML5 spec development at W3C as Invited Expert) As of CSS: CSS2.1 in full. Some practically useful modules of CSS3 - transitions, transforms, etc. I haven't added FlexBox as I think it is an architectural disaster - will not survive on the long run. Instead Sciter offers "flow and flex units" module: https://sciter.com/docs/flex-flow/flex-layout.htm https://sciter.com/docs/flex-flow/flex-layout.htm that covers as FlexBox as Grid in unified manner. Yet check this: https://terrainformatica.com/w3/flex-layout/flex-vs-flexbox.htm https://terrainformatica.com/w3/flex-layout/flex-vs-flexbox.... Yet, I've added quite a lot of HTML/CSS features that are the must for specifically desktop UI: - <menu class=popup> and <popup> elements and their CSS support - windowed DOM elements that are rendered outside of main window canvas. - <frame type=pager> - print preview and print feature. - view.dialog("some.html"), view.window("some.html"), view.msgbox("some.html") - HTML defined windows and dialogs. - <htmlarea> - native WYSIWYG HTML editing widget. More on this: https://sciter.com/developers/for-web-programmers/ https://sciter.com/developers/for-web-programmers/
      - 7y ago
- voodootrucker 7y ago
  See this [0] native UI for Rust. It's the primary UI for Redox OS and it's inspired by React. [0] https://github.com/redox-os/orbtk https://github.com/redox-os/orbtk
- matthewmacleod 7y ago
  Swift is going this way with SwiftUI but you aren’t likely to see it anywhere except Apple platforms in the immediate future.
- edwinyzh 7y ago
  https://github.com/pierrejean-coudert/ReduxDelphi https://github.com/pierrejean-coudert/ReduxDelphi
- tomjen3 7y ago
  Microsoft. Their XAML apps are pretty much web apps done right, ie not javascript and a more powerful layout system -- and everything on the gui part is reactive.
- ivanceras 7y ago
  Yes, I am. https://twitter.com/ivanceras/status/1147594007897202688 https://twitter.com/ivanceras/status/1147594007897202688
chronogram 7y ago
This is actually a really useful walkthrough. With so many options and things out there, it’s great to have a step by step walkthrough of a project. No idea why anyone would want to do this, because it seems you’ll be hated by half the Linux users for using gtk, but seems cool for personal projects.
- ubercow13 7y ago
  Is there a choice which won't leave you hated by half of Linux users?
  - chronogram 7y ago
    The approach I take, which is to never even interact with them and just keep my projects to friends and myself. I do submit pull requests to upstream projects I use if they’re on GitHub!
  - pmarin 7y ago
    Separate UI code from the logic code.
  - pjmlp 7y ago
    Yes, focus on full stack desktop OSes and get hated from all of them instead. /s Due to desktop Linux fragmentation you will never please everyone, but everyone will feel entitled that your care about their snowflake distribution.
  - simion314 7y ago
    Use Electron, then everyone on all OSes will hate your application. /s I did not see people asking for GTK apps to be ported to Qt (if it happens is much lower then the rewrite it in rust phenomenon) , there were a number of projects that switched from GTK2 to Qt instead of GTK3 because they re-evaluated the toolkits and decided Qt was better for those projects.
    - jancsika 7y ago
      > Use Electron, then everyone on all OSes will hate your application. /s Actually this is a real benefit. It means no one will show up and convince people on your project to waste time packaging your software for [pick a Linux Distribution]. Now instead of getting user reports from a hall of mirrors of various packages for various distros with various states of dependency disrepair, you've got one central source of truth.
dijit 7y ago
I tend to prefer Qt as an end user, are there similar tutorials for Qt+Rust? I remember someone telling me that it’s not as good a fit but I can’t remember why that is.
- hdfbdtbcdg 7y ago
  As a guess it is probably because GTK has a C API whilst Qt is C++.
- simion314 7y ago
  GTK is a C toolkit and Qt is C++, it is easier for other languages to use GTK if those languages have a way to interact with C library. There are a lot of bindings to GTK and very few to Qt.
  - dijit 7y ago
    That explains a lot. Thank you. :)
  - pknopf 7y ago
    https://github.com/qmlnet/qmlnet https://github.com/qmlnet/qmlnet
    - simion314 7y ago
      There were C# Qt bindings since many years ago but those were not official supported so the quality was not that good,once there was a Java official binding/port that was dropped after a short time, I would not use someone's hobby bindings for a real world project(I mean a project with many users that you need to support for years , through OS and oteher system updates)
      - pknopf 7y ago
        I'm the author. The QtSharp project used technology that couldn't really address the problem (MonoCppSharp). QML.Net is different. It is purely a QML integration (no c++ wrapper), using a C interop. There is extensive unit tests for QML.Net, including garbage collection tests. I consider it segfault-proof. It's currently used in production on embedded medical devices: https://medxchange.com/4klear-all-in-one-camera-recorder/ https://medxchange.com/4klear-all-in-one-camera-recorder/
bayesian_horse 7y ago
I think the major benefit of a native/compiled language like C or Rust over interpreted/JIT ones like Python or Javascript for desktop applications is the overhead in terms of distribution size and memory consumption. Speed doesn't come into it that much. Current desktop systems are fast enough such that most GUI manipulation just isn't a speed bottleneck, except for things like realtime graphics or something.
- jasonhansel 7y ago
  What I really wish is that these Electron apps could share a common instance of Chromium. That would help the memory consumption issue a lot, but I'm not sure how to implement it best.
  - GhostVII 7y ago
    Couldn't they just run like a regular website, except be available offline? Then you could just open it up in your browser, so only one instance of Chrome/Firefox is used. Not sure how hard it would be to allow electron apps to run like that, but it seems like they are basically just websites as it is, given that they run on Chromium, maybe it would be harder for them to work with the OS filesystem though. For the electron apps I use, they are generally available online as a website anyways, so I just use that, and get the whole common instance thing for free.
    - kryptiskt 7y ago
      Electron apps have unfettered access to the system (through node.js), they aren't just webpages.
    - pcr910303 7y ago
      Well, Electron is essentially a server and chromium, so there should also be a way to execute nodejs code inside the browser then... which would break sandboxing. I think this isn’t really a problem of Electron, but more to Chromium. We bundle python inside the binary and it’s fine. I don’t think I’ll hate command line programs that embed nodejs inside the binary. It’s the Chromium that’s problematic, and just by switching Chromium to the native WebView will make Electron apps much, much more lightweight.
deleted 7y ago
[deleted]
danielscrubs 7y ago
Isn't the problem that users don't want the eye-candy of 1995, but the one of 2019 and therefore we don't have any choice but to bundle a browser and use JS if we want users? There is a heavy focus on transition animations, fonts, media query breakpoints and drag and drop. It's kind of embarrassing (or a testament to hard of a problem that it is) the state we are in because of (IMO) Microsoft/Apple/Canonical. If they had a really, really good GUI foundation, it'd be a quick job to do a minimal Slack or Things for macOS clone in C++/Rust. Edit: Seems people get irritated about what the users want. But that's not really up to us to decide as coders...
- otabdeveloper4 7y ago
  No. Everyone hates web UI's, including users and programmers. But we need them because they're the only cross-platform and device-independent solution.
  - AnIdiotOnTheNet 7y ago
    That's not true though, they only work on one platform: the web browser, and often they only work well on one specific browser. If you're going to allow a runtime as bloated and complicated as a web browser to count as "cross platform" then you'll have to admit that Java met those same criteria 2 decades ago.
    - otabdeveloper4 7y ago
      A web browser has been ported to literally every platform that has a screen. Java doesn't even come pre-installed on a normal machine. It's not about technical considerations, it's just that one cross-platform runtime has won.
- kbumsik 7y ago
  > because of (IMO) Microsoft/Apple/Canonical. > If they had a really, really good GUI foundation. It is not true at all. They already have really nice GUI foundations. Brining the web tech to desktop apps gots so popular because the web is won so that devs are forced to make web apps, not because it is better than the "traditional" GUI development.
aarroyoc 7y ago
I tried this and is awful. GTK and Rust have two very different ways of managing memory and it's painful. Lucky, gtk-rs already helps you with their own types prepared to be used with Rc but with your custom types you need to define all the garbage collector stuff your yourself which makes the code look very ugly (lots of clone, which aren't really clones). At the end the result is good, but the code looks awful.
- spystath 7y ago
  My experience is kind of similar. Unfortunately the way Rust interacts with memory is quite different from how Gtk does (and most GUI tool-kits to be fair). The end result is a kind-of awkward battle between the Rust borrow checker and the internal memory handling of Gtk+ leading to loads of Rc<RefCell<T>>. This makes also quite hard to implement custom Widgets in an intuitive way. In Python or C++ you would subclass the generic "Widget" class and start implementing the bits you need. With Rust things are slightly complicated; you can't just implement the IsA<Widget> trait and call it a day; at least not a straightforward way. Hopefully gnome-class [0] will probably solve this problem eventually. That being said it's been a while since I've used gtk-rs so it is entirely possible things have changed. I'd love to be corrected if that's the case :) [0] https://gitlab.gnome.org/federico/gnome-class/ https://gitlab.gnome.org/federico/gnome-class/
- duguxu 7y ago
  I have kept an eye on this for a long time. Is there any design pattern with Rust style (no unsafe and not ugly from Rust community's perspective) that proved in prototype to be able to achieve the same scaling of performance and memory usage as native C/C++ GUI framework with more complicated interface (e.g. Office)? Could this be an inherent limit of Rust because of the memory safety principle?
  - pcwalton 7y ago
    I would like to see an ECS style UI design in Rust that represents widgets as IDs, to allow arbitrary object graphs without interior mutability. I don't see a reason why this would be incompatible with GTK, but we won't know until we try. It might work out really well. It also might be that Rust is not the right language to write high level UI logic in at this time, and a GC'd language would be more appropriate. That's fine too. One of the strengths of Rust is its interoperability with other languages. C and C++ are certainly not the right languages to implement high level UI logic in, for example.

226 points by luu 7y ago

Is anybody working on bringing reactivity to GUI development? After working with Vue/React, doing GUI apps "the old way" feels like writing quick-sort in assembly language.

rohan1024 7y ago
Check out flutter
baybal2 7y ago
I've been in involuntarily involved in webdev for quite a few years. I will give everything to get that quick and easy manner of building GUIs in GTK+ to the web. I wrote my first GTK+ program in my high school years in 2014-2015, and I can't think of any native toolkit ever approached the ease of work of GTK.
- baybal2 7y ago
  Typo, my school years were a decade earlier :)
- Narishma 7y ago
  > I can't think of any native toolkit ever approached the ease of work of GTK. Which other native UI toolkits do you have experience with to make that claim?
  - baybal2 7y ago
    Been working on Windows side with every Microsoft's take on GUI library, Android, tried Qt (before QML,) and am involuntarily dealing with all those Web toolkits on almost every project involving web.
vnorilo 7y ago
Microsoft and others have MVVM frameworks, such as WPF, which have reactive data binding. Qt Quick also, but I haven't tried it myself. That said, it is not that similar to React or Vue because the "DOM"s are so different.
- baybal2 7y ago
  Try to use WPF from anything other than dotnet. It will be hard, given that you will have to hack its main loop to work with an external code. I'm not sure if that was ever done.
  - pjmlp 7y ago
    It works from any language that speaks COM.
    - baybal2 7y ago
      Any real world examples?
      - pjmlp 7y ago
        Probably not the way you are thinking. - Write the WPF view code in any .NET language and expose the classes to COM as COM Callable Wrapper (https://docs.microsoft.com/en-us/dotnet/framework/interop/com-callable-wrapper https://docs.microsoft.com/en-us/dotnet/framework/interop/co...) - Similar way, but using Windows HWND messages instead, https://docs.microsoft.com/en-us/dotnet/framework/wpf/advanced/walkthrough-hosting-wpf-content-in-win32 https://docs.microsoft.com/en-us/dotnet/framework/wpf/advanc... - Or if using Windows 10, given that UWP is COM vNext, and Microsoft is merging both worlds, use XAML Islands, https://docs.microsoft.com/en-us/windows/apps/desktop/modernize/using-the-xaml-hosting-api https://docs.microsoft.com/en-us/windows/apps/desktop/modern...
awestroke 7y ago
https://github.com/maps4print/azul https://github.com/maps4print/azul
rpeden 7y ago
Microsoft very actively works on React Native for Windows, and last I checked there were decent RN desktop ports for Linux and MacOS. So that's one potential option.
- pjmlp 7y ago
  Given that they were even measuring the performance against Electron, there is some small hope that eventually VSCode gets rewritten in it.
  - Const-me 7y ago
    I don't think they care about performance a tiny bit. Here's very simple to implement change which saves dozens of MB of IO bandwidth every startup: https://github.com/Microsoft/vscode/issues/61343 https://github.com/Microsoft/vscode/issues/61343 "We will very likely not do this."
    - pjmlp 7y ago
      Then check BUILD 2019 talk about React Native for Windows. Electron gets a couple of jabs, including a very nice bar comparison chart.
ubercow13 7y ago
Maybe https://github.com/revery-ui/revery/blob/master/README.md https://github.com/revery-ui/revery/blob/master/README.md
robto 7y ago
I know about revery[0] and cljfx[0], though I haven't had the chance to use them in anger. These both seem like very nice approaches to me - I'm partial to cljfx because I've been utterly spoiled by the clojure/script development experience, but I've also come to enjoy the typescript environment and revery seems to another step along that road. [0]https://github.com/revery-ui/revery https://github.com/revery-ui/revery [1]https://github.com/cljfx/cljfx https://github.com/cljfx/cljfx
- geokon 7y ago
  Be sure to also check out fn-fx. I've tried both but haven't really done anything complex enough to bring out which one is a clear winner https://github.com/fn-fx/fn-fx https://github.com/fn-fx/fn-fx Fn-fx is a more complex beast and no one seems to really know how it all works internally except the creator who isn't maintaining it.. so unfortunately it's in a semi unmaintained state. But the interface was a bit cleaner when I tried it
  - robto 7y ago
    cljfx is actually inspired on fn-fx, and presents a much cleaner and more usable api, just by comparing the docs. I'm pretty sold on data-based apis instead of macro-based ones, though, so maybe it's just catering towards my preferred style of development.
    - geokon 7y ago
      oh okay. you sound more knowledgeable than me, so thanks for the input. I'll stick to cljfx then. I found it clunkier to mix with Java code, so I was considering switching back to fn-fx
kbumsik 7y ago
Actually reactivity in GUI (maybe declarative GUI programming is a more accurate form?) is also "the old way" in the GUI development. I mean it is already done a decade ago, even before react. Try QML. The view is automatically updated when a signal is triggered or its state changes. You will notice that it is surprisingly simpler than React. React got so popular because React implemented it very nicely in the web browsers, not because it brought new concepts.
- sunebeck 7y ago
  Oh, I see - I take my comment back then :-)
- realharo 7y ago
  Last time I looked at QML (a few years ago), you couldn't just use any data in your UI directly, you had to wrap it in clunky models. When using C++, looks like you have to use things like QAbstractListModel https://qmlbook.github.io/ch16-qtcpp/qtcpp.html#a-simple-model https://qmlbook.github.io/ch16-qtcpp/qtcpp.html#a-simple-mod... Even without C++, there are things like ListModel and ListElement https://qmlbook.github.io/ch07-modelview/modelview.html https://qmlbook.github.io/ch07-modelview/modelview.html This is a far cry from React where you just use language-native data structures directly (you only need to do mutations in specific ways). As far as I can tell, you also can't just use native language constructs like functions/ifs/.map, etc. to compose the UI elements. Instead you have containers like Repeater. It seems very different to me compared to React, like built around a significantly different philosophy.
  - asveikau 7y ago
    Your comment seems to just be highlighting the fact that inspecting types at runtime is non-idiomatic at best in C++ or similar languages, so it would make sense to require a specific data structure or format. Even defining what a "native" type is seems like it would be fraught. I guess the c++ way would be to accept begin and end iterators - but of what type?
    - 7y ago
floatboth 7y ago
https://github.com/antoyo/relm https://github.com/antoyo/relm
FreezerburnV 7y ago
JavaFX actually has a lot of reactive elements in its design. Basically every attribute of any GUI element are an “observable” type which allow you to register handlers for doing stuff when the internal value changes.
- walkingolof 7y ago
  JavaFX is great and looks fantastic, surprised it’s not used more
  - FreezerburnV 7y ago
    There seems to be a perception that anything running on the JVM is going to be slow and look bad. Considering I work with Java every day in a gigantic Swing application, (IntelliJ IDEA, if you didn’t guess) and it has great performance for all the things it’s doing for me, that seems to be an old holdover from early days of Java. Also enterprise apps, which of course are going to be bad and slow. At least the JVM has real threads for background work which don’t take another 100MB of RAM like an electron background worker :)
    - walkingolof 7y ago
      Yea, its hard to wash out a stain like that, in general, JIT:d JVM based applications performs as good or better than AOT application, but do still need more memory.
      - FreezerburnV 7y ago
        The “or better” tagged into JVM applications really needs to go away. Realistically, most JVM applications do not have as good performance as native ones. Yes, it’s possible to run better, but it’s very hard to create code that JITs to something faster than a thing written in C/C++/Rust/etc. You have to basically write code that looks like C to make it run as fast or faster, because there’s real overhead that comes with a lot of things in the JVM. You don’t just write standard Java or Scala and suddenly it’s as fast as C++, in general. It’s still heckin blazing fast, to be fair, but not AS heckin blazing fast. (As long as you aren’t just going insane with objects, at least, such as huge lists of integer objects)
pjmlp 7y ago
Yes, about 10 years ago with WPF, QML, JavaFX.
- fasterdom 7y ago
  I've used WPF extensively 10 years ago. It's nowhere near as easy to create a complex GUI as Vue/HTML/CSS. And that just for functionality. If we talk about looks, WPF is very clunky to theme.
  - turrini 7y ago
    There is QML and it can compile natively for many platforms. With the same source code, my applications are natively compiled to: Linux, Windows, MacOS, Android, iOS, QNX, Browser (WebAssembly / WebGL Streaming) And you are free to theme it as you like, one example: https://imgur.com/Ti02n6Y https://imgur.com/Ti02n6Y
  - pjmlp 7y ago
    I happen to have the opposite view, specially with Blend and component libraries into the mix. CSS had to get WPF grid design in order to not be a poor table sibling in what concerns layouts. While WPF is backed by DirectX, CSS requires playing with Z order, so that some browsers might eventually put the rendering into the GPU, but one needs to take care because space is limited. While I can render anything down to pixel level control, if I wish to do so, I am still waiting for Houdini and worlets to actually become available. And the whole template language with events and theming for low level customisation of control behaviours? Nowhere to be seen.
    - fasterdom 7y ago
      Using Blend feels to me like using Word to create HTML pages - the resulting output is horrible. CSS layout was indeed a struggle many years ago, but now with flexbox I never failed to put stuff exactly where I wanted, and I barely understand it. And the new shiny thing, CSS Grid, is supposedly even better at controlling layout.
  - 7y ago
c-smile 7y ago
Sciter ( https://sciter.com https://sciter.com ) and Sciter/Rust for that matter: https://github.com/sciter-sdk/rust-sciter https://github.com/sciter-sdk/rust-sciter It adds single 5mb DLL to the equation. Yet it allows to build native applications where UI structure is defined by HTML, style by CSS and reactivity by script or by Rust (or by C++, Go, Python, etc.) "Sciter makes GUI programming genuinely fun!" https://sciter.com/forums/topic/attach-detach-behavior/#post-61347 https://sciter.com/forums/topic/attach-detach-behavior/#post...
- amelius 7y ago
  What HTML/CSS rendering engine does it use? And in case it has its own implementation, then how good and up to date is the HTML/CSS support?
  - c-smile 7y ago
    It uses its own HTML/CSS engine designed by myself to be embeddable from ground up. Check this: https://sciter.com/10-years-road-to-sciter/ https://sciter.com/10-years-road-to-sciter/ As of HTML: most of HTML5 constructs (I participated in HTML5 spec development at W3C as Invited Expert) As of CSS: CSS2.1 in full. Some practically useful modules of CSS3 - transitions, transforms, etc. I haven't added FlexBox as I think it is an architectural disaster - will not survive on the long run. Instead Sciter offers "flow and flex units" module: https://sciter.com/docs/flex-flow/flex-layout.htm https://sciter.com/docs/flex-flow/flex-layout.htm that covers as FlexBox as Grid in unified manner. Yet check this: https://terrainformatica.com/w3/flex-layout/flex-vs-flexbox.htm https://terrainformatica.com/w3/flex-layout/flex-vs-flexbox.... Yet, I've added quite a lot of HTML/CSS features that are the must for specifically desktop UI: - <menu class=popup> and <popup> elements and their CSS support - windowed DOM elements that are rendered outside of main window canvas. - <frame type=pager> - print preview and print feature. - view.dialog("some.html"), view.window("some.html"), view.msgbox("some.html") - HTML defined windows and dialogs. - <htmlarea> - native WYSIWYG HTML editing widget. More on this: https://sciter.com/developers/for-web-programmers/ https://sciter.com/developers/for-web-programmers/
    - 7y ago
voodootrucker 7y ago
See this [0] native UI for Rust. It's the primary UI for Redox OS and it's inspired by React. [0] https://github.com/redox-os/orbtk https://github.com/redox-os/orbtk
matthewmacleod 7y ago
Swift is going this way with SwiftUI but you aren’t likely to see it anywhere except Apple platforms in the immediate future.
edwinyzh 7y ago
https://github.com/pierrejean-coudert/ReduxDelphi https://github.com/pierrejean-coudert/ReduxDelphi
tomjen3 7y ago
Microsoft. Their XAML apps are pretty much web apps done right, ie not javascript and a more powerful layout system -- and everything on the gui part is reactive.
ivanceras 7y ago
Yes, I am. https://twitter.com/ivanceras/status/1147594007897202688 https://twitter.com/ivanceras/status/1147594007897202688

chronogram 7y ago

This is actually a really useful walkthrough. With so many options and things out there, it’s great to have a step by step walkthrough of a project. No idea why anyone would want to do this, because it seems you’ll be hated by half the Linux users for using gtk, but seems cool for personal projects.

ubercow13 7y ago
Is there a choice which won't leave you hated by half of Linux users?
- chronogram 7y ago
  The approach I take, which is to never even interact with them and just keep my projects to friends and myself. I do submit pull requests to upstream projects I use if they’re on GitHub!
- pmarin 7y ago
  Separate UI code from the logic code.
- pjmlp 7y ago
  Yes, focus on full stack desktop OSes and get hated from all of them instead. /s Due to desktop Linux fragmentation you will never please everyone, but everyone will feel entitled that your care about their snowflake distribution.
- simion314 7y ago
  Use Electron, then everyone on all OSes will hate your application. /s I did not see people asking for GTK apps to be ported to Qt (if it happens is much lower then the rewrite it in rust phenomenon) , there were a number of projects that switched from GTK2 to Qt instead of GTK3 because they re-evaluated the toolkits and decided Qt was better for those projects.
  - jancsika 7y ago
    > Use Electron, then everyone on all OSes will hate your application. /s Actually this is a real benefit. It means no one will show up and convince people on your project to waste time packaging your software for [pick a Linux Distribution]. Now instead of getting user reports from a hall of mirrors of various packages for various distros with various states of dependency disrepair, you've got one central source of truth.

dijit 7y ago

I tend to prefer Qt as an end user, are there similar tutorials for Qt+Rust? I remember someone telling me that it’s not as good a fit but I can’t remember why that is.

hdfbdtbcdg 7y ago
As a guess it is probably because GTK has a C API whilst Qt is C++.
simion314 7y ago
GTK is a C toolkit and Qt is C++, it is easier for other languages to use GTK if those languages have a way to interact with C library. There are a lot of bindings to GTK and very few to Qt.
- dijit 7y ago
  That explains a lot. Thank you. :)
- pknopf 7y ago
  https://github.com/qmlnet/qmlnet https://github.com/qmlnet/qmlnet
  - simion314 7y ago
    There were C# Qt bindings since many years ago but those were not official supported so the quality was not that good,once there was a Java official binding/port that was dropped after a short time, I would not use someone's hobby bindings for a real world project(I mean a project with many users that you need to support for years , through OS and oteher system updates)
    - pknopf 7y ago
      I'm the author. The QtSharp project used technology that couldn't really address the problem (MonoCppSharp). QML.Net is different. It is purely a QML integration (no c++ wrapper), using a C interop. There is extensive unit tests for QML.Net, including garbage collection tests. I consider it segfault-proof. It's currently used in production on embedded medical devices: https://medxchange.com/4klear-all-in-one-camera-recorder/ https://medxchange.com/4klear-all-in-one-camera-recorder/

bayesian_horse 7y ago

I think the major benefit of a native/compiled language like C or Rust over interpreted/JIT ones like Python or Javascript for desktop applications is the overhead in terms of distribution size and memory consumption. Speed doesn't come into it that much. Current desktop systems are fast enough such that most GUI manipulation just isn't a speed bottleneck, except for things like realtime graphics or something.

jasonhansel 7y ago
What I really wish is that these Electron apps could share a common instance of Chromium. That would help the memory consumption issue a lot, but I'm not sure how to implement it best.
- GhostVII 7y ago
  Couldn't they just run like a regular website, except be available offline? Then you could just open it up in your browser, so only one instance of Chrome/Firefox is used. Not sure how hard it would be to allow electron apps to run like that, but it seems like they are basically just websites as it is, given that they run on Chromium, maybe it would be harder for them to work with the OS filesystem though. For the electron apps I use, they are generally available online as a website anyways, so I just use that, and get the whole common instance thing for free.
  - kryptiskt 7y ago
    Electron apps have unfettered access to the system (through node.js), they aren't just webpages.
  - pcr910303 7y ago
    Well, Electron is essentially a server and chromium, so there should also be a way to execute nodejs code inside the browser then... which would break sandboxing. I think this isn’t really a problem of Electron, but more to Chromium. We bundle python inside the binary and it’s fine. I don’t think I’ll hate command line programs that embed nodejs inside the binary. It’s the Chromium that’s problematic, and just by switching Chromium to the native WebView will make Electron apps much, much more lightweight.

deleted 7y ago

[deleted]

danielscrubs 7y ago

Isn't the problem that users don't want the eye-candy of 1995, but the one of 2019 and therefore we don't have any choice but to bundle a browser and use JS if we want users? There is a heavy focus on transition animations, fonts, media query breakpoints and drag and drop. It's kind of embarrassing (or a testament to hard of a problem that it is) the state we are in because of (IMO) Microsoft/Apple/Canonical. If they had a really, really good GUI foundation, it'd be a quick job to do a minimal Slack or Things for macOS clone in C++/Rust. Edit: Seems people get irritated about what the users want. But that's not really up to us to decide as coders...

otabdeveloper4 7y ago
No. Everyone hates web UI's, including users and programmers. But we need them because they're the only cross-platform and device-independent solution.
- AnIdiotOnTheNet 7y ago
  That's not true though, they only work on one platform: the web browser, and often they only work well on one specific browser. If you're going to allow a runtime as bloated and complicated as a web browser to count as "cross platform" then you'll have to admit that Java met those same criteria 2 decades ago.
  - otabdeveloper4 7y ago
    A web browser has been ported to literally every platform that has a screen. Java doesn't even come pre-installed on a normal machine. It's not about technical considerations, it's just that one cross-platform runtime has won.
kbumsik 7y ago
> because of (IMO) Microsoft/Apple/Canonical. > If they had a really, really good GUI foundation. It is not true at all. They already have really nice GUI foundations. Brining the web tech to desktop apps gots so popular because the web is won so that devs are forced to make web apps, not because it is better than the "traditional" GUI development.

aarroyoc 7y ago

I tried this and is awful. GTK and Rust have two very different ways of managing memory and it's painful. Lucky, gtk-rs already helps you with their own types prepared to be used with Rc but with your custom types you need to define all the garbage collector stuff your yourself which makes the code look very ugly (lots of clone, which aren't really clones). At the end the result is good, but the code looks awful.

spystath 7y ago
My experience is kind of similar. Unfortunately the way Rust interacts with memory is quite different from how Gtk does (and most GUI tool-kits to be fair). The end result is a kind-of awkward battle between the Rust borrow checker and the internal memory handling of Gtk+ leading to loads of Rc<RefCell<T>>. This makes also quite hard to implement custom Widgets in an intuitive way. In Python or C++ you would subclass the generic "Widget" class and start implementing the bits you need. With Rust things are slightly complicated; you can't just implement the IsA<Widget> trait and call it a day; at least not a straightforward way. Hopefully gnome-class [0] will probably solve this problem eventually. That being said it's been a while since I've used gtk-rs so it is entirely possible things have changed. I'd love to be corrected if that's the case :) [0] https://gitlab.gnome.org/federico/gnome-class/ https://gitlab.gnome.org/federico/gnome-class/
duguxu 7y ago
I have kept an eye on this for a long time. Is there any design pattern with Rust style (no unsafe and not ugly from Rust community's perspective) that proved in prototype to be able to achieve the same scaling of performance and memory usage as native C/C++ GUI framework with more complicated interface (e.g. Office)? Could this be an inherent limit of Rust because of the memory safety principle?
- pcwalton 7y ago
  I would like to see an ECS style UI design in Rust that represents widgets as IDs, to allow arbitrary object graphs without interior mutability. I don't see a reason why this would be incompatible with GTK, but we won't know until we try. It might work out really well. It also might be that Rust is not the right language to write high level UI logic in at this time, and a GC'd language would be more appropriate. That's fine too. One of the strengths of Rust is its interoperability with other languages. C and C++ are certainly not the right languages to implement high level UI logic in, for example.