39 ms·

Writing Gnome Apps with Swift

552 points by msk-lywenn 3y ago

koito17 3y ago
Something like SwiftUI but open source and targeting GTK4 would be pretty close to my "dream framework" for cross-platform desktop UI. I will admit, Swift syntax is an acquired taste, but once you're familiar with all of the concepts (and understand that some design decisions were made for Objective-C interoperability), then it's a very usable language. To be frank, the only thing that stops me from using Swift is the fact that Linux support isn't as good as on Apple platforms. But if I am targeting nothing but Apple platforms, then Swift is probably the best choice, just for SwiftUI and SPM alone.
- rubymamis 3y ago
  Why not go with Qt's QML?
  - wizzledonker 3y ago
    As someone who works with QML daily, I had the same question. The work is already done. Why write a common UI backend in swift when you can have the whole thing common using QML/Qt. It’s the best way to write native Multiplatform apps at the moment. It just is.
    - dhosek 3y ago
      I’m not entirely convinced that multiplatform UI is a good idea for anything other than the simplest of applications. It always ends up looking out of place on at least one platform and sometimes all of them.
      - rubymamis 3y ago
        It just takes an effort to make Qt apps look and behave native. This has been one of the goals with my new note-taking app, and I think it looks pretty native (at least on macOS): https://www.get-plume.com/ https://www.get-plume.com/
        mike_ivanov 3y ago
        Looks gorgeous. Is it QML or pure Qt?
        rubymamis 3y ago
        Thanks! It’s both. The model side and logic is written in C++ while the view is written in QML. That way I get the best of both worlds, the performance of C++ with the ease of use, flexibility, animations, etc of QML. It’s worth noting that most Qt Quick components and much of QML code is compiled to C++, so even code on that side is performant.
        mike_ivanov 3y ago
        Amazing. This is very inspiring, thanks.
        ezst 3y ago
        Hey, I don't use your app because it's too limited for my "PKMS" needs (I use trilium notes instead), but I appreciate that you make being "native and fast" a distinguishing feature (vs all the other electron based alternatives boiling the oceans).
        rubymamis 3y ago
        Thanks for the feedback, although the app isn’t released yet so you should at least give it a shot once it’s out. I do try to strike a balance between flexibility and ease of use. I think Notion is too complicated (yet very flexible/powerful). With Plume, the focus is to be able to organize your thoughts in a powerful way, effortlessly. Sign up to the waitlist and try it once it’s out. Much more is coming soon.
        ezst 3y ago
        > I think Notion is too complicated I wrote about the problem space extensively on this site before, tl;dr, to me the issue lies in the fact that most of the contenders aim to manage data/knowledge/notes as "types" (for categorization, templating and derivation/re-purposing), but, to my knowledge, only trilium is enabling that with a "sound" design. Notion is exposing a lot of incidental complexity due to its "unsoundness".
    - aplummer 3y ago
      It just is is a relative term, for example - I already know SwiftUI.
    - pona-a 3y ago
      For me, QML, while expressive, had a lot of rough edges. If most of your logic is inside the C++ backend, its JS engine is just useless overhead. If you do something like lite data wrangling in QML, or worse, try to adapt existing JS libraries for it, it quickly becomes a nightmare of standard JS weirdness, non-compliance with normal JS, and just outright ridiculous and difficult to diagnose issues like data getting passed by reference from the previous page and that page getting popped off the stack, resulting in error. And besides that, QML tooling is virtually non-existent. Major code editors don't even ship basic syntax highlighting for it out-of-the-box, the linter doesn't catch anything useful forcing you back into manual testing, and recently added language-server is at best a little useless and at worst impossible to get working correctly because your components live inside the build container and cannot be installed on the host without risk to system stability (Ubuntu Touch Clickable and Lomiri.Components). If something like that was possible for Qt, I'd probably switch in a heartbeat. If our modern programing languages are finally expressive enough to write sane reactive UI and statically verify parts of your logic, why keep relying on the unverifiable and slow DSL?
      - rubymamis 3y ago
        > If most of your logic is inside the C++ backend, its JS engine is just useless overhead. Well, if most of your logic in C++, what's the problem then? For my app[1] most of the logic in C++ but there's still a good amount of logic in JS (out of laziness or ease). BTW, much of QML code is compiled to C++ these days[2] > difficult to diagnose issues like data getting passed by reference from the previous page and that page getting popped off the stack, resulting in error. This is very true, it's quite difficult to diagnose issues in QML, and it doesn't seem to me like Qt ships debugger tools for errors as available for C++ when a program crashes. I relate to your issues with syntax highlighting (although the linter is good imo). Also auto-complete is pretty bad in Qt Creator for QML. I wonder how feasible it is to integrate Typescript into QML rather than JS. But I think that while all these issues should be addressed, developing with C++ and QML is the most joyful combination I've experienced so far for GUI development (I also developed in React and React Native). [1] https://www.get-plume.com/ https://www.get-plume.com/ [2] https://www.qt.io/blog/the-new-qtquick-compiler-technology https://www.qt.io/blog/the-new-qtquick-compiler-technology
  - dheera 3y ago
    I hate Qt, the apps look non-native and don't obey Ubuntu's appearance settings and fonts.
    - dartharva 3y ago
      Nobody bats an eye when apps built for Windows don't adhere to its design patterns. Some goes to a large extent for MacOS. I swear Linux users have the strangest obsessions..
      - dheera 3y ago
        I mean, most Windows UIs look like shit, they look like something that would be at a DMV. We Linux users do like our desktops to be sleek, badass, and sci-fi ...
      - eitland 3y ago
        Mac users are worse than ordinary Linux users I think (writing this as a Linux user who right now uses a Mac :-) As an ordinary Linux user I at least welcome all applications with bonus points if they are well integrated into KDE. Maybe the Gnome crowd is more picky?
        jwells89 3y ago
        Longtime mac users definitely have a preference for apps that are not only native, but designed to be good citizens of the mac desktop by abiding by its UI conventions, feature progressive disclosure of power user features, etc.
      - tcmart14 3y ago
        To be fair, even Microsoft isn't consistent on what people feel like native should look like. I'm primary a linux/mac user as home, but at work I have to use Windows 11. It is surprising that Microsoft gets paid the Windows given that the control panel has a new updated UI that meshes with Windows 11 fairly well, but then you open up something in control panel and need to access more advanced features and your greeted by a UI that I am pretty sure is from Vista or 7. A standard winforms UI looks totally different from a WinUI. Yes, technically they are all native, but they all look completely different.
- p10r 3y ago
  Sounds like Compose and Kotlin, although multiplatform still being more in a beta stage.
  - dkh 3y ago
    If I had a nickel for every time I got excited about something with experimental multiplatform support... The Kotlin platform looks good and I've kept an eye on it, but the problem is, if I have to start working on an app now, it's still kind of scary, as you're basically just placing a bet on a horse race of which one will mature the fastest down the road. At a previous job, I decided to adopt React Native in its early stages for a project. By some miracle (and with a lot of rolling-our-own) it managed to not hold us back and seemed to mature about as fast as we needed it to, but boy, even then it was still stressful, and I feel like we got a little lucky. (Just to be clear, I also knew this going into it and the choice was mine, I may just have a deathwish)
    - travisgriggs 3y ago
      We had a Kotlin app written with view bindings and the various other bits and pieces of Android app stack “no now this thing” detritus over the years. I hated it. I cut my teeth on 20 years of smalltalk, so it wasn’t even the “let’s hate on OO now” thing. It was just so much unfinished/inconstant things. We have been porting to Jetpack Compose, and I really like it. It’s still got some growing pains. We don’t use ViewModels, hardly any Flow stuff, just mutable states and render trees and I’ve been pretty pleased. What makes me happiest is that it’s much more consistent. I don’t feel like I’m in a line at the DMV anymore; “oh you need that, go stand in that line and learn that stack, then come back”. Like you, I’m extremely skeptical about the multiplatform siren. We tried it in Smalltalk land. The Java guys tried it and failed. I tried Flutter for a couple of apps, early testing iOS users were totally turned off (so fine for internal simple utility apps only). I would love it if someone really succeeded. We have 2 Swift UIKit apps I’ll have to convert to SwiftUI someday. So I will wish all that try well, but I’m not holding my breath at all. Having a “write once run everywhere” pitch is about the same as politicians who run on “change”. It always sells; it never really delivers.
- pojntfx 3y ago
  > Linux support isn't as good as on Apple platforms That's definitely still a problem for libraries etc., but thanks to very recent developments (see the article) at least getting your app to users is super simple thanks to the new Swift Flatpak runtime: https://flathub.org/apps/org.freedesktop.Sdk.Extension.swift5 https://flathub.org/apps/org.freedesktop.Sdk.Extension.swift...
  - cglong 3y ago
    It says the runtime is under GPL3. Does the copyleft apply to all Flatpak apps written using Swift?
    - nextaccountic 3y ago
      I thought that Apple actively avoided GPLv3
      - cglong 3y ago
        It looks like the runtime is owned by the author of this article, who (from his bio) doesn't seem to be affiliated with Apple. Either way, I agree it seems like an odd choice.
      - rock_artist 3y ago
        a. It's the author using something which is GPL b. GPL is allowed as long as complied. c. GPL mostly limits ability for use within iOS / AppStore.
    - flexagoon 3y ago
      No, it is the runtime, it's not a part of your app, it just runs it. You can basically think of it as a Docker container (but specifically for desktop apps). You don't have to make your app GPL, the same way as you can run a proprietary app on Linux even though the Linux kernel is GPL
      - badsectoracula 3y ago
