return to table of content

Writing Gnome Apps with Swift

koito17
63 replies
20h24m

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
19 replies
19h51m

Why not go with Qt's QML?

wizzledonker
12 replies
18h7m

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
8 replies
17h56m

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
7 replies
12h53m

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/

ezst
3 replies
10h55m

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
2 replies
10h42m

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
1 replies
2h2m

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".

rubymamis
0 replies
1h46m

Just read this comment of yours[1]. Plume is aimed to be much simpler than Trilium, I want a non-tech-savvy 40-year-old mom that doesn't know what Kanban is to be able to happily use it as someone that is tech-savvy that knows all about Kanbans. Something that just works for many people, like Apple Notes but with a more advanced editor and features.

[1] https://news.ycombinator.com/item?id=39034749

mike_ivanov
2 replies
11h15m

Looks gorgeous. Is it QML or pure Qt?

rubymamis
1 replies
11h4m

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
0 replies
1h37m

Amazing. This is very inspiring, thanks.

pona-a
1 replies
7h52m

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
0 replies
6h37m

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/

[2] https://www.qt.io/blog/the-new-qtquick-compiler-technology

aplummer
0 replies
13h2m

It just is is a relative term, for example - I already know SwiftUI.

dheera
5 replies
17h31m

I hate Qt, the apps look non-native and don't obey Ubuntu's appearance settings and fonts.

dartharva
3 replies
11h45m

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..

eitland
1 replies
10h13m

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
0 replies
2h19m

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
0 replies
2h29m

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.

ezst
0 replies
11h11m

Qt apps arguably look more "native" on average than anything else I've seen, considering that it mimics the native look and feel of the target platform for a wide range of them. Now compare that to Gtk, which just leaves you with gnome-style shortcuts and controls on Windows/Mac, and nothing in the area of desktop integration if that's a feature gnome doesn't have (e.g. tray).

p10r
15 replies
20h11m

Sounds like Compose and Kotlin, although multiplatform still being more in a beta stage.

jwells89
10 replies
18h32m

Kotlin is probably the most similar in syntax to Swift out of the languages I’ve written, but it’s somewhat quirky and opinionated and I’m not sure I agree with its opinions (lack of guard statement, no ternary ifs, etc). Also it involves Java ecosystem stuff like Gradle which can drive a person mad sometimes.

fuzztester
5 replies
18h8m

Also it involves Java ecosystem stuff like Gradle which can drive a person mad sometimes.

Interesting. Why is that? I've been out of the Java loop for some years (although I did a fair amount of work with it earlier), so not up to date with this stuff.

dhosek
2 replies
17h57m

Gradle combines the inscrutable magic of Maven with the unpredictable structurelessness of Ant in one bundle of pain.

thfuran
1 replies
17h2m

What really irritates me about gradle is that they have significant API churn but there's still five ways to do everything.

naruhodo
0 replies
15h46m

I will never pass up an opportunity to heap scorn on Gradle. I agree with everything said so far, except I would argue Ant was easier to use.

Every single Gradle build system I have encountered in the wilds of GitHub has been broken on Fedora. I eventually realised it works if I run it in an Ubuntu container (using "toolbox"). So it's only portable if you bundle up the OS with your build system.

Now it should be portable. It's written in a JVM language and every Gradle project I have seen commits a copy of the Gradle JAR to its GitHub repo, which gives me those arbitrary code execution heebie-jeebies.

e3bc54b2
1 replies
10h40m

ooh where do I start... Let's see:

1. Every single gradle script is a unique snowflake of mishmashed plugins and custom functions

2. Gradle likes to pretend it is declarative, but as people very quickly learn it really isn't.

3. The one thing a build system is expected to do is be reliable in face of changing platform version, libraries and plugins. But gradle, being built on top a language on top of JDK itself has a Compatibility Matrix[0] that one has to be aware of. Often when upgrading a project you have to update JDK and gradle in explicit order, sometimes multiple times.

4. Speaking of which, did you know that gradle, being designed to build java projects does not even manage multiple JDK versions?!

5. untyped groovy means you're forever left wondering whether what you wrote is actually correct until you run it, at which point it fails with excellent errors that tell you nothing. Granted, this situation has improved in recent days, but a jump from 90th floor compared to 100th is still painful.

6. Every single fkin thing that gradle offers can be done in half dozen ways and nothing tells you which way is better or why. Ex.A: is it providedCompile or implementation? Yes, one is intended to be a replacement for another, and no, they are /not/ same.

7. The 'One Nice Thing' gradle had going for is that it bootstraps itself. But look, if want to add gradle to a 'new' project, you have to install it to your system first and use it to add the wrapper. But after that, you are expected to use the wrapper. Nobody tells you that, you just have to figure it out. Oh and when it comes time to upgrade the wrapper version, you're to use the wrapper itself, not the system gradle, again mentioned nowhere, and if you try updating the wrapper using system gradle, the error helps exactly not.

8. Gradle takes free reign in breaking APIs /between minor versions/. WTF!

9. gradle starts a daemon to cache stuff, which is nice I guess. Except when you don't want it to run a daemon, so you tell it with `--no-daemon`. Do you know what that does? It starts a daemon, runs the build and shuts it down. This may not sound like a big deal, but it is just cherry on top of this shitcacke that tells you just how thoughtfully and well designed gradle is. /s

/endrant

[0]: https://docs.gradle.org/current/userguide/compatibility.html

thfuran
0 replies
3h24m

4. Speaking of which, did you know that gradle, being designed to build java projects does not even manage multiple JDK versions?!

