I have some thoughts on the future of on non-mobile devices and the role that 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.

image/svg+xml Follow

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.

6. Finally, we need to constantly look for the future. According to the cyberpunk theorem, that the future is here but just unevenly distributed, we can find and accelerate parts of the future we want and decelerate those we want to avoid.

7-ish. I think one of the important value propositions of good FLOSS is precisely that it isn’t market-oriented. It can target segments that are not profitable, but more importantly it can offer software as democratic participation, or, if you can bear the Marxism, non-alienated computing. Doesn’t mean it always does, but it can, and should.

It’s one of the few cases where @doctorow’s Walkaway principle, which only works in the presence of abundance, probably works for real.

@doctorow It doesn't have to be market-oriented, but still product-oriented. As in: the whole package of functionality, design, quality assurance, documentation, user support, release planning, community management and public communication has to be consistent and clear. The best FOSS projects are run like commercial products. But most aren't.

@Sturmflut I didn’t see this at first but I think I, am avid Marxist, would agree. The core difference I see is in participation and influence.

@albin all great points. I would add “platform independent” and “language agnostic”. Don’t try and invent yet another language, there are plenty already that are very good at what they do. and a way to make money/get funded wouldn’t hurt, provided it’s not the primary goal.

@Tryphon absolutely, but those are different and perhaps even harder problems, though I suspect things like Patreon and/or app subscriptions could work. I suspect people would be much happier paying a recurring fee for software where they feel like a part of its community and can see its ongoing development

@albin Have you seen @HerraBRE and the Mailpile team's "gui-o-matic" library? I've only barely glanced at it, but iirc it's trying to be dialog-but-for-GUIs? Which might be partway to one type of thing?


@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 #Linux. #KDE'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 I’m looking for things like even just a widget gallery online and how to do very common patterns (a list with things populated from whatever standard data store you have).

I think C and C++ are both too weak and too verbose for GUI programming. Neither have language constructs for dealing with concurrent programming, and extensions are often very clunky. Vala might work, I don’t know.

@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

@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

Show more
Show more

@albin it's not a GNOME-wide official decision or anything like that.

A lot of people in the GNOME community are experimenting with Rust, and writing platform libraries and applications with it.

There is even some collaboration between those GNOME developers and the Rust community, in the form of hackfests gathering the two.

@MatejLach @alcinnz

@MatejLach @albin @alcinnz

Python is a nice language, but it *does* have a lot of weaknesses. i think Golang is a better choice for "easy to pick up and use" than Python. first off, its a million times easier to distribute (one static binary), the memory overhead is much smaller, and you can easily do multicore concurrency if you need to.
@MatejLach @albin @alcinnz

honestly tho, making things simpler to interoperate with and understand in a holistic way is more important than the lang you are using. even if there are advantages, its always easier to work in a language that you already know than to learn a new one.
@xj9 @MatejLach @albin @alcinnz Also, sort of subjective, but Python 3 (at least to my eye) seems to have grown many times more complicated and less approachable then Python 2 and I think that Go comes closer to capturing the 'feel' of Python 2 then Python 3 does.

@devilish I always felt 3 addressed some mistakes in 2 (mainly Unicode), is there anything in particular you have a problem with? The things I would like to fix in python these days is mainly packaging and tooling (virtual environments), and the boilerplate needed for async.

@albin To be fair, it's been a decade since I've worked with either, but I remember removing the functional bits was kind of irritating and some of the other syntactical stuff tripped me up. That being said, UTF-8 is the logical choice and I'm glad Python developed in that direction, even if it did take a breaking language change to do it

@devilish most of the functional stuff is still there in various modules, but generally discarded in favour of list comprehensions, but I see your point

@devilish @alcinnz @xj9 @albin

I'd prefer a statically typed language that simply compiles to a native binary, the reason I said Python is because that's the only thing Qt officially supports besides C++, making any other language rely on 3rd party libraries, which are not going to be as well supported as the official bindings by their very nature.

@MatejLach @albin @alcinnz @devilish