- dkh 3y ago
  I remember a few years ago, a few really cool cross-platform UI libraries were starting to emerge such as libui [0] that got me excited. I've kind of lost track of them since then (libui itself went dormant for a while before this fork) so I am not sure how mature/useful they are now, but the potential for writing native desktop UIs in basically any language seemed like an absolute dream. Perhaps it's feasible for very basic things? [0] https://github.com/libui-ng/libui-ng https://github.com/libui-ng/libui-ng
- loic-sharma 3y ago
  Flutter Linux targets GTK3 and is currently investigating a GTK4 migration. Flutter also supports Windows and macOS.
  - PlutoIsAPlanet 3y ago
    But it doesn't use GTK widgets, it just uses GTK to make a window. That said GTK on Windows and macOS is very meh. You don't choose GTK for making a cross platform app.
    - treyd 3y ago
      Deluge and Transmission are good cross platform GTK apps.
      - IshKebab 3y ago
        Evidentially it is possible to make GTK apps work at least somewhat nicely on Windows and Mac since there are a few out there. But it's clearly a ton of work. If you just make a standard GTK app it will be terrible. Most toolkits (e.g. Qt or even Flutter) work much nicer without having to fix them.
      - sirwhinesalot 3y ago
        Transmission only uses GTK on linux.
        abrouwers 3y ago
        There is a Qt and CLI client, too.
        seabrookmx 3y ago
        And a web UI! (My preferred method as I run it on my home server)
      - chungy 3y ago
- nicoburns 3y ago
  There is Relm (https://relm4.org/ https://relm4.org/). Which is in Rust is just GTK (through it's Rust bindings) with a nice reactivity layer on top.
- firecall 3y ago
  FWIW I very much enjoyed using SwiftUI once I got the hang of it! I'd been out of iOS dev for a good long while, and was still thinking in UIKit and Obj-C. Overall I've found SwiftUI to be the most productive and enjoyable declarative framework and developer experience I've used! To be fair my experience is limited to React and Flutter, but still, Apple have done a rather excellent job IMHO! YMMV :-)
  - mojuba 3y ago
    Rewriting an app from UIKit to SwiftUI not only eliminates storyboards but also reduces the code base. So once again: you have code plus storyboard XML vs. just code that is smaller! My jaw dropped when I first discovered this while rewriting something. Unfortunately though SwiftUI hasn't completely matured yet. Especially if you are targeting iOS versions prior to 16, you will encounter many of SwiftUI's shortcomings. Some (many?) UI components are still UIKit under the hood, scroll view and its derivatives are still not as flexible as you sometimes want them to be etc. For some custom UI tricks that would be a piece of cake in UIKit are impossible in SwiftUI and you often resort to wrapping the old components in your custom ones. Oh and don't get me started on resorting to the main thread (because of the underlying UIKit code) in the age of structured concurrency. All in all, the concept of SwiftUI coupled with structured concurrency is beyond amazing but its maturing process is still underway.
- dartharva 3y ago
  > targeting GTK4 > cross-platform ?? Do you know of any GTK4 app that runs well on non-Unix platforms?
imbnwa 3y ago
I’ve recently noticed Swift sneakily becoming an interesting option for desktop dev. On top of this example I’d add Arc for macOS and Windows.
- diggan 3y ago
  Will be interesting to see where it ends up, yeah :) > On top of this example I’d add Arc for macOS and Windows. Didn't development of Arc stop like a really long time ago? Anarki seems to be where development is at nowadays.
  - tunaoftheland 3y ago
    I believe the references to “arc” here and elsewhere in the thread is referring to the new web browser and not the Lisp-family language. There’s a GitHub link to a Swift ui bindings for Windows elsewhere by another poster here.
    - imbnwa 3y ago
      This is correct
  - imbnwa 3y ago
    Oh, I meant the Arc Browser[0]. Wraps Chromium with a Swift GUI layer [0]https://arc.net/ https://arc.net/
    - diggan 3y ago
      Oh yeah, in hindsight that makes perfect sense. Guess I've spent too much time on HN...