What about toolchains?

newZWhoDis
2 replies
16h1m

My dealbreaker for kotlin is that it’s possible to call a throwing function with no indication it will throw. In swift, the compiler forces every throwing function do be inside a try/catch block or be called by another throwing function.

I also am extremely unhappy that those functions can be 16 layers deep somewhere in a lib and cause your app to blowup.

rockyj
0 replies
10h5m

There are entire languages built with unchecked exceptions, Python, Ruby, Nodejs and most recent ones. Even with checked exceptions you can write code and miss to throw or declare an exception somewhere so ultimately the developer has to deal with exceptions somehow.

jwells89
0 replies
15h30m

Yep, this is a problem I’ve encountered several times. Even if none of your own code has unhandled throws, you’ll inevitably get crash reports coming in from fooLib throwing an exception somewhere because the moon was in the wrong phase.

pjmlp
0 replies
11h52m

There is only one reason to use Gradle instead of Maven, being stuck on Android.

dkh
3 replies
18h52m

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
1 replies
15h58m

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.

jwells89
0 replies
14h37m

The first two paragraphs has been my experience on Android too. Android Framework is an incredibly disjointed mess that leaves you neck-deep in half-baked APIs.

Compose is better for sure. I’m still figuring it all out but it’s a marked improvement.

marcprux
0 replies
13h29m

Take a look at skip.tools. It's pure SwiftUI on iOS and Jetpack Compose on Android, with the tool automatically handling the translation from Swift to Kotlin as part of the Xcode build process.

loic-sharma
14 replies
19h59m

Flutter Linux targets GTK3 and is currently investigating a GTK4 migration. Flutter also supports Windows and macOS.

PlutoIsAPlanet
7 replies
19h53m

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
6 replies
19h49m

Deluge and Transmission are good cross platform GTK apps.

sirwhinesalot
2 replies
19h41m

Transmission only uses GTK on linux.

abrouwers
1 replies
19h36m

There is a Qt and CLI client, too.

seabrookmx
0 replies
15h14m

And a web UI! (My preferred method as I run it on my home server)

dpassens
0 replies
19h41m

Transmission uses Qt on Windows, either GTK or Qt on Linux, and something AppKit on macOS.

chungy
0 replies
19h41m

Transmission has Qt and Win32-native GUI clients as an alternative to its GTK client.

I don't think Transmission is a good example.

IshKebab
0 replies
19h42m

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.

rokkitmensch
5 replies
17h31m

And it's a Google project, which means as soon as the low-hanging promo fruit is harvested it will immediately go EOL.

seabrookmx
4 replies
15h15m

Like golang? Dart? Or Angular? They kill consumer products not programming languages or major frameworks..

seabrookmx
0 replies
3h7m

Hardly anyone used the Dart Angular bindings so it was not surprising they got dropped. They were an early adopter and got bit.. this happens everywhere especially in frontend web development, and is certainly not specific to Google's frameworks.

krasin
1 replies
13h19m

Angular

Well, Angular is kind of dead now (or rather - will be). See https://twitter.com/sarah_edo/status/1770478763253379488

Today we have some exciting news! We're merging frameworks! Angular and Wiz!

Wiz is awful and it's my read that a Wiz manager "won" a corporate battle and Angular (as it was) is dead.

seabrookmx
0 replies
3h6m

Isn't Wiz internal only at Google? How can it replace Angular (honest question)?

pojntfx
6 replies
20h7m

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
5 replies
20h0m

It says the runtime is under GPL3. Does the copyleft apply to all Flatpak apps written using Swift?

nextaccountic
2 replies
17h33m

I thought that Apple actively avoided GPLv3

rock_artist
0 replies
7h49m

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.

cglong
0 replies
12h33m

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.

flexagoon
1 replies
14h20m

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
0 replies
10h55m

It isn't that simple. If your application links against the runtime, be it dynamically or statically, then it is a derivative work and thus must be distributed under the GPL. This is why Java, also being under GPL, has an explicit exception for the runtime library despite even being a VM.

The Linux kernel allows you to run proprietary apps because the kernel code and the userland code exist in two separate "planes" connected by the syscall interface. The kernel even has an explicit exception for any code that may need to be shared between the kernel and the userland to make clear that this code is excluded from GPL.

As another similar case, the Free Pascal compiler is licensed under GPL including the runtime and almost all libraries/units that come with it but it also has an exception to allow linking without having the GPL extend to the programs the users write. AFAIK the GNU C library also has a similar GPL-with-linking-exception license.

firecall
1 replies
17h56m

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
0 replies
12h3m

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.

nicoburns
0 replies
17h56m