ok that makes sense. i wouldn't touch Qt myself, way too complicated. something like nuklear.h is a lot easier to wrap your head around.

@MatejLach Python can compile to a binary if you just bundle the interpreter and standard libraries taps head @albin @xj9 @alcinnz @devilish

@albin @MatejLach I'm very interested in why it is you've found it unbearable (not that I really disagree... but then I wouldn't agree either)

Are the languages (objc, Swift) hard to learn/use? Is the tooling bad? Not enough docs? ...

@bugaevc @MatejLach I have only ever tried swift, but I dislike Xcode (and all IDEs), and I couldn’t find documentation for anything, including things like basic project structure and what even the basic code temples do, and there was a horrendous amount of boilerplate code and incidental complexity

@albin @bugaevc

Swift was created because ObjC is showing its age, rather crufty and it's not that pleasant on the eyes either.

From my own experience, having tried it myself, Swift is actually rather nice to work with. The problem is that Swift, the language, is a small part of the picture.

Most of the time, you'll spend time with Mac's frameworks, which were not made for Swift's functional paradigm, they're still the same old ObjC, wrapped in extremely thin, unidiomatic Swift wrappers.

@albin @bugaevc

So you have this nice, modern language - Swift - but you rarely get to write it idiomatically or allow for its expressiveness to shine, because you're constrained by Cocoa/AppKit, which are very much 80s OO.

Then there's the whole thing about Apple having very deliberate patterns, which also don't mix well with Swift, that you need to follow, Xcode constantly loosing syntax highlighting & requiring you to fiddle with settings that are hard to find, Storyboards being a mess...

@MatejLach @albin imo the issue with gnome 3 was (is?) their focus on developing their own "brand" and being hostile to extensions and theming. at least in the early days. also they kept breaking back-compat a *lot* in the early gtk3 days. igurublog.wordpress.com/2012/1

@trwnh I think from my perspective (that is, the overarching project I described) Gnome is really at least two projects; one of them is the construction of infrastructure for making a DE/GUI apps, and one is making a DE/a number of GUI apps, which is (and must be) opinionated.

@albin well... opinionated shouldn't mean preventing other opinions. there certainly is an issue with having GTK be so dependent on GNOME.

Really though, the issue isn't limited to GNOME, obviously. I think we need a lower-level framework that's more generalistic if it hopes to receive any sort of actual adoption. There's only so much we can accomplish by making bindings to Qt...

@MatejLach we're working on exactly that in GNOME. Builder and Flatpak in particular are big parts of this work.


@mathieu I saw, and I'm looking forward to seeing the results. Do you also work with the KDE people on this, or do they have their own version?

@albin KDE is working on Flatpak as well: they have their own runtime to build/run their applications, and their "software center" (iirc it's called Discover) can install/update/remove Flatpak apps.

I have no idea what else they are doing, you'll have to ask them. 🙂

Sign in to participate in the conversation
Scholar Social

NOTICE: Registration on scholar.social is open to anyone who is willing to abide by our Community Standards. Email scholar dot social at protonmail dot com if you want an invite!

Federated microblogging for academics

Scholar Social is a microblogging platform for researchers, grad students, librarians, archivists, undergrads, academically inclined high schoolers, educators of all levels, journal editors, research assistants, professors, administrators—anyone involved in academia who is willing to engage with others respectfully.

We strive to be a safe space for queer people and other minorities in academia, recognizing that there can only be academic freedom where the existence and validity of interlocutors' identities is taken as axiomatic.

"An academic microblog that you can be proud to put on the last slide of a presentation at a conference"

"Official" monthly journal club!

(Participation is, of course, optional)

Scholar Social features a monthly "official" journal club, in which we try to read and comment on a paper of interest.

Any user of Scholar Social can suggest an article by sending the DOI by direct message to @socrates@scholar.social and one will be chosen by random lottery on the last day of the month. We ask that you only submit articles that are from *outside* your own field of study to try to ensure that the papers we read are accessible and interesting to non-experts.

Read more ...