[HN Gopher] Writing Gnome Apps with Swift
       ___________________________________________________________________
        
       Writing Gnome Apps with Swift
        
       Author : msk-lywenn
       Score  : 110 points
       Date   : 2024-03-27 21:40 UTC (1 hours ago)
        
 (HTM) web link (www.swift.org)
 (TXT) w3m dump (www.swift.org)
        
       | koito17 wrote:
       | 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.
        
         | p10r wrote:
         | Sounds like Compose and Kotlin, although multiplatform still
         | being more in a beta stage.
        
         | pojntfx wrote:
         | > 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.swift...
        
           | cglong wrote:
           | It says the runtime is under GPL3. Does the copyleft apply to
           | all Flatpak apps written using Swift?
        
         | dkh wrote:
         | 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
        
         | loic-sharma wrote:
         | Flutter Linux targets GTK3 and is currently investigating a
         | GTK4 migration. Flutter also supports Windows and macOS.
        
           | PlutoIsAPlanet wrote:
           | 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 wrote:
             | Deluge and Transmission are good cross platform GTK apps.
        
               | IshKebab wrote:
               | 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 wrote:
               | Transmission only uses GTK on linux.
        
               | abrouwers wrote:
               | There is a Qt and CLI client, too.
        
               | chungy wrote:
               | Transmission has Qt and Win32-native GUI clients as an
               | alternative to its GTK client.
               | 
               | I don't think Transmission is a good example.
        
               | dpassens wrote:
               | Transmission uses Qt on Windows, either GTK or Qt on
               | Linux, and something AppKit on macOS.
        
         | rubymamis wrote:
         | Why not go with Qt's QML?
        
       | imbnwa wrote:
       | 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.
        
       | Apocryphon wrote:
       | Flutter desktop app support has been on Ubuntu since 2021, but
       | not sure if that ever got anywhere.
        
         | robertlagrant wrote:
         | 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 (video)
        
           | bcye wrote:
           | Top comment: "don't follow this tutorial [because it's
           | outdated]" :(
        
             | robertlagrant wrote:
             | 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.
        
         | fngjdflmdflg wrote:
         | 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-
         | deskt...
        
       | coldtea wrote:
       | > _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 wrote:
         | 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
        
         | Razengan wrote:
         | I don't get these kinds of complaints about open source
         | projects..
         | 
         | Seems like you guys want either 0% or 100% ..that something
         | either not exist at all or perfectly does everything you ever
         | wanted without any effort or cost on your part.
        
           | lmm wrote:
           | You want a process and commitment, a clear distinction
           | between which things are first-class and which things aren't.
           | If this is just an experimental project that may not go
           | anywhere, fine. If this is meant to be the new way of writing
           | Gnome apps, displacing Vala, and they're going to support it
           | in LTS releases for at least the next n years, fine. But it
           | should be clear which it is.
        
         | georgelyon wrote:
         | This is spot-on. Though I think the interesting thing here is
         | just demonstrating that you _can_ build this kind of thing at
         | all and a cross-platform-SwiftUI-like framework isn't a pipe
         | dream.
         | 
         | For production use-cases at this moment in time, I'd probably
         | lean towards using Swift's pretty-good C++ interop
         | functionality to thinly wrap a more battle-tested C++ library.
        
       | eptcyka wrote:
       | 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 wrote:
         | 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/
        
       | l72 wrote:
       | 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.
        
       ___________________________________________________________________
       (page generated 2024-03-27 23:00 UTC)