There is Relm (https://relm4.org/). Which is in Rust is just GTK (through it's Rust bindings) with a nice reactivity layer on top.

dkh
0 replies
20h0m

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

dartharva
0 replies
11h48m

targeting GTK4

cross-platform

??

Do you know of any GTK4 app that runs well on non-Unix platforms?

codedokode
38 replies
8h57m

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?

mahkoh
15 replies
7h50m

Isn't it good that now there is an alternative to C?

Rust has had endorsed language bindings for GTK for a long time: https://www.gtk.org/docs/language-bindings/rust

Some official Gnome applications are written in Rust.

Swift only supports a small number of linux systems (Ubuntu, CentOS, Amazon Linux) which makes unsuitable for general linux application development.

machinekob
11 replies
6h52m

Swift run on almost every linux desktop (Arch, Debian, Ubuntu etc. have even their own packages) I hate when people are writing false information with such a confidence.

diggan
5 replies
6h23m

"runs" would be different than "supports". AFAIK, there still isn't an official package for Swift in the Arch package registry, so to say Swift is supported by Arch sounds like "writing false information with such a confidence".

diggan
1 replies
5h53m

Be that as it may, the initial claim was "Swift only supports a small number of linux systems" which you tried to refute but moved the goal post from "supports" to "runs". One of them are true for Swift + Arch, yes.

machinekob
0 replies
5h42m

Supporting languages isn't the arch maintainers job I srsly don't understand your argument if all language stuff (LSP, language, debbuger etc.) work on every linux distro without any modifications is this distro "supported"?

If rustup will be removed from official repo we can argue that rust isn't supported in arch?

mahkoh
2 replies
6h38m

See https://www.swift.org/platform-support/ for a list of supported distributions.

You seem to have hallucinated that I said that swift cannot be made to run on other systems. You can even make windows-only games run on linux so that is not a surprise.

What distinguishes swift from gcc, clang, python, bash, go, rust, and so on is that languages other that swift aim to support linux in general.

rsynnott
0 replies
4h2m

I don't think that, say, rust, offers any explicit support for any particular linux distro?

Swift here are basically saying they'll endeavour to make sure it works on those particular distros, but in general you're probably going to install Swift on Linux the same way you install rust; via your distro's package manager, and supported by your distro, not the Swift or Rust project.

machinekob
0 replies
6h22m

Swift only supports a small number of linux systems. which is at most half-truth cause this is just official installers and most likely you'll use some sort of rustup (rust wasn't working on every system few years ago if you use official installer not some sort of rustenv installer or building from source etc.) you can use https://github.com/kylef/swiftenv you can use community packages https://wiki.archlinux.org/title/Swift etc.

"and so on is that languages other that swift aim to support linux in general." -> again not true linux distro dosen't change swift usage it is just official build is run for few most popular distros and you can use prebuild swift-bin on any linux repo. (arch, debina, ubuntu, centos etc. etc.) You can say the same stuff about rust/nim/go every other language that didn't have official release for some niche linux distro.

cocoto
1 replies
6h35m

It might run but support and packaging is missing, compared to gtk oficially supported for other languages and packaged on distributions that matter (e.g. Debian).

jeroenhd
2 replies
7h19m

Why doesn't Swift run on other Linux distributions?

machinekob
1 replies
6h51m

It runs just fine comment above is lying if you can run llvm/clang you can run Swift.

tcmart14
0 replies
2h13m

I don't know if I would say, 'just fine.' Technically yes. The issue comes in with that not everything in Foundation is quiet yet there on the Linux platform. But it is getting better and better and probably good enough for 90% of stuff. It seems more of a problem of just getting the last bit done to push Foundation over the finish line.

diggan
13 replies
8h43m

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
12 replies
8h37m

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
11 replies
8h33m

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.

codedokode
10 replies
8h28m

Swift is compiled, static-typed language and without tons of legacy like JS (for example, it has real objects, not dictionaries). Doesn't require an interpreter. It seems to be better than JS in every aspect.

diggan
7 replies
8h22m

One mans gold is another mans trash :) Static typing seems to be a neat addition for lots of people, that's great! Doesn't mean it's a silver bullet that improves development for everyone, and that's OK.

I still don't see how a language (GJS) with an already existing ecosystem of writing Gnome apps, lots of examples, API references and more is worse for writing Gnome apps than Swift, that seems to have been launched just some days ago?

Edit: I realize now that the "Adwaita for Swift" this blogpost is about isn't even an official Swift project, is the output of a student interested in Swift and Gnome.

Betelgeuse90
3 replies
7h17m

Honestly I used to think the same way about JS, because not having types allowed for very concise code sometimes. But the more I used Swift I realized how powerful type inference can be, and the difference in conciseness shrunk to basically nothing.

knallfrosch
1 replies
5h3m

Doesn't TypeScript – as mentioned above – solve all JavaScript type problems? I have, in 6 years, never encountered a single type error originating from a TS file.

jwells89
0 replies
2h11m

Biggest problems with TypeScript IMO are that it’s a layer rather than a language proper and that untyped JS problems can too easily worm their way in if you’re using any libraries at all. Also depending on the group of developers involved, the ease at which one can pull the escape hatch and opt out of TS is a liability and can render much of its benefit moot.

diggan
0 replies
7h8m

Heh, yeah, everyone's journey is different :) I started out being a big fan of static typing but eventually found that I'm usually hit by different issues than "this was a int but I expected a string" that were more important to be solved, so I'm mostly using dynamic languages nowadays.

But that's what so great with programming languages, there are so many that work so differently, so there is at least one language for everyone, no matter how different your brain works :)

By the way, if you're a fan of "conciseness" you should give a lisp-type languages a try if you haven't before, will show you a completely different level of conciseness! Clojure is a great introduction to lisps. And if you still need validation of data somehow, clojure.spec et al works great and will introduce you to some cool new things you probably haven't come across before :)

SkiFire13
1 replies
6h59m

I still don't see how a language (GJS) with an already existing ecosystem of writing Gnome apps, lots of examples, API references and more is worse for writing Gnome apps than Swift, that seems to have been launched just some days ago?

I mean, you said it yourself:

One mans gold is another mans trash :) Static typing seems to be a neat addition for lots of people, that's great!

For those people it is definitely better than GJS!

diggan
0 replies
6h32m

