I have some thoughts on the future of #UI on non-mobile devices and the role that #FLOSS can play.

1. It seems that all proprietary software companies are de-prioritising their desktop OSes, in terms of focus and resources. Microsoft is doing weird tablet hybridisation and Apple is just porting iOS junk back from the iPad.

This creates a vacuum, as there is no modern desktop UI. Nothing's been done since roughly OS X. It's been 18 years. More than my whole adult life.

2. There will be very little financial incentive to fill this vacuum. Desktop OS:es only sell to the enterprise, which has different requirements, and Microsoft has that market cornered anyway.

No-one who is making software purely for money would be able to do this. Well, we, the FLOSS community, aren't, and so we can.

3. In order to do this, we need to experiment. A lot. And most of these experiments will probably fail.

For that to happen, the cost of development in terms of time and cognitive load must go down. Much like Rust seems to have enabled a wave of new command-line tools that are faster and much less boring than the traditional Unix tools. Making a GUI app must be roughly as complicated as making a CLI app.

4. This requires languages AND frameworks. The languages need to remove the incidental complexity in dealing with the concurrent situation that is a modern UX app. The frameworks need to encapsulate common patterns and remove boilerplate.

The languages are mostly there, I would argue, and the patterns are somewhat implemented (functional reactive programming, Excel, etc), but the frameworks are not just a little behind.

5. We also need to train FLOSS people in design AND recruit design-oriented people who may or may not code. This might also entail developing our tools for communication and infrastructure to also capture common workflows in design. I don't know, I'm not a designer.

@albin Agreed. We do experiment a bit, i.e. GNOME 3, but then that generates a lot of heated discussions etc.

I think we have fairly decent desktop UIs now. They should keep evolving for sure, but what we should focus most of our energy on is a Mac like developer experience for desktop aps, i.e. developing an unified set of APIs with lots of complex functionality prepared as part of a SDK for developers to tap into. On Mac, there's AppKit, which is why all the independent desktop apps are Mac.

@MatejLach I have tried app development on the Mac and found it unbearable, but I agree, sort of. It’s a trade-off between exploring new things and improving the ones we have, but I don’t think they are in fundamental conflict.

@albin Agreed. I tried it too and didn't like it, but that's mostly because there's a lot of legacy stuff back from NEXTStep days, (a lot of APIs are even still named NS), which is not idiomatically integrated with Swift as ObjC doesn't really fit that model. But that wooudn't really be a problem with Linux if said frameworks were build from scratch. The point is, bellow the cruft, Mac has the most complete set of APIs to tap into for desktop dev, (in terms of functionality, not elegance of use)

@albin The reason why the likes of Sketch, Scrivener etc. are on the Mac is because of all that ready-made functionality you can tap into, which there's no real equivalent on . 's trying it a bit with their split into frameworks, but that's largely tied to C++ because of Qt a bit too strongly and also tends to be specific to the KDE ecosystem.

If you look at all the functionality here, developer.apple.com/documentat - Linux does have most of it, but not nicely documented or unified.

@MatejLach @albin There's certainly all the libraries you could need though, so really it's just a matter of bundling those together into useful groups.

@alcinnz @albin

Yep. It might be as easy as making a simple 'orientation index' of what's available, because a lot of devs coming from integrated experiences like on the Mac are simply not sure where to look for the stuff they'd expect when developing for Linux.

I also happen to think we need a secondary choice/alternative to program in - something a bit more accessible to people than C/C++.

Qt now has official Python bindings so I think it would be useful for KDE to adopt it as well.

@alcinnz @albin

GNOME/GTK/GObject has Vala, but they seem to have shifted towards Rust now, so hopefully it'll become a first class citizen in their docs as well soon.

@MatejLach @alcinnz WHAT?! They are going with Rust? OMG I didn't know. That's AMAZING!

@MatejLach @albin I'm glad to see them moving towards dropping their ugly GObject system and towards a language that's offers what they neeed.

That said Rust won't be a simple transition and I'm sure it'll take a while, it's interpretation is a fair bit different from what they based their APIs on. Until then I may continue to see Vala as the best choice for developing GTK apps.

@alcinnz @MatejLach @albin wait, what? GObject is not ugly (if cumbersome to write out in C), and no way they're going to drop it

Follow

@bugaevc @alcinnz @albin

I think they've invested too heavily at this point in GObject to simply entirely drop it, it's far more than a OO system at this point. I think what they're going to do is to have wrappers around it that hopefully make it a more pleasant experience to write and maybe build Rust-native parts for the new libs etc. that will feel even more idiomatic.

@MatejLach @bugaevc @albin I can't disagree. And Vala fills the need for those wrappers very well.

Definitely will be an interesting transition to watch!

@alcinnz @MatejLach why are you talking about it as if there was some grand decision to transition from GObject to Rust?