Apocryphon 3y ago
Flutter desktop app support has been on Ubuntu since 2021, but not sure if that ever got anywhere.
- robertlagrant 3y ago
  I quite enjoyed following a Flutter/Dart tutorial[0] a couple of years ago. Quite enjoyed the combo. If anyone fancies trying it, it's probably also the best tutorial I've ever seen. Really well structured and just the right amount of detail based on the place in the tutorial. [0] https://www.youtube.com/watch?v=1ukSR1GRtMU https://www.youtube.com/watch?v=1ukSR1GRtMU (video)
  - bcye 3y ago
    Top comment: "don't follow this tutorial [because it's outdated]" :(
    - robertlagrant 3y ago
      I don't see that one. There's one from 3 weeks ago that liked the course. I did do it years ago though, so it could be outdated now.
  - zogrodea 3y ago
    I had to use Flutter and Dart for a job a couple of years back and found this video series an excellent guide when learning about them too. Would recommend to anyone looking to learn either too.
- fngjdflmdflg 3y ago
  Yes flutter works on Linux. In fact the Ubuntu installer/OOBE is written in Flutter.[0] Not sure how this is related to the OP though. [0] https://ubuntu.com/blog/how-we-designed-the-new-ubuntu-desktop-installer https://ubuntu.com/blog/how-we-designed-the-new-ubuntu-deskt...
- deleted 3y ago
  [deleted]
coldtea 3y ago
>The primary motivation for this package is to enable the use of Swift when writing GNOME apps, for all the reasons outlined above The only problem I have with such projects is when they are unmaintained, in various stages of immaturity, and have little adoption (vicious circle). You find them, they promise exactly what you need, and then you fell into issue after issue in practical use (*). It would be amazing if there was (perhaps this is or will be) well maintained bindings for Swift/Rust/Go and co for Gnome. * Yes, it's open source and you can fix some of the issues yourself. Doesn't mean you have the know-how or time to fix all of them, especially when there are lots of things to fix or features missing. Ideally a big community must exist, so that each can just work on or fix a small part and the problem still get lots of fixes/improvements incoming, as opposed to "fully replace the single overworked maintainer yourself".
- dkh 3y ago
  This. Over the years I've seen so many cool projects aiming to ease native desktop UI development, but most became unmaintained at some point, for what I am guessing is due to the difficulty and complexity associated with actually making this work in practice. It is less sexy, but a solid language binding to the existing libraries is likely the more practical and maintainable way to go
  - MBCook 3y ago
    After so many years of seeing cross platform stuff come and go I can’t help but think it can’t be done well enough for mass adoption. It just has too many gotchas that make things feel out of place on every platform in different ways. At least outside my first demo app territory. The only thing that really seems to be succeeding is web stuff like Electron, which usually throws the baby out with the bathwater and does its own thing of emulating the web (itself, basically) instead of trying to feel perfectly native.
    - jcelerier 3y ago
      Idk I've been developing with Qt for idk, 15 years now, it's stable and keeps chugging along with constant improvements. And is used in more than enough mass-adopted apps, e.g. Telegram
eptcyka 3y ago
Is there a language server for Swift that does not suck? I believe swift is a good language, however its ecosystem being steered by apple is a massive red flag. It also suffers a bit from being a commercially developed language in that its developers are clearly incentivized to add more features.
- georgelyon 3y ago
  sourcekit-lsp works really well, VSCode integration is solid[1]. I've been using VSCode+dev-containers+sourcekit-lsp for a couple years now for Linux development on macOS and it has been really nice. I agree that this is a must-have for idiomatic Swift. It is really hard to write the long-named-functions and get all the variable names correct without reasonable autocomplete. [1]: https://www.swift.org/blog/vscode-extension/ https://www.swift.org/blog/vscode-extension/
  - jwells89 3y ago
    VS Code isn’t too bad, it after ~20 years of Xcode/Project Builder, muscle memory for keybinds and UI in general is strong. Hoping that someone uses the LSP to write a cross platform “Xcode Lite” or something along those lines.
    - georgelyon 3y ago
      It wasn't too bad to switch for me, but the problem is going back and forth. I don't love over-customizing my IDE but I've created my own keybindings for the commands I mis-type most (Command-R to run being the main culprit). Both Xcode and VSCode support custom key bindings and this isn't something that the LSP is responsible. UI is a different matter. Xcode is still miles ahead in performance tooling.
  - cmrdporcupine 3y ago
    I was curious and noticed that this looks reasonable: https://github.com/emacs-lsp/lsp-sourcekit https://github.com/emacs-lsp/lsp-sourcekit Emacs + lsp-mode + sourcekit + company-mode etc looks reasonably close to what I get with Rust in Emacs. If I were doing application development I'd maybe consider Swift.
l72 3y ago
I recently wrote a small side project using vala + gtk4. I tried blueprint, and while I liked the format, I struggled with a lack of documentation on how to do some more advanced things. Gtk's .ui files are ok, but you still end up writing a lot of code to hook everything up. While I really like vala as a language, I think it'd be great to write all my logic and models in vala, then use this swift library for the UI.
- RussianCow 3y ago
  > While I really like vala as a language, I think it'd be great to write all my logic and models in vala, then use this swift library for the UI. At that point, why not just do everything in Swift? What does Vala give you that Swift doesn't?
  - dkh 3y ago
    In the context of Gnome/GTK development, there's almost nothing more stable and comprehensive than Vala, as it's been around a very long time and was created specifically to occupy that space. Can't speak for OP about why to combine it with Swift handling the UI, but certainly Vala still has far better support for the Gnome data model and APIs outside of those specific to the GUI.
    - RussianCow 3y ago
      I get that, but if you're going to deal with the impedance mismatch anyway, I would just go all in and use Swift for everything. But I guess that's assuming that GTK/GLib is fairly easy to wrap in a language like Swift, which I assume is true given all the different language bindings out there.
      - badsectoracula 3y ago
        I think a difference between Vala and everything else is that Vala has been written with gobject as its "native" object system whereas everything else uses the glib bindings. Kinda like using COM from Visual Basic 6 vs using it from plain C.
worik 3y ago
I spent 3-years with Swift recently Makes me want to ask: Why? Why do this? It is a decent language for 2005. But it has some serious shortcomings (reference counting garbage collector? Really?) The worst thing IMO is its dreadful support for threads. The "DispatchQueue" seems to be a wrapper around "fork/renice". There is no attempt at memory protection. But it is full of little niggles that get very irritating in this day and age. I never used Objective-C so it may be a vast improvement on that. It is no longer 2005, and we deserve, and we have, better languages. My time as an Apple developer left me with the overwhelming sensation that Apple hates its developers. So much cool looking stuff that mostly worked...
- keyle 3y ago
  I'm not sure where you get your references from but Swift is one of the most modern and advanced languages out there. The documentation of Apple is worse than hot garbage though. As in, at least with hot garbage you have something.
  - developerDan 3y ago
    What do you mean? Apple has lots and lots of documentation saying that function signatures exist! (/s just in case)
  - tcmart14 3y ago
    I've gotten better at navigating the Apple docs, but yea, they are not the best. The one thing I will say, when they give code snippets in their docs, the code snippets are really good. But you just need to read the API of a framework or see the functions tied to a type, it could be a lot better.
- frizlab 3y ago
  ARC is for classes, structs use don’t have that and classes are heavily discouraged. DispatchQueue is anything but fork/renice. Also there is async/await now. GCD should be used for concurrent work only now, not async work. Memory protection is fully implemented in Swift 5.10, but compilation only warns, enabled by default as errors in Swift 6.
msie 3y ago
I always thought that introducing keys in function parameters was a mistake.
- frizlab 3y ago
  I disagree. It makes the code readable.
  - makeitdouble 3y ago
    It's still a tradeoff: in a previous team switching languages it openned the door to function with 5+ parameters, when that was highly throwned upon otherwise. It's a tool to help better manage complexity, and that naturally invites more complexity as well.
    - bigyikes 3y ago
      is that an issue of the language or of the team? adding additional names does not add additional complexity. complexity arises in interactions between components.
      - makeitdouble 3y ago
        I see it as mostly influenced by the language and tooling. From there, some people will be more attracted by one side or the other, but when moving stack you tend to follow the stack's natural incline. For instance ruby helps to have shorter, less verbose code, but with more hidden components. Rails rose from there, tooling tends to support that style. I've seen java devs moving to ruby and naturally writing less verbose code. In contract Java tooling makes it a lot more manageable to write 40 character long classes, deeper dependency trees and injections and potentially auto-generate half of the needed methods. The cost is low, and there's less incentive to fight that trend when tools help you abstract part of it.
        bigyikes 3y ago
        i agree but you discuss verbosity and not complexity
YmiYugy 3y ago
Has anyone been able to get this running on Mac. Followed the instructions, but I always get a missing adwaita.h in some shim.h
- axoltl 3y ago
  Adwaita is - I believe - closely tied to Gnome. SwiftUI (obviously) already has bindings for macOS’ window server. Not sure what this project gets you on macOS that you don’t already have?
- ankurdhama 3y ago
  You will need to install libadwaita. Try "brew install libadwaita"
jamilbk 3y ago
That's neat! But how is everyone testing their Swift codebases? We've found the story around testing to be... lacking. The [docs](https://developer.apple.com/documentation/xctest https://developer.apple.com/documentation/xctest) on the subject are pretty bare and don't offer strategies for mocks, stubs, reporting, code coverage, etc. And good luck if your app uses a Network Extension... those must be tested on a live physical device due to the signing restrictions! On that note, does anyone know of a good physical device CI service that supports both iOS and macOS devices?
- suraj 3y ago
  Take a look at https://github.com/apple/swift-testing https://github.com/apple/swift-testing It is under active development as Swift first replacement for xctest. For CI service, Xcode cloud does support running tests on mac and iOS hardware. https://developer.apple.com/xcode-cloud/ https://developer.apple.com/xcode-cloud/
  - plorkyeran 3y ago
    Xcode Cloud doesn’t actually support running tests on devices. Some of the marketing tries to imply that it does, but it’s simulators only.
QuantumG 3y ago
The article doesn't summarise the differences between developing these cross-platform apps vs only targetting Apple and that is the most important information really. Did I miss it?
- deleted 3y ago
  [deleted]
etaioinshrdlu 3y ago
I'm having Deja Vu from about 20 years ago of writing Gnome apps in C# using Mono.
- jddj 3y ago
  Oh wow, I forgot all about that little detour. I remember making some rudimentary accounting software for which I'm sure now the source is long gone.
- neonsunset 3y ago
  You still can! (even easier now since it will run on CoreCLR instead) https://www.nuget.org/packages/GtkSharp https://www.nuget.org/packages/GtkSharp
  - przmk 3y ago
    This only targets Gtk3 and not Gtk4 or libadwaita though. Seems a little end-of-life.
- pjmlp 3y ago
  Which ended up having such a community backslash that Miguel de Icaza decided to focus his efforts on Xamarin instead, followed by Microsoft's acquisition, and nowadays he is focused on Apple's ecosystem, Swift and Godot on Apple platforms. "Miguel de Icaza and his ostracization from FOSS" https://www.linux-magazine.com/Online/Blogs/Off-the-Beat-Bruce-Byfield-s-Blog/Miguel-de-Icaza-and-his-ostracization-from-FOSS https://www.linux-magazine.com/Online/Blogs/Off-the-Beat-Bru... "What killed the Linux Desktop" https://tirania.org/blog/archive/2012/Aug-29.html https://tirania.org/blog/archive/2012/Aug-29.html "How I ended up with a Mac" https://tirania.org/blog/archive/2013/Mar-05.html https://tirania.org/blog/archive/2013/Mar-05.html One might wonder how things would have turned out instead if the community had been more welcoming of his efforts on GNU/Linux.
  - masfoobar 3y ago
    While I found the MonoProject interesting, I was skeptical using it. Sure, it is an Open Source .NET framework but .NET is Microsoft at the end of the day. I do not (and still do not) want their fingerprints inside my GNU/Linux machine. What I mean by this is the legalities behind it. Remember, my comment above is based on views 20 years ago. My perspective is that Microsoft cannot "beat" Linux purely as competition. It isn't going anywhere. While it may not be a concern in the Desktop market, it certainly dominates on servers! Microsfot are not stupid and see CONTROL through other means. Imagine if most programs that come default in Linux distributions being C#? If more and more programs are written in C# (whether Mono or not) gives them power over the Linux user. Today, Microsoft has .NET core (recent release .NET 8) and also replaces Mono. We still have Xamarin of course but that is getting replaced with MAUI. A lot of Microsofts software is now cross platform, like Powershell, SQL Server, etc. This "concern" I was having 20 years ago is still just as big of an issue today. Imagine Microsoft getting the marketing right and SQL Server starts gaining momentum on Linux boxes. This means less using MySQL or Postgres. Imagine is Powershell starts gaining more traction in Linux land rather than Bash. Now -- I think this is EXTREMELY UNLIKELY to happen but you can garantuee this is a strategy. They have the money and manipulation skills to help make it happen. Big companies can easily eat this up and it starts with "but we can support you!" Think about it -- WSL is easy to setup on Windows machines! More and more C# applications can easily be tested for Linux. Microsoft just gave you the tools, and letting developers/companies do the rest for them. Soon it is sheep follow sheep. Bit of a long winded comment/reply - and while I do not share targeting hate towards anyone (I do not know Miguel personally but he seems like a cool guy) -- I just think efforts should have been elsewhere. Dlang could have been a really, really good replacement. My guess as to why Dlang didn't take off back them was the compiler was not open source. Who knows?
throw_m239339 3y ago
So, the elephant in room, what's the best way/framework today to write desktop apps for linux (no electron)?
- dzogchen 3y ago
  Qt of course, hands down.
- tkubacki 3y ago
  Flutter
- FireInsight 3y ago
  Imo libadwaita apps are the best, but I haven't found a perfect solution for writing them.
- earthnail 3y ago
  Qt (without QML). Has been around for ages and works beautifully. GTK is more complicated. I have no experience with libadwaita, but if in doubt I'd always go for Qt on Linux. It's stable, has great tooling and good documentation. And it hasn't changed much over the years, so most information you find - even on Qt 3 - is still mostly accurate today.
  - rubymamis 3y ago
    I would argue that Qt with QML is the best combo. See: https://news.ycombinator.com/item?id=39848069 https://news.ycombinator.com/item?id=39848069
    - earthnail 3y ago
      Love the idea of Plume; signed up to the mailing list. Btw the website layout breaks on very wide browsers (images in the .features-section overlap text). Maybe consider some max-width for the page. And I also have to say that my days with Qt are quite some time ago. I never really got into QML, so if you say that QML is a great choice I'd put more weight on your word than on mine.
lukeh 3y ago
Other things worth checking: https://github.com/stackotter/swift-cross-ui https://github.com/stackotter/swift-cross-ui https://github.com/TokamakUI/Tokamak https://github.com/TokamakUI/Tokamak I’m also working (slowly) on native Flutter channels: https://github.com/PADL/FlutterSwift https://github.com/PADL/FlutterSwift But this is really targeted at embedded use cases.
- dkh 3y ago
  TIL Sony maintains a Flutter eLinux embedder project[0] [0] https://github.com/sony/flutter-embedded-linux https://github.com/sony/flutter-embedded-linux
- marcprux 3y ago
  And there's also SwiftUI for Android: https://skip.tools/blog/bringing-swift-to-android/ https://skip.tools/blog/bringing-swift-to-android/
  - wahnfrieden 3y ago
    Very nice Do any of these have a good wkwebview equivalent
    - marcprux 3y ago
      Yes, web views (backed by WKWebView on iOS and android.webkit.WebView on Android) are one of the Skip modules under active development: https://github.com/skiptools/skip-web https://github.com/skiptools/skip-web
      - wahnfrieden 3y ago
        Looks amazing. As an indie dev who quit my job to try to make it solo, I'll either need to wait until I have more revenue to afford this, or hopefully you add some indie-friendly tier for bootstrapped pricing (such as a discount on team size, or ARR like Apple does with its small business program).
w10-1 3y ago
For another SwiftUI-like wrapper, see also https://github.com/stackotter/swift-cross-ui https://github.com/stackotter/swift-cross-ui (used by Adawaita to generate widgets, and mentioned in other comments). The key premise of this approach is to provide a SwiftUI-like declarative wrapper around Gnome functionality. It's unclear what it adds over swift-cross-ui. SwiftUI itself has growing pains mainly around being on the right thread for processing/updates and getting data binding right. Blog entries on swift.org or from Apple tend to be little demos that show the happy path, but when discussing new frameworks (like a Gnome wrapper) or platforms (like the recent embedded), I'd like more demonstration that the authors understand and address key issues and will sustain development. Cross-platform UI frameworks get complicated quickly and have a long tail of issues (cf Flutter, Java/Eclipse, et al) that can be blockers for clients/users. For Swift it doesn't help to have multiple concurrency models and obviously different behaviors on apple platforms and Linux (where UI is not officially tested).
- azinman2 3y ago
  I’ve never struggled with being on the right thread. It’s always main to update UI. Grand dispatch makes this trivial, and the recent actors work also extends this. I’m also not sure how this is SwiftUI specific as UIKit and most other UI frameworks are the same. What are the growing pains here?
  - w10-1 3y ago
    Aside from UI updates, processing includes view-model derivations (e.g., calculating errors), persistence, and loading, all of which are offloaded to dispatch queues or actors and then brought back to the UI/main thread. wrt granularity, there's @State, @StateObject, and @Observable, with different binding reaches. So understandably a lot of choices reflecting legacy and new API's, integration with UIKit and web/media services -- and probably AI recognizers in the background. To me the pains are that the approach taken needs to be consistent application-wide (async is pretty viral, queues are designed to be shared e.g., per subsystem, etc.), making it hard to manage or migrate a code base. Also many features build on macros which can make builds almost intolerable. Also saving on macOS vs integrating with update manager on iOS. It can be hard even to find documentation on stdlib feature support e.g., Regex. It's good they maintain both the legacy support and go full-steam-ahead on new features, but developers (i.e., I) need more guidance on tip-toeing around pitfalls and managing platform differences.
galina700 3y ago
[flagged]
accurrent 3y ago
How is the 3D story on gtk4 am I still stuck to opengl contexts?
iidaya00 3y ago
[flagged]
tschumacher 3y ago
I wonder where the pulse is with current GTK app development. I've noticed some of the newer core apps are in Rust like the new camera app and the image viewer, also the public transport app railway (not a core app afaik).
treprinum 3y ago
Writing UI code layouts is suboptimal in any language. Delphi had it right - place whatever controls you like in a GUI, set up basic behavior via properties, then just quickly write handlers in code.
- berkes 3y ago
  My immediate though of the Swift Example Code was "but where does the business logic go". This trivial example lacks it, and places it simple logic inside the UI code. But what if we want to protect against negative numbers? Or want to increase the number with larger increments if we hold the button pressed? Etc. Your Delphi setup isolates business logic from UI. Which may seem "overly complex" in trivial demoes, but will help you the very moment you write the first test or add some business logic. It's also why I see so many React apps spiral into an unmaintainable mess within days after their "git init".
  - diggan 3y ago
    > It's also why I see so many React apps spiral into an unmaintainable mess within days after their "git init". This is true for any library/framework/architecture, and the same problem is very prominent in Svelte/Vue/React/Backbone/Angular and everything else.
    - berkes 3y ago
      > and everything else. No. It's true for any library or framework that lack isolation or decoupling concepts. In react (and many of the ones you mention) there is nothing on place that guides you into decoupling. It has nothing, not even conventions, that help a junior to put stuff in the right place (or to prohibit or make it difficult to put stuff in the wrong place). Part of that is due to how in TS/JS everything can grope around in everything else. But the bigger part is lacking conventions, primitives and structure in the libs and frameworks. Sure, a library (which react is) doesn't provide structure (it's a distinguishing trait from frameworks). But the many frameworks on top of React don't do a good job either. They either become some Enterprise Ready amalgamation of saga's, redux, message-bus, setups, or they offer too little guidance. And in all situations, it's still possible to just fire a fetch() or put data transforms or business logic within the UI. Only discipline keeps people from taking this "much easier" route. And when only discipline stands between us and "the easier way for now", that "easier way for now" will be chosen, and pain in future will be felt.
codedokode 3y ago
I don't understand why there are so many negative comments. Writing GUI in C looks like a stone age programming, and people are simply wasting their time to do routine work that can be diminished by using another language. One might use Python, but it is slow and memory-hungry. Isn't it good that now there is an alternative to C?
- diggan 3y ago
  > Isn't it good that now there is an alternative to C? It's not exactly the first alternative, GJS (Gnome JavaScript) have existed for a long time and is also a C-like language, so doesn't seem this would give too much value compared to just using GJS, unless you know Swift a lot better than JavaScript but the languages are similar enough that even that doesn't provide much value. AFAIK, GJS is an official Gnome project too, so there will be a vast difference in ecosystem support compared to Gnome apps written in Swift, which I'm not sure is so popular outside of Apple circles.
  - codedokode 3y ago
    JavaScript is non static-typed and you'll spend time fixing bugs that can be prevented by static typing. Also, GJS is not well documented, as far as I remember.
    - diggan 3y ago
      > JavaScript is non static-typed and you'll spend time fixing bugs that can be prevented by static typing. Use TypeScript if types are so important for you. Others find their own way of handling those issues without getting tripped up on it. Hardly a reason to completely switch between two languages in my mind, but of course it's alright if it's reason enough for you. Luckily there are acceptable workarounds for both groups of people :) > Also, GJS is not well documented, as far as I remember. What exactly is missing here? There are guides for the basics, API reference exists and there is a ton of apps you can look into for inspiration and/or figure out specific implementations. Is that really worse than what exists for writing Gnome apps with Swift? Seems like a really weak argument for using Swift instead of GJS.
vi4m 3y ago
Really something we needed. Swift has such low memory usage, that it's an order of magnitude easier on resources, than those Electron wrappers. At the same time, it gives what you loved about React - expressiveness for UI. I wrote a lot of apps in SwiftUI, and it strikes a good balance between type safety and expressiveness, it's cool that we have something similar for GKT/Gnome now.
- deleted 3y ago
  [deleted]
FireInsight 3y ago
This is really cool! I love the JSX-like approach to UI and it's a shame it's not so common on desktop. https://github.com/can-lehmann/owlkettle https://github.com/can-lehmann/owlkettle is the only thing I find comparable.
- elcritch 3y ago
  And Nim is pretty handy for DSL approaches like that! I've never got to try SwiftUI stuff, but it looks great for desktop UIs.
pona-a 3y ago
That looks really nice! A healthy balance of reactive UI, expressiveness, and sanity. I wonder if there's a similar Swift binding for Qt... Ubuntu Touch and KDE could really benefit from that, as QML proved to be a total typing nightmare from my experience, often even slightly worse than regular JS thanks to its quirks...
keyle 3y ago
It's an interesting value proposition. But can I take my existing SwiftUI app and have a path towards porting them to Linux and windows? How foreign would they look since Apple's patterns aren't the same.
nickwarren 3y ago
Swift is such a delightful language to use, well suited for general application development. It's awesome to see it gaining traction outside of the cocoa ecosystem. If you haven't given it a fair chance yet, I would highly recommend you do!
Obertr 3y ago
I had an extremely negative experience creating apps in Swift. I can't see any logical reason why people would not use Electron/Tauri. Swift doesn't allow you to have full control of what you want to do. I built a whole macOS [ fixkey dot ai] app in Swift, and it was a very painful development experience.
- manmal 3y ago
  Were you new to Swift? It for sure has its issues, but lack of control wouldn’t make it on my list.
deleted 3y ago
[deleted]
nurettin 3y ago
You could say "writing Gtk code in X language where I implemented a DSL for this special case is easy!" in any PR piece. You could do it in Python using contextmanager which packs after adding the widget to HBox to save a line, you could do it in Ruby using do/end blocks, you could do it in C with the help of some pretty macros.
tripdout 3y ago
Is this the only declarative way to write desktop app UI? (Maybe Kaitlin multiplatform, but not sure how that works on Linux). I mean GTK/Qt
zengid 3y ago
I feel like a cross platform Swift GUI would be a great thing for the world. Swift strikes a great balance between ergonomics and performance, and seems to be the only other mainstream language to have absorbed some of Rust's key features around borrowing references.
- georgelyon 3y ago
  For the record, borrowed references are only going to be really usable in Swift 6 which isn't released yet. That said, Swift's implementation of borrowing seems significantly more user-friendly than Rust's. While this is very much an advanced feature, I'd expect it to be actually used in many cases where in Rust folks would resort to working around the borrow checking (via things like indexing into arrays and such). As a result I expect it to be significantly more useful.
- jrsj 3y ago
  Browser Company sort of built this themselves for Arc, but its really a separate SwiftUI-like Windows implementation (Windows UI is separate code written in a similar style). It still feels like a technical preview though unfortunately.

552 points by msk-lywenn 3y ago

Something like SwiftUI but open source and targeting GTK4 would be pretty close to my "dream framework" for cross-platform desktop UI. I will admit, Swift syntax is an acquired taste, but once you're familiar with all of the concepts (and understand that some design decisions were made for Objective-C interoperability), then it's a very usable language. To be frank, the only thing that stops me from using Swift is the fact that Linux support isn't as good as on Apple platforms. But if I am targeting nothing but Apple platforms, then Swift is probably the best choice, just for SwiftUI and SPM alone.

rubymamis 3y ago
Why not go with Qt's QML?
- wizzledonker 3y ago
  As someone who works with QML daily, I had the same question. The work is already done. Why write a common UI backend in swift when you can have the whole thing common using QML/Qt. It’s the best way to write native Multiplatform apps at the moment. It just is.
  - dhosek 3y ago
    I’m not entirely convinced that multiplatform UI is a good idea for anything other than the simplest of applications. It always ends up looking out of place on at least one platform and sometimes all of them.
    - rubymamis 3y ago
      It just takes an effort to make Qt apps look and behave native. This has been one of the goals with my new note-taking app, and I think it looks pretty native (at least on macOS): https://www.get-plume.com/ https://www.get-plume.com/
      - mike_ivanov 3y ago
        Looks gorgeous. Is it QML or pure Qt?
        rubymamis 3y ago
        Thanks! It’s both. The model side and logic is written in C++ while the view is written in QML. That way I get the best of both worlds, the performance of C++ with the ease of use, flexibility, animations, etc of QML. It’s worth noting that most Qt Quick components and much of QML code is compiled to C++, so even code on that side is performant.
        mike_ivanov 3y ago
        Amazing. This is very inspiring, thanks.
      - ezst 3y ago
        Hey, I don't use your app because it's too limited for my "PKMS" needs (I use trilium notes instead), but I appreciate that you make being "native and fast" a distinguishing feature (vs all the other electron based alternatives boiling the oceans).
        rubymamis 3y ago
        Thanks for the feedback, although the app isn’t released yet so you should at least give it a shot once it’s out. I do try to strike a balance between flexibility and ease of use. I think Notion is too complicated (yet very flexible/powerful). With Plume, the focus is to be able to organize your thoughts in a powerful way, effortlessly. Sign up to the waitlist and try it once it’s out. Much more is coming soon.
        ezst 3y ago
        > I think Notion is too complicated I wrote about the problem space extensively on this site before, tl;dr, to me the issue lies in the fact that most of the contenders aim to manage data/knowledge/notes as "types" (for categorization, templating and derivation/re-purposing), but, to my knowledge, only trilium is enabling that with a "sound" design. Notion is exposing a lot of incidental complexity due to its "unsoundness".
  - aplummer 3y ago
    It just is is a relative term, for example - I already know SwiftUI.
  - pona-a 3y ago
    For me, QML, while expressive, had a lot of rough edges. If most of your logic is inside the C++ backend, its JS engine is just useless overhead. If you do something like lite data wrangling in QML, or worse, try to adapt existing JS libraries for it, it quickly becomes a nightmare of standard JS weirdness, non-compliance with normal JS, and just outright ridiculous and difficult to diagnose issues like data getting passed by reference from the previous page and that page getting popped off the stack, resulting in error. And besides that, QML tooling is virtually non-existent. Major code editors don't even ship basic syntax highlighting for it out-of-the-box, the linter doesn't catch anything useful forcing you back into manual testing, and recently added language-server is at best a little useless and at worst impossible to get working correctly because your components live inside the build container and cannot be installed on the host without risk to system stability (Ubuntu Touch Clickable and Lomiri.Components). If something like that was possible for Qt, I'd probably switch in a heartbeat. If our modern programing languages are finally expressive enough to write sane reactive UI and statically verify parts of your logic, why keep relying on the unverifiable and slow DSL?
    - rubymamis 3y ago
      > If most of your logic is inside the C++ backend, its JS engine is just useless overhead. Well, if most of your logic in C++, what's the problem then? For my app[1] most of the logic in C++ but there's still a good amount of logic in JS (out of laziness or ease). BTW, much of QML code is compiled to C++ these days[2] > difficult to diagnose issues like data getting passed by reference from the previous page and that page getting popped off the stack, resulting in error. This is very true, it's quite difficult to diagnose issues in QML, and it doesn't seem to me like Qt ships debugger tools for errors as available for C++ when a program crashes. I relate to your issues with syntax highlighting (although the linter is good imo). Also auto-complete is pretty bad in Qt Creator for QML. I wonder how feasible it is to integrate Typescript into QML rather than JS. But I think that while all these issues should be addressed, developing with C++ and QML is the most joyful combination I've experienced so far for GUI development (I also developed in React and React Native). [1] https://www.get-plume.com/ https://www.get-plume.com/ [2] https://www.qt.io/blog/the-new-qtquick-compiler-technology https://www.qt.io/blog/the-new-qtquick-compiler-technology
- dheera 3y ago
  I hate Qt, the apps look non-native and don't obey Ubuntu's appearance settings and fonts.
  - dartharva 3y ago
    Nobody bats an eye when apps built for Windows don't adhere to its design patterns. Some goes to a large extent for MacOS. I swear Linux users have the strangest obsessions..
    - dheera 3y ago
      I mean, most Windows UIs look like shit, they look like something that would be at a DMV. We Linux users do like our desktops to be sleek, badass, and sci-fi ...
    - eitland 3y ago
      Mac users are worse than ordinary Linux users I think (writing this as a Linux user who right now uses a Mac :-) As an ordinary Linux user I at least welcome all applications with bonus points if they are well integrated into KDE. Maybe the Gnome crowd is more picky?
      - jwells89 3y ago
        Longtime mac users definitely have a preference for apps that are not only native, but designed to be good citizens of the mac desktop by abiding by its UI conventions, feature progressive disclosure of power user features, etc.
    - tcmart14 3y ago
      To be fair, even Microsoft isn't consistent on what people feel like native should look like. I'm primary a linux/mac user as home, but at work I have to use Windows 11. It is surprising that Microsoft gets paid the Windows given that the control panel has a new updated UI that meshes with Windows 11 fairly well, but then you open up something in control panel and need to access more advanced features and your greeted by a UI that I am pretty sure is from Vista or 7. A standard winforms UI looks totally different from a WinUI. Yes, technically they are all native, but they all look completely different.
p10r 3y ago
Sounds like Compose and Kotlin, although multiplatform still being more in a beta stage.
- dkh 3y ago
  If I had a nickel for every time I got excited about something with experimental multiplatform support... The Kotlin platform looks good and I've kept an eye on it, but the problem is, if I have to start working on an app now, it's still kind of scary, as you're basically just placing a bet on a horse race of which one will mature the fastest down the road. At a previous job, I decided to adopt React Native in its early stages for a project. By some miracle (and with a lot of rolling-our-own) it managed to not hold us back and seemed to mature about as fast as we needed it to, but boy, even then it was still stressful, and I feel like we got a little lucky. (Just to be clear, I also knew this going into it and the choice was mine, I may just have a deathwish)
  - travisgriggs 3y ago
    We had a Kotlin app written with view bindings and the various other bits and pieces of Android app stack “no now this thing” detritus over the years. I hated it. I cut my teeth on 20 years of smalltalk, so it wasn’t even the “let’s hate on OO now” thing. It was just so much unfinished/inconstant things. We have been porting to Jetpack Compose, and I really like it. It’s still got some growing pains. We don’t use ViewModels, hardly any Flow stuff, just mutable states and render trees and I’ve been pretty pleased. What makes me happiest is that it’s much more consistent. I don’t feel like I’m in a line at the DMV anymore; “oh you need that, go stand in that line and learn that stack, then come back”. Like you, I’m extremely skeptical about the multiplatform siren. We tried it in Smalltalk land. The Java guys tried it and failed. I tried Flutter for a couple of apps, early testing iOS users were totally turned off (so fine for internal simple utility apps only). I would love it if someone really succeeded. We have 2 Swift UIKit apps I’ll have to convert to SwiftUI someday. So I will wish all that try well, but I’m not holding my breath at all. Having a “write once run everywhere” pitch is about the same as politicians who run on “change”. It always sells; it never really delivers.
pojntfx 3y ago
> Linux support isn't as good as on Apple platforms That's definitely still a problem for libraries etc., but thanks to very recent developments (see the article) at least getting your app to users is super simple thanks to the new Swift Flatpak runtime: https://flathub.org/apps/org.freedesktop.Sdk.Extension.swift5 https://flathub.org/apps/org.freedesktop.Sdk.Extension.swift...
- cglong 3y ago
  It says the runtime is under GPL3. Does the copyleft apply to all Flatpak apps written using Swift?
  - nextaccountic 3y ago
    I thought that Apple actively avoided GPLv3
    - cglong 3y ago
      It looks like the runtime is owned by the author of this article, who (from his bio) doesn't seem to be affiliated with Apple. Either way, I agree it seems like an odd choice.
    - rock_artist 3y ago
      a. It's the author using something which is GPL b. GPL is allowed as long as complied. c. GPL mostly limits ability for use within iOS / AppStore.
  - flexagoon 3y ago
    No, it is the runtime, it's not a part of your app, it just runs it. You can basically think of it as a Docker container (but specifically for desktop apps). You don't have to make your app GPL, the same way as you can run a proprietary app on Linux even though the Linux kernel is GPL
    - badsectoracula 3y ago
dkh 3y ago
I remember a few years ago, a few really cool cross-platform UI libraries were starting to emerge such as libui [0] that got me excited. I've kind of lost track of them since then (libui itself went dormant for a while before this fork) so I am not sure how mature/useful they are now, but the potential for writing native desktop UIs in basically any language seemed like an absolute dream. Perhaps it's feasible for very basic things? [0] https://github.com/libui-ng/libui-ng https://github.com/libui-ng/libui-ng
loic-sharma 3y ago
Flutter Linux targets GTK3 and is currently investigating a GTK4 migration. Flutter also supports Windows and macOS.
- PlutoIsAPlanet 3y ago
  But it doesn't use GTK widgets, it just uses GTK to make a window. That said GTK on Windows and macOS is very meh. You don't choose GTK for making a cross platform app.
  - treyd 3y ago
    Deluge and Transmission are good cross platform GTK apps.
    - IshKebab 3y ago
      Evidentially it is possible to make GTK apps work at least somewhat nicely on Windows and Mac since there are a few out there. But it's clearly a ton of work. If you just make a standard GTK app it will be terrible. Most toolkits (e.g. Qt or even Flutter) work much nicer without having to fix them.
    - sirwhinesalot 3y ago
      Transmission only uses GTK on linux.
      - abrouwers 3y ago
        There is a Qt and CLI client, too.
        seabrookmx 3y ago
        And a web UI! (My preferred method as I run it on my home server)
    - chungy 3y ago
nicoburns 3y ago
There is Relm (https://relm4.org/ https://relm4.org/). Which is in Rust is just GTK (through it's Rust bindings) with a nice reactivity layer on top.
firecall 3y ago
FWIW I very much enjoyed using SwiftUI once I got the hang of it! I'd been out of iOS dev for a good long while, and was still thinking in UIKit and Obj-C. Overall I've found SwiftUI to be the most productive and enjoyable declarative framework and developer experience I've used! To be fair my experience is limited to React and Flutter, but still, Apple have done a rather excellent job IMHO! YMMV :-)
- mojuba 3y ago
  Rewriting an app from UIKit to SwiftUI not only eliminates storyboards but also reduces the code base. So once again: you have code plus storyboard XML vs. just code that is smaller! My jaw dropped when I first discovered this while rewriting something. Unfortunately though SwiftUI hasn't completely matured yet. Especially if you are targeting iOS versions prior to 16, you will encounter many of SwiftUI's shortcomings. Some (many?) UI components are still UIKit under the hood, scroll view and its derivatives are still not as flexible as you sometimes want them to be etc. For some custom UI tricks that would be a piece of cake in UIKit are impossible in SwiftUI and you often resort to wrapping the old components in your custom ones. Oh and don't get me started on resorting to the main thread (because of the underlying UIKit code) in the age of structured concurrency. All in all, the concept of SwiftUI coupled with structured concurrency is beyond amazing but its maturing process is still underway.
dartharva 3y ago
> targeting GTK4 > cross-platform ?? Do you know of any GTK4 app that runs well on non-Unix platforms?

imbnwa 3y ago

I’ve recently noticed Swift sneakily becoming an interesting option for desktop dev. On top of this example I’d add Arc for macOS and Windows.

diggan 3y ago
Will be interesting to see where it ends up, yeah :) > On top of this example I’d add Arc for macOS and Windows. Didn't development of Arc stop like a really long time ago? Anarki seems to be where development is at nowadays.
- tunaoftheland 3y ago
  I believe the references to “arc” here and elsewhere in the thread is referring to the new web browser and not the Lisp-family language. There’s a GitHub link to a Swift ui bindings for Windows elsewhere by another poster here.
  - imbnwa 3y ago
    This is correct
- imbnwa 3y ago
  Oh, I meant the Arc Browser[0]. Wraps Chromium with a Swift GUI layer [0]https://arc.net/ https://arc.net/
  - diggan 3y ago
    Oh yeah, in hindsight that makes perfect sense. Guess I've spent too much time on HN...

Apocryphon 3y ago

Flutter desktop app support has been on Ubuntu since 2021, but not sure if that ever got anywhere.

robertlagrant 3y ago
I quite enjoyed following a Flutter/Dart tutorial[0] a couple of years ago. Quite enjoyed the combo. If anyone fancies trying it, it's probably also the best tutorial I've ever seen. Really well structured and just the right amount of detail based on the place in the tutorial. [0] https://www.youtube.com/watch?v=1ukSR1GRtMU https://www.youtube.com/watch?v=1ukSR1GRtMU (video)
- bcye 3y ago
  Top comment: "don't follow this tutorial [because it's outdated]" :(
  - robertlagrant 3y ago
    I don't see that one. There's one from 3 weeks ago that liked the course. I did do it years ago though, so it could be outdated now.
- zogrodea 3y ago
  I had to use Flutter and Dart for a job a couple of years back and found this video series an excellent guide when learning about them too. Would recommend to anyone looking to learn either too.
fngjdflmdflg 3y ago
Yes flutter works on Linux. In fact the Ubuntu installer/OOBE is written in Flutter.[0] Not sure how this is related to the OP though. [0] https://ubuntu.com/blog/how-we-designed-the-new-ubuntu-desktop-installer https://ubuntu.com/blog/how-we-designed-the-new-ubuntu-deskt...
deleted 3y ago
[deleted]

coldtea 3y ago

>The primary motivation for this package is to enable the use of Swift when writing GNOME apps, for all the reasons outlined above The only problem I have with such projects is when they are unmaintained, in various stages of immaturity, and have little adoption (vicious circle). You find them, they promise exactly what you need, and then you fell into issue after issue in practical use (*). It would be amazing if there was (perhaps this is or will be) well maintained bindings for Swift/Rust/Go and co for Gnome. * Yes, it's open source and you can fix some of the issues yourself. Doesn't mean you have the know-how or time to fix all of them, especially when there are lots of things to fix or features missing. Ideally a big community must exist, so that each can just work on or fix a small part and the problem still get lots of fixes/improvements incoming, as opposed to "fully replace the single overworked maintainer yourself".

dkh 3y ago
This. Over the years I've seen so many cool projects aiming to ease native desktop UI development, but most became unmaintained at some point, for what I am guessing is due to the difficulty and complexity associated with actually making this work in practice. It is less sexy, but a solid language binding to the existing libraries is likely the more practical and maintainable way to go
- MBCook 3y ago
  After so many years of seeing cross platform stuff come and go I can’t help but think it can’t be done well enough for mass adoption. It just has too many gotchas that make things feel out of place on every platform in different ways. At least outside my first demo app territory. The only thing that really seems to be succeeding is web stuff like Electron, which usually throws the baby out with the bathwater and does its own thing of emulating the web (itself, basically) instead of trying to feel perfectly native.
  - jcelerier 3y ago
    Idk I've been developing with Qt for idk, 15 years now, it's stable and keeps chugging along with constant improvements. And is used in more than enough mass-adopted apps, e.g. Telegram

eptcyka 3y ago

Is there a language server for Swift that does not suck? I believe swift is a good language, however its ecosystem being steered by apple is a massive red flag. It also suffers a bit from being a commercially developed language in that its developers are clearly incentivized to add more features.

georgelyon 3y ago
sourcekit-lsp works really well, VSCode integration is solid[1]. I've been using VSCode+dev-containers+sourcekit-lsp for a couple years now for Linux development on macOS and it has been really nice. I agree that this is a must-have for idiomatic Swift. It is really hard to write the long-named-functions and get all the variable names correct without reasonable autocomplete. [1]: https://www.swift.org/blog/vscode-extension/ https://www.swift.org/blog/vscode-extension/
- jwells89 3y ago
  VS Code isn’t too bad, it after ~20 years of Xcode/Project Builder, muscle memory for keybinds and UI in general is strong. Hoping that someone uses the LSP to write a cross platform “Xcode Lite” or something along those lines.
  - georgelyon 3y ago
    It wasn't too bad to switch for me, but the problem is going back and forth. I don't love over-customizing my IDE but I've created my own keybindings for the commands I mis-type most (Command-R to run being the main culprit). Both Xcode and VSCode support custom key bindings and this isn't something that the LSP is responsible. UI is a different matter. Xcode is still miles ahead in performance tooling.
- cmrdporcupine 3y ago
  I was curious and noticed that this looks reasonable: https://github.com/emacs-lsp/lsp-sourcekit https://github.com/emacs-lsp/lsp-sourcekit Emacs + lsp-mode + sourcekit + company-mode etc looks reasonably close to what I get with Rust in Emacs. If I were doing application development I'd maybe consider Swift.

l72 3y ago

I recently wrote a small side project using vala + gtk4. I tried blueprint, and while I liked the format, I struggled with a lack of documentation on how to do some more advanced things. Gtk's .ui files are ok, but you still end up writing a lot of code to hook everything up. While I really like vala as a language, I think it'd be great to write all my logic and models in vala, then use this swift library for the UI.

RussianCow 3y ago
> While I really like vala as a language, I think it'd be great to write all my logic and models in vala, then use this swift library for the UI. At that point, why not just do everything in Swift? What does Vala give you that Swift doesn't?
- dkh 3y ago
  In the context of Gnome/GTK development, there's almost nothing more stable and comprehensive than Vala, as it's been around a very long time and was created specifically to occupy that space. Can't speak for OP about why to combine it with Swift handling the UI, but certainly Vala still has far better support for the Gnome data model and APIs outside of those specific to the GUI.
  - RussianCow 3y ago
    I get that, but if you're going to deal with the impedance mismatch anyway, I would just go all in and use Swift for everything. But I guess that's assuming that GTK/GLib is fairly easy to wrap in a language like Swift, which I assume is true given all the different language bindings out there.
    - badsectoracula 3y ago
      I think a difference between Vala and everything else is that Vala has been written with gobject as its "native" object system whereas everything else uses the glib bindings. Kinda like using COM from Visual Basic 6 vs using it from plain C.

worik 3y ago

I spent 3-years with Swift recently Makes me want to ask: Why? Why do this? It is a decent language for 2005. But it has some serious shortcomings (reference counting garbage collector? Really?) The worst thing IMO is its dreadful support for threads. The "DispatchQueue" seems to be a wrapper around "fork/renice". There is no attempt at memory protection. But it is full of little niggles that get very irritating in this day and age. I never used Objective-C so it may be a vast improvement on that. It is no longer 2005, and we deserve, and we have, better languages. My time as an Apple developer left me with the overwhelming sensation that Apple hates its developers. So much cool looking stuff that mostly worked...

keyle 3y ago
I'm not sure where you get your references from but Swift is one of the most modern and advanced languages out there. The documentation of Apple is worse than hot garbage though. As in, at least with hot garbage you have something.
- developerDan 3y ago
  What do you mean? Apple has lots and lots of documentation saying that function signatures exist! (/s just in case)
- tcmart14 3y ago
  I've gotten better at navigating the Apple docs, but yea, they are not the best. The one thing I will say, when they give code snippets in their docs, the code snippets are really good. But you just need to read the API of a framework or see the functions tied to a type, it could be a lot better.
frizlab 3y ago
ARC is for classes, structs use don’t have that and classes are heavily discouraged. DispatchQueue is anything but fork/renice. Also there is async/await now. GCD should be used for concurrent work only now, not async work. Memory protection is fully implemented in Swift 5.10, but compilation only warns, enabled by default as errors in Swift 6.

msie 3y ago

I always thought that introducing keys in function parameters was a mistake.

frizlab 3y ago
I disagree. It makes the code readable.
- makeitdouble 3y ago
  It's still a tradeoff: in a previous team switching languages it openned the door to function with 5+ parameters, when that was highly throwned upon otherwise. It's a tool to help better manage complexity, and that naturally invites more complexity as well.
  - bigyikes 3y ago
    is that an issue of the language or of the team? adding additional names does not add additional complexity. complexity arises in interactions between components.
    - makeitdouble 3y ago
      I see it as mostly influenced by the language and tooling. From there, some people will be more attracted by one side or the other, but when moving stack you tend to follow the stack's natural incline. For instance ruby helps to have shorter, less verbose code, but with more hidden components. Rails rose from there, tooling tends to support that style. I've seen java devs moving to ruby and naturally writing less verbose code. In contract Java tooling makes it a lot more manageable to write 40 character long classes, deeper dependency trees and injections and potentially auto-generate half of the needed methods. The cost is low, and there's less incentive to fight that trend when tools help you abstract part of it.
      - bigyikes 3y ago
        i agree but you discuss verbosity and not complexity

YmiYugy 3y ago

Has anyone been able to get this running on Mac. Followed the instructions, but I always get a missing adwaita.h in some shim.h

axoltl 3y ago
Adwaita is - I believe - closely tied to Gnome. SwiftUI (obviously) already has bindings for macOS’ window server. Not sure what this project gets you on macOS that you don’t already have?
ankurdhama 3y ago
You will need to install libadwaita. Try "brew install libadwaita"

jamilbk 3y ago

That's neat! But how is everyone testing their Swift codebases? We've found the story around testing to be... lacking. The [docs](https://developer.apple.com/documentation/xctest https://developer.apple.com/documentation/xctest) on the subject are pretty bare and don't offer strategies for mocks, stubs, reporting, code coverage, etc. And good luck if your app uses a Network Extension... those must be tested on a live physical device due to the signing restrictions! On that note, does anyone know of a good physical device CI service that supports both iOS and macOS devices?

suraj 3y ago
Take a look at https://github.com/apple/swift-testing https://github.com/apple/swift-testing It is under active development as Swift first replacement for xctest. For CI service, Xcode cloud does support running tests on mac and iOS hardware. https://developer.apple.com/xcode-cloud/ https://developer.apple.com/xcode-cloud/
- plorkyeran 3y ago
  Xcode Cloud doesn’t actually support running tests on devices. Some of the marketing tries to imply that it does, but it’s simulators only.

QuantumG 3y ago

The article doesn't summarise the differences between developing these cross-platform apps vs only targetting Apple and that is the most important information really. Did I miss it?

deleted 3y ago
[deleted]

etaioinshrdlu 3y ago

I'm having Deja Vu from about 20 years ago of writing Gnome apps in C# using Mono.

jddj 3y ago
Oh wow, I forgot all about that little detour. I remember making some rudimentary accounting software for which I'm sure now the source is long gone.
neonsunset 3y ago
You still can! (even easier now since it will run on CoreCLR instead) https://www.nuget.org/packages/GtkSharp https://www.nuget.org/packages/GtkSharp
- przmk 3y ago
  This only targets Gtk3 and not Gtk4 or libadwaita though. Seems a little end-of-life.
pjmlp 3y ago
Which ended up having such a community backslash that Miguel de Icaza decided to focus his efforts on Xamarin instead, followed by Microsoft's acquisition, and nowadays he is focused on Apple's ecosystem, Swift and Godot on Apple platforms. "Miguel de Icaza and his ostracization from FOSS" https://www.linux-magazine.com/Online/Blogs/Off-the-Beat-Bruce-Byfield-s-Blog/Miguel-de-Icaza-and-his-ostracization-from-FOSS https://www.linux-magazine.com/Online/Blogs/Off-the-Beat-Bru... "What killed the Linux Desktop" https://tirania.org/blog/archive/2012/Aug-29.html https://tirania.org/blog/archive/2012/Aug-29.html "How I ended up with a Mac" https://tirania.org/blog/archive/2013/Mar-05.html https://tirania.org/blog/archive/2013/Mar-05.html One might wonder how things would have turned out instead if the community had been more welcoming of his efforts on GNU/Linux.
- masfoobar 3y ago
  While I found the MonoProject interesting, I was skeptical using it. Sure, it is an Open Source .NET framework but .NET is Microsoft at the end of the day. I do not (and still do not) want their fingerprints inside my GNU/Linux machine. What I mean by this is the legalities behind it. Remember, my comment above is based on views 20 years ago. My perspective is that Microsoft cannot "beat" Linux purely as competition. It isn't going anywhere. While it may not be a concern in the Desktop market, it certainly dominates on servers! Microsfot are not stupid and see CONTROL through other means. Imagine if most programs that come default in Linux distributions being C#? If more and more programs are written in C# (whether Mono or not) gives them power over the Linux user. Today, Microsoft has .NET core (recent release .NET 8) and also replaces Mono. We still have Xamarin of course but that is getting replaced with MAUI. A lot of Microsofts software is now cross platform, like Powershell, SQL Server, etc. This "concern" I was having 20 years ago is still just as big of an issue today. Imagine Microsoft getting the marketing right and SQL Server starts gaining momentum on Linux boxes. This means less using MySQL or Postgres. Imagine is Powershell starts gaining more traction in Linux land rather than Bash. Now -- I think this is EXTREMELY UNLIKELY to happen but you can garantuee this is a strategy. They have the money and manipulation skills to help make it happen. Big companies can easily eat this up and it starts with "but we can support you!" Think about it -- WSL is easy to setup on Windows machines! More and more C# applications can easily be tested for Linux. Microsoft just gave you the tools, and letting developers/companies do the rest for them. Soon it is sheep follow sheep. Bit of a long winded comment/reply - and while I do not share targeting hate towards anyone (I do not know Miguel personally but he seems like a cool guy) -- I just think efforts should have been elsewhere. Dlang could have been a really, really good replacement. My guess as to why Dlang didn't take off back them was the compiler was not open source. Who knows?

throw_m239339 3y ago

So, the elephant in room, what's the best way/framework today to write desktop apps for linux (no electron)?

dzogchen 3y ago
Qt of course, hands down.
tkubacki 3y ago
Flutter
FireInsight 3y ago
Imo libadwaita apps are the best, but I haven't found a perfect solution for writing them.
earthnail 3y ago
Qt (without QML). Has been around for ages and works beautifully. GTK is more complicated. I have no experience with libadwaita, but if in doubt I'd always go for Qt on Linux. It's stable, has great tooling and good documentation. And it hasn't changed much over the years, so most information you find - even on Qt 3 - is still mostly accurate today.
- rubymamis 3y ago
  I would argue that Qt with QML is the best combo. See: https://news.ycombinator.com/item?id=39848069 https://news.ycombinator.com/item?id=39848069
  - earthnail 3y ago
    Love the idea of Plume; signed up to the mailing list. Btw the website layout breaks on very wide browsers (images in the .features-section overlap text). Maybe consider some max-width for the page. And I also have to say that my days with Qt are quite some time ago. I never really got into QML, so if you say that QML is a great choice I'd put more weight on your word than on mine.

lukeh 3y ago

Other things worth checking: https://github.com/stackotter/swift-cross-ui https://github.com/stackotter/swift-cross-ui https://github.com/TokamakUI/Tokamak https://github.com/TokamakUI/Tokamak I’m also working (slowly) on native Flutter channels: https://github.com/PADL/FlutterSwift https://github.com/PADL/FlutterSwift But this is really targeted at embedded use cases.

dkh 3y ago
TIL Sony maintains a Flutter eLinux embedder project[0] [0] https://github.com/sony/flutter-embedded-linux https://github.com/sony/flutter-embedded-linux
marcprux 3y ago
And there's also SwiftUI for Android: https://skip.tools/blog/bringing-swift-to-android/ https://skip.tools/blog/bringing-swift-to-android/
- wahnfrieden 3y ago
  Very nice Do any of these have a good wkwebview equivalent
  - marcprux 3y ago
    Yes, web views (backed by WKWebView on iOS and android.webkit.WebView on Android) are one of the Skip modules under active development: https://github.com/skiptools/skip-web https://github.com/skiptools/skip-web
    - wahnfrieden 3y ago
      Looks amazing. As an indie dev who quit my job to try to make it solo, I'll either need to wait until I have more revenue to afford this, or hopefully you add some indie-friendly tier for bootstrapped pricing (such as a discount on team size, or ARR like Apple does with its small business program).

w10-1 3y ago

For another SwiftUI-like wrapper, see also https://github.com/stackotter/swift-cross-ui https://github.com/stackotter/swift-cross-ui (used by Adawaita to generate widgets, and mentioned in other comments). The key premise of this approach is to provide a SwiftUI-like declarative wrapper around Gnome functionality. It's unclear what it adds over swift-cross-ui. SwiftUI itself has growing pains mainly around being on the right thread for processing/updates and getting data binding right. Blog entries on swift.org or from Apple tend to be little demos that show the happy path, but when discussing new frameworks (like a Gnome wrapper) or platforms (like the recent embedded), I'd like more demonstration that the authors understand and address key issues and will sustain development. Cross-platform UI frameworks get complicated quickly and have a long tail of issues (cf Flutter, Java/Eclipse, et al) that can be blockers for clients/users. For Swift it doesn't help to have multiple concurrency models and obviously different behaviors on apple platforms and Linux (where UI is not officially tested).

azinman2 3y ago
I’ve never struggled with being on the right thread. It’s always main to update UI. Grand dispatch makes this trivial, and the recent actors work also extends this. I’m also not sure how this is SwiftUI specific as UIKit and most other UI frameworks are the same. What are the growing pains here?
- w10-1 3y ago
  Aside from UI updates, processing includes view-model derivations (e.g., calculating errors), persistence, and loading, all of which are offloaded to dispatch queues or actors and then brought back to the UI/main thread. wrt granularity, there's @State, @StateObject, and @Observable, with different binding reaches. So understandably a lot of choices reflecting legacy and new API's, integration with UIKit and web/media services -- and probably AI recognizers in the background. To me the pains are that the approach taken needs to be consistent application-wide (async is pretty viral, queues are designed to be shared e.g., per subsystem, etc.), making it hard to manage or migrate a code base. Also many features build on macros which can make builds almost intolerable. Also saving on macOS vs integrating with update manager on iOS. It can be hard even to find documentation on stdlib feature support e.g., Regex. It's good they maintain both the legacy support and go full-steam-ahead on new features, but developers (i.e., I) need more guidance on tip-toeing around pitfalls and managing platform differences.

galina700 3y ago

[flagged]

accurrent 3y ago

How is the 3D story on gtk4 am I still stuck to opengl contexts?

iidaya00 3y ago

[flagged]

tschumacher 3y ago

I wonder where the pulse is with current GTK app development. I've noticed some of the newer core apps are in Rust like the new camera app and the image viewer, also the public transport app railway (not a core app afaik).

treprinum 3y ago

Writing UI code layouts is suboptimal in any language. Delphi had it right - place whatever controls you like in a GUI, set up basic behavior via properties, then just quickly write handlers in code.

berkes 3y ago
My immediate though of the Swift Example Code was "but where does the business logic go". This trivial example lacks it, and places it simple logic inside the UI code. But what if we want to protect against negative numbers? Or want to increase the number with larger increments if we hold the button pressed? Etc. Your Delphi setup isolates business logic from UI. Which may seem "overly complex" in trivial demoes, but will help you the very moment you write the first test or add some business logic. It's also why I see so many React apps spiral into an unmaintainable mess within days after their "git init".
- diggan 3y ago
  > It's also why I see so many React apps spiral into an unmaintainable mess within days after their "git init". This is true for any library/framework/architecture, and the same problem is very prominent in Svelte/Vue/React/Backbone/Angular and everything else.
  - berkes 3y ago
    > and everything else. No. It's true for any library or framework that lack isolation or decoupling concepts. In react (and many of the ones you mention) there is nothing on place that guides you into decoupling. It has nothing, not even conventions, that help a junior to put stuff in the right place (or to prohibit or make it difficult to put stuff in the wrong place). Part of that is due to how in TS/JS everything can grope around in everything else. But the bigger part is lacking conventions, primitives and structure in the libs and frameworks. Sure, a library (which react is) doesn't provide structure (it's a distinguishing trait from frameworks). But the many frameworks on top of React don't do a good job either. They either become some Enterprise Ready amalgamation of saga's, redux, message-bus, setups, or they offer too little guidance. And in all situations, it's still possible to just fire a fetch() or put data transforms or business logic within the UI. Only discipline keeps people from taking this "much easier" route. And when only discipline stands between us and "the easier way for now", that "easier way for now" will be chosen, and pain in future will be felt.

codedokode 3y ago

I don't understand why there are so many negative comments. Writing GUI in C looks like a stone age programming, and people are simply wasting their time to do routine work that can be diminished by using another language. One might use Python, but it is slow and memory-hungry. Isn't it good that now there is an alternative to C?

diggan 3y ago
> Isn't it good that now there is an alternative to C? It's not exactly the first alternative, GJS (Gnome JavaScript) have existed for a long time and is also a C-like language, so doesn't seem this would give too much value compared to just using GJS, unless you know Swift a lot better than JavaScript but the languages are similar enough that even that doesn't provide much value. AFAIK, GJS is an official Gnome project too, so there will be a vast difference in ecosystem support compared to Gnome apps written in Swift, which I'm not sure is so popular outside of Apple circles.
- codedokode 3y ago
  JavaScript is non static-typed and you'll spend time fixing bugs that can be prevented by static typing. Also, GJS is not well documented, as far as I remember.
  - diggan 3y ago
    > JavaScript is non static-typed and you'll spend time fixing bugs that can be prevented by static typing. Use TypeScript if types are so important for you. Others find their own way of handling those issues without getting tripped up on it. Hardly a reason to completely switch between two languages in my mind, but of course it's alright if it's reason enough for you. Luckily there are acceptable workarounds for both groups of people :) > Also, GJS is not well documented, as far as I remember. What exactly is missing here? There are guides for the basics, API reference exists and there is a ton of apps you can look into for inspiration and/or figure out specific implementations. Is that really worse than what exists for writing Gnome apps with Swift? Seems like a really weak argument for using Swift instead of GJS.

vi4m 3y ago

Really something we needed. Swift has such low memory usage, that it's an order of magnitude easier on resources, than those Electron wrappers. At the same time, it gives what you loved about React - expressiveness for UI. I wrote a lot of apps in SwiftUI, and it strikes a good balance between type safety and expressiveness, it's cool that we have something similar for GKT/Gnome now.

deleted 3y ago
[deleted]

FireInsight 3y ago

This is really cool! I love the JSX-like approach to UI and it's a shame it's not so common on desktop. https://github.com/can-lehmann/owlkettle https://github.com/can-lehmann/owlkettle is the only thing I find comparable.

elcritch 3y ago
And Nim is pretty handy for DSL approaches like that! I've never got to try SwiftUI stuff, but it looks great for desktop UIs.

pona-a 3y ago

That looks really nice! A healthy balance of reactive UI, expressiveness, and sanity. I wonder if there's a similar Swift binding for Qt... Ubuntu Touch and KDE could really benefit from that, as QML proved to be a total typing nightmare from my experience, often even slightly worse than regular JS thanks to its quirks...

keyle 3y ago

It's an interesting value proposition. But can I take my existing SwiftUI app and have a path towards porting them to Linux and windows? How foreign would they look since Apple's patterns aren't the same.

nickwarren 3y ago

Swift is such a delightful language to use, well suited for general application development. It's awesome to see it gaining traction outside of the cocoa ecosystem. If you haven't given it a fair chance yet, I would highly recommend you do!

Obertr 3y ago

I had an extremely negative experience creating apps in Swift. I can't see any logical reason why people would not use Electron/Tauri. Swift doesn't allow you to have full control of what you want to do. I built a whole macOS [ fixkey dot ai] app in Swift, and it was a very painful development experience.

manmal 3y ago
Were you new to Swift? It for sure has its issues, but lack of control wouldn’t make it on my list.

deleted 3y ago

[deleted]

nurettin 3y ago

You could say "writing Gtk code in X language where I implemented a DSL for this special case is easy!" in any PR piece. You could do it in Python using contextmanager which packs after adding the widget to HBox to save a line, you could do it in Ruby using do/end blocks, you could do it in C with the help of some pretty macros.

tripdout 3y ago

Is this the only declarative way to write desktop app UI? (Maybe Kaitlin multiplatform, but not sure how that works on Linux). I mean GTK/Qt

zengid 3y ago

I feel like a cross platform Swift GUI would be a great thing for the world. Swift strikes a great balance between ergonomics and performance, and seems to be the only other mainstream language to have absorbed some of Rust's key features around borrowing references.

georgelyon 3y ago
For the record, borrowed references are only going to be really usable in Swift 6 which isn't released yet. That said, Swift's implementation of borrowing seems significantly more user-friendly than Rust's. While this is very much an advanced feature, I'd expect it to be actually used in many cases where in Rust folks would resort to working around the borrow checking (via things like indexing into arrays and such). As a result I expect it to be significantly more useful.
jrsj 3y ago
Browser Company sort of built this themselves for Arc, but its really a separate SwiftUI-like Windows implementation (Windows UI is separate code written in a similar style). It still feels like a technical preview though unfortunately.