Well, I mean if the difference was only about static typing, I definitively see what you're talking about. But the difference between GJS and Swift for Gnome app development is greater than that, so personally just that one "feature" wouldn't push me towards Swift.

But yeah, probably for some it's worth it, so that's pretty cool :)

sph
0 replies
6h8m

I think you are vastly overestimating how good and current the GJS documentation and examples are. Without touching the fact that it is NOT a stable API and breaking changes are very common.

Even the gold standard of GTK coding in C is still very undocumented outside of the happy path and confusing due to the Gtk 3->4 migration, and the only approach to learning it is by reading what other Gtk apps do.

azangru
1 replies
7h17m

legacy like JS (for example, it has real objects, not dictionaries)

Could you explain the nature of problems that occur due to javascrript's treatment of objects? What makes it a big and important issue?

codedokode
0 replies
3h4m

In JS you can delete properties, assign anything to them (no typing), cannot add comments to them, cannot restrict access from outside. Also you can access non-existing properties and no error will be thrown.

poulpy123
3 replies
6h25m

to be fair and looking at how closed is the apple ecosystem, I would not put my open source eggs in swift

tiny_ouch
0 replies
6h5m

My feelings exactly! It's frustrating the lack of viable alternatives though. Just typing on my japanese flip phone is a pain and i think the T9 could be improved. That said i don't think adopting apple tech would help much as far as fixing any deficiencies in ui imho.

t888
0 replies
3h47m

How does the App Store affect Swift?

sgjohnson
0 replies
3h39m

Swift is open source.

steve1977
0 replies
6h7m

Isn't it good that now there is an alternative to C?

There’s this new kid in town, IIRC it’s called C++

pjmlp
0 replies
3h20m

Gtkmm exists since GNOME 1.0 days.

As do bindings for Python, C#, Lisp, Scheme, Vala, JavaScript (since GNOME 3)...

kevincox
0 replies
4h29m

Yeah, I'll happily take GUIs written in a fairly fast and memory efficient language that are using a full GUI toolkit. It beats Electron, Python, Java or Go programs any day.

amon22
0 replies
6h51m

I used common lisp in the past to interface with GTK via the cl-cffi-gtk library. Performance was good I think (I did not benchmark but the UI was responsive and did not consume much resources) and dev experience was great because of the REPL. But it did take quite a bit of suffering to get the resulting artifact working on Windows which was a definite requirement sadly. It can be done though.

treprinum
26 replies
9h58m

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
6 replies
9h43m

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
2 replies
8h37m

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
1 replies
5h48m

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.

imbnwa
0 replies
3h21m

They either become some Enterprise Ready amalgamation of saga's, redux, message-bus, setups, or they offer too little guidance

At least Redux provides a semblance of immediately grokable data flow, this all gets worse with mobx which gives you all the flour you need to make spaghetti for the whole village. Worked on a codebase where you might have to chase down references across all sorts of files you wouldn't expect because everything is 'observable' so people, working 2-week sprints, just stop thinking about any kind of coherent structure cause it works anyway.

NiteOwl066
1 replies
8h32m

You would just use some architecture pattern. I would say the most natural one for SwiftUI is MVVM so the logic would go to viewModel.

berkes
0 replies
3h18m

Do I understand it correct when the UI then calls methods or functions on a model layer?

Wytwwww
0 replies
8h19m

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.

So basically, the same as Cocoa/obj-C?

teekert
3 replies
9h12m

But then what if the UI changes dimensions? Then you'd need an underlying set of rules, and isn't it best if you can set those rules yourself? How would that work graphically?

And then how about version control? Sure there could be (and is) underlying machine code, and you could try hard to make it human readable. But... IDK seems like a lot of effort to me for some small benefits.

Disclaimer: I have only very little experience with UI programming.

hgs3
0 replies
2h9m

You solve this by using a layout control (a UI control specifically for managing the size/position of its child controls). For example using a visual form builder you could drag-n-drop a "vertical layout control" and then drag-n-drop controls inside it to be resized/positioned in a vertical stack.

The window itself can have a layout control that stretches to fill the window regardless of resizing. Layout changes would cascade down through the tree of UI controls and everything would resize/reposition accordingly.

diggan
0 replies
8h38m

But then what if the UI changes dimensions? Then you'd need an underlying set of rules, and isn't it best if you can set those rules yourself? How would that work graphically?

Look into how various design tools handle flexible layouts. Usually a combination of flexbox/something similar to flexbox or slightly more old-school; constraints.

Here is an example with Figma: https://gdwn.medium.com/how-you-can-create-really-flexible-a...

badsectoracula
0 replies
8h57m

But then what if the UI changes dimensions? Then you'd need an underlying set of rules, and isn't it best if you can set those rules yourself? How would that work graphically?

I don't know about current Delphi, but in Lazarus (which is kind of an open source and crossplatform Delphi) you set those rules visually. For example you can "draw" the UI by drag-and-dropping controls in a window/containers/etc and then you can add rules like "this button's left side will be 5 pixels from that label's left side and will be placed vertically so that it is centered relatively to the label". You can also set things like "this control (or container or whatever) will always be at the top/left/right/bottom edge of its window/container". This is done in the visual editor with immediate feedback (you can even resize the window/container while you are editing its layout to see how it behaves).

This allows you to make UIs that work not only across dimensions, but also handle different fonts, texts (for localization), scaling (for DPI) and themes. Especially important for Lazarus since its GUI framework has various backends that often look very different from each other.

And then how about version control?