As far as I understand it, some GNOME folks ( @federicomena, @slomo, @alatiera, ...) are interested in Rust, use it in some projects (librsvg, GStreamer plugins) and are working on ways to use GObject-based libraries *from* Rust (gtk-rs) & write GObject-based libraries *in* Rust (gnome-class); and that's it.

@bugaevc @MatejLach @federicomena @slomo @alatiera Fair enough, I still need to watch the linked talk. And probably should be more sceptical when hear of "grand decisions" from GNOME.

@alcinnz @bugaevc @MatejLach @federicomena @alatiera

Where did you get that part about "grand decisions"? There's no CEO of Gnome who decides that everything's going to be done *that* way now :) People do the work they want to do (or are paid to do), and that's how things move forward.

@alcinnz @slomo @MatejLach @federicomena @alatiera @bugaevc I just want to add my 50c:
as an ex-iOS dev I can say that developing for Apple is a pain. AppKit is such a nightmare, they're porting UIKit to macOS. No one sane even wants to touch default database, what are the super APIs you're talking about. There are desktop apps for mac because people who use mac are used to pay and a lot and UI people use it

@alcinnz @slomo @MatejLach @federicomena @alatiera @bugaevc ..
GObject is not ugly. GObject introspection is a very elegant system which allows you to write code in whatever you want, including Rust using generated bindings. We're only now coming to the same things with WebAssembly.
No one should write gobject apps by hand in C IMO but that doesn't mean it's not useful

@charlag @alcinnz @slomo @federicomena @alatiera @bugaevc

See i.e. sketch.com/support/requirement

"Due to the technologies and frameworks exclusive to macOS that Sketch has been built upon, regrettably we will not be considering supporting Sketch on either of these platforms."

I am not saying they're pretty to work with, but there's no denying that AppKit, Cocoa etc. provide a large set of functionality to tap into that while available on other platforms as well, is only really unified on macOS.

@MatejLach @alcinnz @slomo @federicomena @alatiera @bugaevc I read that as "we could only afford to build it for macOS and now porting just doesn't worth it because we're knee-deep in Apple stuff".
I doesn't see any value in there, they just used non-portable stack from the beginning. Would be nice to hear what is so irreplaceable they use if you're right.

@charlag @alcinnz @slomo @federicomena @alatiera @bugaevc It's not just them, it's Scrivener, PaintCode, Ulysses etc.

I don't think anything there is technologically 'irreplaceable' in a technical sense. It's just that there's one SDK, using one language, conforming to the same set of patterns, accessible from a singular IDE etc.

It's not that there's something that Apple has that the other platforms don't. It's more like if you're a small shop, who has it all under one roof?

@charlag @alcinnz @slomo @federicomena @alatiera @bugaevc As in there's basically no need to browse GitHub for external libraries most of the time, no need to use multiple languages, it all has the same documentation format, it's all updated uniformly/at the same time, it's all installed as part of the one SDK etc.

It's actually really surface-level stuff, mostly convenience, which is good, because it means it's not that difficult to replicate the experience on Linux.

@MatejLach @alcinnz @slomo @federicomena @alatiera @bugaevc well I see no point of digging the ground here, we both believe pretty strongly in what we say and probably have our reasons to say it (for me it is pain of working with Xcode/iOS). I just want to link Ash'es blog where he had many posts about it and where he compares this "we take care about thus" approach with OSS one
ashfurrow.com/blog/apple-relea

@charlag @alcinnz @slomo @federicomena @alatiera @bugaevc

I am actually not disagreeing with you, I don't like the Apple dev experience either. I am only stating what I've observed to be the reason for many independent desktop apps to be on macOS, (and yes, many paying users also also there, but they're there because the apps are there).

That's why I said, the solution might be as simple as having a portal for new developers on the Linux desktop, pointing them to the right places.

@charlag @MatejLach @slomo @federicomena @alatiera @bugaevc I understand they're situation, because for Odysseus I couldn't move away from WebKit (ironically here, an Apple lead project) if I wanted to. It'd be easier to rewrite it all from scratch!

Because almost every piece touches WebKitGTK's API, or if not that GTK's.

Though I'm not complaining, WebKitGTK is a nice piece of libre software that will at least run cross-platform.

@MatejLach @charlag @alcinnz @slomo @federicomena @alatiera @bugaevc PS. Ex-macOS Sketcher, now very happy with a subscription to Gravit Designer on Linux – it’s rather excellent ;)

Sign in to participate in the conversation
Matej Lach's mastodon

Hi there! I am a free software developer. I enjoy working on useful software, as well as advocating for software freedom and the use of open standards, promoting data ownership, decentralization and privacy. If this is important to you, I may be worth following. If you like Go, Rust, or Swift, it may be worth following me as well. Besides computing, I enjoy metal, a good read and occasionally some gaming, (not much time for that these days).