Lazarus (and Delphi - with the exception of some earlier versions - and really most GUI designers) save UIs in a text based format with a tree-like structure of key/value pairs, e.g. (i edited it a bit for brevity):

    object Main: TMain
        Left = 625
        Height = 505
        Top = 393
        Width = 903
        Caption = 'World Editor'
        Menu = MainMenu1
        Position = poScreenCenter
        object plRenderContainer: TPanel
            Align = alClient
            BorderStyle = bsSingle
            object plRenderWindow: TPanel
                Align = alClient
                BevelOuter = bvNone
            end
        end
    end
This can easily be stored in version control and diffed to see changes (in fact in my own projects before committing something to VCS i check both the code and the UI files to see what exactly i changed).

rimliu
2 replies
4h47m

It is not. macOS/iOS had it for a long time with AppKit, UIKit. But the progression is usually this: you start with Interface Builder and storyboards or .xibs, then you see the problem with that and gradually move to code-only UI and then start looking at SwiftUI with it's declarative UI like a guy in that meme. GUI for layout just does not cut it, especially when your app runs in very different environments - it can be macOS, it can be a phone or just a smartwatch/widget.

treprinum
0 replies
3h38m

Alternate take: macOS/Qt/MFC/React etc. got it wrong, Delphi got it right.

steve1977
0 replies
1h57m

especially when your app runs in very different environments - it can be macOS, it can be a phone or just a smartwatch/widget.

But the question here is also if it makes sense to basically have the same UI or even UI paradigms for such different types of environments.

boxed
2 replies
9h17m

That's what mac/iOS development has had since before it was even mac, back in the NeXTStep days... But it doesn't work very well for very custom stuff.

sgt
0 replies
9h12m

My thoughts exactly.

Generally writing UI code in Xcode (and presumably before that on NeXT as well) is a breeze and a joy. Work with your delegates, connections, outlets etc.

izacus
0 replies
9h12m

And that's a good thing, because it discourages "very custom stuff" that made mobile apps such a usability disaster.

atlasduo
2 replies
8h33m

It is the same approach as declarative UI programming like SwiftUI or QML, but with an extra GUI abstraction on top of it. An artifact of this GUI-driven development process (like Xcode or Glade) is still a file with some declarative markup (sometimes even human-readable).

treprinum
0 replies
5h50m

There is a big qualitative jump when one can arrange and play with UI without writing a single line of code, even if the user's decisions about component placement are recorded in a declarative file.

steve1977
0 replies
1h59m

An artifact of this GUI-driven development process (like Xcode or Glade) is still a file with some declarative markup

Not really in the case of Cocoa's Interface Builder (nib/xib files). There the artifact is basically a marshalled object tree of the actual UI objects, not declarative markup.

ptx
1 replies
6h18m

Perhaps, but as a counterexample, the SerenityOS people implemented the Delphi approach with Visual Builder but then realized that they preferred working with text, so they replaced it with a declarative DSL and live preview (GML Playground).

Here's Andreas Kling briefly demoing both and talking a bit about it: https://www.youtube.com/watch?v=1QYBvTy9QKE&t=519s

badsectoracula
0 replies
5h58m

I don't know about Visual Builder, but judging from this screenshot[0] it doesn't look like the Delphi approach, but the "Windows resource editor" approach. Yes, both allow you to place things visually, but one works with live instances of serialized objects in an IDE that also understands the edited source code and can modify the code to -e.g.- introduce a new event handler for the OnClick event when you doubleclick the button (even with the cursor placed just right where you can start writing the actual logic of the event handling code), while the other has you draw the UI, assign some IDs and then expects you to do all the plumbing of loading the UI, associating it with code and handlers by hand.

The difference might sound trivial but in practice it is like trying to dismiss editing text with Emacs by experiencing editing text in Notepad.

[0] https://adkaster.github.io/images/build/VisualBuilder.png

fleabitdev
1 replies
8h21m

I also admire the simplicity of this approach, but it has several downsides:

- Code-based UIs tend to work better with existing tooling, like comments and source control. You can freely customise your development environment, rather than being at the mercy of a single GUI app.

- Most serious UIs need code-like features, such as "for-each" to render a list of objects, or "if" to reveal a form when a checkbox is ticked. The easiest way to access code-like features is to write your UIs in code.

- You'll need to write some backing code in any case. Defining the UI tree and its "code-behind" in the same file could be considered more DRY.

- Live preview (or alternatively, hot reloading) will give you very quick iteration when writing a UI in code. It's not quite as good as drag-to-resize, but it's close.

- Automatic layout (which is non-optional nowadays) isn't necessarily a great fit for WYSIWYG editing.

- As React has demonstrated, the ability to quickly throw together custom components is extremely useful. Visual editors tend to make it more complicated and bureaucratic to define custom components.

jwells89
0 replies
2h29m

In addition:

- WYSIWYG editors are bad about making small unintended changes that can easily slip by undetected (Interface Builder in Xcode for example often changes XIBs/storyboards just by viewing them)

- WYSIWYG editors bury bits of configuration in inspectors that are only visible in certain conditions, e.g. a control being selected, making them less evident and more difficult to find

There are circumstances where I think they still work alright — for instance I still enjoy building Mac apps with XIBs in Cocoa, but there’s a reason for that: traditional desktop UI has much less of a need for flexibility and generally speaking, has far fewer moving parts since it doesn’t have to hide things as a result of limited screen real estate. Additionally, these apps will only ever run on Macs which further reduces need for flexibility/adaptivity.

For mobile and multiplatform on the other hand, I strongly prefer code. It just works better.

datascienced
1 replies
6h51m

The old fashioned screwdriver has it right. Why fiddle with charging batteries, using a chuck and selecting direction when you can just pick up a ol’ screwdriver and get going!

… assembles an appartments worth of new Ikea furniture…

Oh!

treprinum
0 replies
5h47m

Try Delphi/Lazarus for just 10 minutes, then come back with a better metaphor. The productivity difference in comparison to React, Qt, GTK etc. is enormous. When was the last time you built the whole UI of a large app in 1 day?

msie
20 replies
19h25m

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

yen223
10 replies
18h55m

Not having keys in function parameters is a mistake.

Swift does have an unconventional approach to function keys though, wherein you can specify an "external" label and an "internal" label:

  func greeting(for person: String) -> String {
      "Hello, " + person + "!"  // the argument is "person" inside the function body...
  }
  print(greeting(for: "Dave"))  // ... but it's "for" when calling the function
I'm not sure if I like it or hate it, but it is cool.

jwells89
6 replies
18h30m

I love the internal/external labeling. With a little thought it can make for code that reads more nicely than is possible otherwise.

dorianmariefr
2 replies
18h7m

JavaScript has that with:

    const hello = ({ for: person }) => `Hello ${person}`

    hello({ for: "Dorian" })

    'Hello Dorian'

yen223
0 replies
18h2m

Javascript's one is a little bit different in that you are renaming the destructured variable - it's not a function-specific thing - whereas Swift's version is a property of the function.

e.g.

  const user = {id: "123"};
  const { id } = user;          // This extracts the `id` field
  const { id: userId } = user;  // This also extracts the `id` field, but renames it to userId
  console.log(userId)

jahewson
0 replies
14h51m

It does indeed, but the cost is an object allocation for every function call.

airstrike
1 replies
17h51m

it's one of those small things that are also brilliant in hindsight

MBCook
0 replies
14h26m

Objective-C sort of had it unofficially through how methods tended to be named.

I’m glad they found a nice way to do it in Swift.

zem
0 replies
13h26m

crystal has it too, and i agree, it's a very nice feature

travisgriggs
0 replies
15h56m

It’s one of the things I miss most in Kotlin.

tcmart14
0 replies
2h19m

For me, I felt the same way initially, but I found it depends on the case. The case you gave is probably now one I would do, I would probably have the external be 'for' if I expected the caller to pass in a list that I was gonna iterate over inside of the method.

An example I like to use to show when and how I used it. I have been playing with Metal. If I write a function called translate, I will have it's external parameter as 'by' with the internal parameter being 'vector'. As a simple example:

    func translate(_ origin: simd_float3, by vector: simd_float3) -> simd_float3 {
      // do some stuff
    }

    let newVector = translate(originalVector, by: translatingVector)

cherryteastain
0 replies
7h8m

Even C/C++ have the internal/external mismatch:

// in greeting.h

void greeting(char* for);

// in greeting.c

void greeting(char* person) { ... }

frizlab
5 replies
19h23m

I disagree. It makes the code readable.

makeitdouble
4 replies
18h22m

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
3 replies
16h49m

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
2 replies
15h56m

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
1 replies
15h48m

i agree but you discuss verbosity and not complexity

makeitdouble
0 replies
15h11m

Fair point.

You're right that total complexity across the system fundamentally doesn't change (it's up to the devs and the problems at hand). Local complexity in each part of the system can vary, but the whole will probably always be least as complex as it needs to be.

seanalltogether
1 replies
19h17m

I disagree, I think the more self documenting the code is, the better. It's also nice with code completion because when I start typing a function, I'm given a list of all the overloads for that function, and when I pick one I get all the arguments sitting there ready for me to fill in.

msie
0 replies
17h45m

You still get that with traditional languages that don’t use keywords like java. With Swift you have to read a lot more to get the right function since many vary in the number and type of parameters.

worik
12 replies
19h27m

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...

stevepotter
3 replies
18h49m

I did obj-c on a popular consumer app about 10 years ago. Recently had to make an app. I used async/await and SwiftUI heavily. Used observableobject and actors as well. It’s very nice, much like a React/typescript app. UIs used to be torture

I did have to build some things that I felt should have come standard. For example, I had to build a class that provides a thread-safe way to enqueue objects and process them in a background task, which used DispatchQueue internally.

By and large, it’s a world of difference from what it was and my experience has been joyful. Xcode cloud just worked so that’s cool. Profiling is wonderful (signposts etc). Could there be improvements? Sure. Are there other languages with better features? I think so. But I haven’t found myself longing much for something provided by other languages and platforms

Point is, I no longer dread iOS development. In fact, it’s quite fun.

astrange
1 replies
12h58m

I did have to build some things that I felt should have come standard. For example, I had to build a class that provides a thread-safe way to enqueue objects and process them in a background task, which used DispatchQueue internally.

That is DispatchQueue. Or NSOperationQueue. Or preferablly Swift concurrency.

Most wrappers around dispatch queues are unnecessary and use it incorrectly. (I would say this is true of operation queues themselves.) Swift concurrency is better than dispatch, though.

saagarjha
0 replies
3h59m

Swift concurrency is better than dispatch, though.

For some things, sure.

cageface
0 replies
17h53m

I'm coming back to iOS development after years of doing web stuff. SwiftUI will feel very familiar to anyone that's done React and massively reduces the amount of boilerplate and ceremony it takes to build for Apple platforms. It has some rough edges but overall feels like the most modern mainstream UI toolkit now.

keyle
2 replies
19h18m

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.

tcmart14
0 replies
2h7m

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.

developerDan
0 replies
18h25m

What do you mean? Apple has lots and lots of documentation saying that function signatures exist! (/s just in case)

frizlab
2 replies
19h18m

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.

cageface
1 replies
18h1m

I really like the struct-based method of modeling data in Swift. The language makes this very convenient. Unfortunately the new Observation framework which is at the center of SwiftUI requires classes.

https://forums.swift.org/t/any-future-directions-for-support...

amomchilov
0 replies
1h35m

This makes sense, observation requires a durable identity, which structs don’t have.

Two struct might be the same, but when I observe for changes in one, but not another, a distinction arises which is best captured by object-based identity

zapzupnz
0 replies
14h30m

2005? Swift is from 2014.

jumhyn
0 replies
19h18m

FWIW the concurrency story has been getting substantially more attention over the past couple of years with first-class language support. Swift 6 aims to be data-race-safe by default.

eptcyka
12 replies
19h49m

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.

dcgudeman
6 replies
18h16m

a commercially developed language in that its developers are clearly incentivized to add more features.

Do you have any evidence this is true? Most programming languages are developed either by a company (C#, Java, Swift, Go) or heavily influenced by many companies (Python, JavaScript, C++). Java had been criticized forever (until very recently) for it's slow pace of development and it was 100% controlled by either Sun or Oracle.

Comments like these show just how little developers investigate the reasons why features they personally dislike were introduced to a language.

MBCook
5 replies
14h17m

As a professional Java developer its new feature pace is still slow. It’s a little better but it hasn’t been fast in a VERY long time.

But that’s OK. They do an amazing job of maintaining backwards compatibility and making things fit in the language well as well as trying to get it right the first time.

Some languages are more willing to remove things that don’t work. Others are willing to have multiple different attempts that all work completely differently every few years.

In many ways that’s just not Java’s style. And that’s OK.

tkubacki
4 replies
5h26m

If you want to move faster in JVM world use Kotlin. There is no alternative in .NET world- that’s why JVM ecosystem is much better (and bigger)

pjmlp
2 replies
3h17m

F# would be the alternative.

tkubacki
1 replies
1h11m

F# is not mainstream lang - it’s more like Clojure for .NET. My point was - you don’t have that variety in .NET as in JVM (Scala, Kotlin, Groovy are all relatively mainstream)

pjmlp
0 replies
22m

Kotlin is only mainstream on Android because Google says so, Groovy is barely kept alive thanks Gradle, and if it wasn't for Kafka and Spark, Scala would have been long gone.

Hardly any better than F#.

MBCook
0 replies
4h16m

I’m actually quite happy with how it’s done, but I know many others aren’t.

georgelyon
3 replies
19h45m

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/

jwells89
1 replies
18h38m

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
0 replies
18h10m

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
0 replies
16h48m

I was curious and noticed that this looks reasonable: 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.

zapzupnz
0 replies
14h32m

It’s not a commercially developed language; it’s open source and many of its features have been developed outside of Apple.

wahnfrieden
4 replies
14h23m

Very nice

Do any of these have a good wkwebview equivalent

marcprux
3 replies
13h35m

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

wahnfrieden
2 replies
1h8m

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).

timo555
1 replies
46m

Looks like it is free for your use case. Pricing page[0] shows $0 annual cost for small businesses, which is defined as

Educational institution, nonprofit, or business/individual with less than 250K USD annual revenue

[0] https://skip.tools/pricing/

wahnfrieden
0 replies
14m

Thank you! It is temporarily free with application

jwells89
0 replies
13h22m

Will have to try it to see how well it works in practice, but very cool. I can see this being popular for side project apps written by iOS devs that otherwise wouldn’t have an Android port.

wahnfrieden
2 replies
15h57m

arc released a windows ui for swift lib but it's imperative

kybernetyk
1 replies
4h59m

do you have a link? my google-fu failed me

etaioinshrdlu
9 replies
18h6m

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

pjmlp
4 replies
10h59m

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-Bru...

"What killed the Linux Desktop" 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

One might wonder how things would have turned out instead if the community had been more welcoming of his efforts on GNU/Linux.

masfoobar
3 replies
9h36m

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?

devjab
1 replies
9h11m

I think that most of what Microsoft does today on the developer front is focused on getting enterprise developers ever more integrated into azure. I live in a very Microsoft heavy part of Denmark, and the result is that virtually everyone uses azure and so do we. Take SQLServer as an example, a lot of FOSS database frameworks and orms don’t support it, even though there are some pretty decent Microsoft drivers for most languages. The result of this, when you use azure, is that you’re going to be using a different SQL server, or a different set of tools. It’ll often be the latter because on many enterprise subscriptions running SQLServer is quite a bit cheaper than running any other SQL DB in Azure.

That’s the developer side of things, then on the more operations side of things it’s hard to justify not using Powershell if you’re running a lot of Microsoft products. It integrates very well with everything your IT operations department does anyway from EntraID to Azure Automation, where you may be able to use Python as well, but Python is often not what Microsoft IT operations people “grew up with”. So unless other cloud providers have a strong Powershell presence on their IT operations side of things, using them, instead of using Azure, because a huge change management issue… Often one you can’t really solve, because a lot of IT operations people will rather find a different job than switch away from their Microsoft focused talents, and why wouldn’t they? Good cloud operations people are harder to find than basically anyone else in IT.

robertlagrant
0 replies
6h29m

Given Azure's support for Postgres is pretty good, I would push hard for this in any new projects. Makes you more portable in future, and you can spin up local environments more easily.

pjmlp
0 replies
9h25m

Well, many folks on the FOSS space are to blame, Microsoft has learned by the hordes buying Apple hardware, that what a large majority cares about is POSIX experience and very little about GNU/Linux itself.

As usual, while Microsoft has its own actions to answer for, it isn't alone in making everything happen.

The Year of Desktop Linux comes packaged in desktop VMs, regardless if it is on Apple, Microsoft or Google's hardware.

przmk
0 replies
11h8m

This only targets Gtk3 and not Gtk4 or libadwaita though. Seems a little end-of-life.

tamrix
0 replies
3h40m

You may have started with Vala. An object oriented language inspired by C# complied in straight C.

jddj
0 replies
17h58m

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.

coldtea
9 replies
20h0m

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".

Razengan
4 replies
19h53m

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
0 replies
19h46m

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.

dkh
0 replies
19h2m

It doesn't have to be 100%, but nobody wants to invest a ton of time/energy into a project just to hit a wall a little ways down the road when something at the very core of it breaks or becomes unmaintained. Of course it would be nice for users of such projects to help and contribute, but this isn't always practical. Not because the users are being entitled assholes, but often times they aren't even the same skillsets, and I think this is especially true of some of this complicated, low-level UI stuff. If I'm a user of PyGObject writing GTK apps in Python, I'm not necessarily capable of contributing to the underlying C bindings, even if I wanted to be helpful.

This dynamic presents a legitimate problem for pretty much any open source project that aims to abstract away something very complex to enable more developers to use it. Any project that does this is going to have more developers relying on it than are capable of contributing to it.

You should never feel entitled to continued development of a project you don't contribute to, and you should always assess the community around tools you want to use in order to make good decisions. But this doesn't mean you can't be super frustrated if something you rely on goes dormant. I personally avoid using any library/package that doesn't appear to be very active, but nothing is foolproof. Even a seemingly healthy project die can fairly quickly in certain circumstances.

coldtea
0 replies
18h30m

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.

Or, you know, that's a strawman, and we just want something that exists and is mature, like hundreds of other FOSS people are fine with, as opposed to basing our code on something that is immature, has little community, and will probably be abandoned when the authors get bored with it.

Which has nothing to do with it being "100%" or "perfectly doing everything we ever wanted".

balder1991
0 replies
19h9m

I think the discussion is valid, I don’t see it as complaining. People can create cool things, but you have to weight whether that can actually be used in practice. After all, until AI start writing software for us, maintaining a project takes time and effort. No one wants to see it go to waste.

dkh
2 replies
19h56m

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
1 replies
14h21m

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
0 replies
13h55m

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

georgelyon
0 replies
19h42m

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.

throw_m239339
7 replies
18h2m

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

earthnail
3 replies
9h28m

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.

earthnail
1 replies
8h26m

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.

rubymamis
0 replies
7h46m

Thanks for letting me know! I'll fix that.

Qt Quick (The Qt Company's library that is exposed in QML) is very advanced today. I'm able to do things that would be considered very difficult with Qt Widgets. For example: true drag and drop between items in a virtualized list: https://twitter.com/plumenotes/status/1772599295243440137

Also, they started to work well on native widgets (at least on macOS), for example they support native dialogs, context menus, etc. Very helpful.

I'll probably write a blog post about the development and architecture (some said they'd be interested).

tkubacki
0 replies
14h47m

Flutter

dzogchen
0 replies
17h58m

Qt of course, hands down.

FireInsight
0 replies
11h16m

Imo libadwaita apps are the best, but I haven't found a perfect solution for writing them.

Apocryphon
5 replies
20h1m

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

robertlagrant
3 replies
19h46m

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
1 replies
19h41m

Top comment: "don't follow this tutorial [because it's outdated]" :(

robertlagrant
0 replies
19h36m

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
0 replies
10h54m

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.

l72
4 replies
19h39m

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
3 replies
17h20m

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
2 replies
16h43m

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
1 replies
12h53m

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
0 replies
11h9m

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.

imbnwa
4 replies
20h24m

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
3 replies
6h30m

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
1 replies
3h41m

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
0 replies
3h35m

This is correct

imbnwa
0 replies
3h35m

Oh, I meant the Arc Browser[0]. Wraps Chromium with a Swift GUI layer

[0]https://arc.net/

zengid
2 replies
2h22m

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.

jrsj
0 replies
1h12m

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.

georgelyon
0 replies
1h16m

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.

w10-1
2 replies
17h3m

For another SwiftUI-like wrapper, see also 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
1 replies
14h54m

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
0 replies
14h31m

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.

jamilbk
2 replies
18h55m

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) 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?

plorkyeran
0 replies
12h3m

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.

YmiYugy
2 replies
19h0m

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
0 replies
15h30m

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
0 replies
15h19m

You will need to install libadwaita. Try "brew install libadwaita"

Obertr
1 replies
6h14m

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
0 replies
5h36m

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

FireInsight
1 replies
8h23m

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 is the only thing I find comparable.

elcritch
0 replies
6h16m

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.

vi4m
0 replies
8h32m

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.

tschumacher
0 replies
10h1m

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).

tripdout
0 replies
5h12m

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

pona-a
0 replies
8h15m

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...

nurettin
0 replies
5h23m

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.

nickwarren
0 replies
6h16m

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!

keyle
0 replies
8h2m

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.

accurrent
0 replies
13h26m

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

QuantumG
0 replies
18h22m

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?