Consolidating the Linux Desktop App Story: An Idea | Hacker News Reader

Consolidating the Linux Desktop App Story: An Idea

jonobacon.com

36 pointsjonobacon62 comments

Unpopular opinion: Ditch everything GNOME, glib, vala, GTK and focus on making KDE, Qt, QML first class software. QML is powerful and is quite fast and can at least be made fast. KDE needs UI and design polish but the foundations are IMHO more sane than GNOME ever was. Move the good stuff from GNOME over to KDE. E.g. kio-slaves and gvfs should be one stable solid pluggable piece of software. And document that well - Good tools are already there - Qt is documented, QtCreator is usable, KDevelop is fine software - merge the efforts to make that platform fast and sane and secure. Also please stop that CADT stuff[1]. Won't happen, but one can dream.

1: http://nullrefer.com/?www.jwz.org/doc/cadt.html

Edit: jwz doesn't like hacker news. removed referer.

FWIW jwz redirects to something unfortunate, here's the same page via nullrefer.com which seems to do the trick:

http://nullrefer.com/?www.jwz.org/doc/cadt.html

and on archive.org:

http://web.archive.org/web/20170702194030/https://www.jwz.or...

Thank you! Didn't saw that.

BTW: Miguel, Gnome creator, now officially works works at MS

First Qt would need to be written in C so it's usable from other languages. The list of broken Qt bindings is much longer than the list of working ones. That or the language bindings need to be part of Qt itself so they can be maintained instead of abandoned.

Qml is an awful xml+javascript layer on top of qt that adds nothing but unnecessary complication to building UI's. Using Qt directly is much simpler.

> QtCreator is usable

Funny, last time I tried it was literally unusable. The new project dialog expanded beyond the height of the screen and all I could do was kill the process.

Would agree to an degree, but KDE is adopting more and more Gnome-isms at the plumbing level as they do not have the deep pocket backing that Gnome has via Red Hat.

I really don't understand the drive to make GNU/Linux a "consumer operating system." The consumers don't care and are happy with absolutely awful software. Shiny GUI toolkits that are a huge pain to develop for, and non-free software gos against what the people who use GNU/Linux now want. That's why ubuntu's unity stuff failed, because they chased after users who don't care and alienated the only ones that might use their product.

It's because Linux desktop users want to be able to use consumer software, and the only way they're going to get it is if Linux becomes a consumer operating system

Yes! Developers are people too..

I don't see anyone here who suggested they're not?

Linux desktop has mostly been about using free software IMO. If you don't care about your freedom, why not run macOS?

Most vendors of non-free software do support macOS (or viable alternatives are available). I strongly doubt many of them will even come to Linux. Because it requires more standard configurations. Apple had to make its main FS case insensitive before vendors like MS and Adobe were porting their software.

I like having my own choice in configuring my system. That amd freedom is why I use Linux desktop.

A small nit here: the Mac has been case insensitive since 1984 and AFAIK Adobe actually started on Mac.

But yeah, the main justification for an open-source power-user desktop OS is a backup plan in case macOS dies, which isn't a very good business case.

> Shiny GUI toolkits that are a huge pain to develop for, and non-free software gos against what the people who use GNU/Linux now want.

This is a yuuuge generalization. There are many Linux folks who want a slick consumer experience and there are many that want ratpoison and vim. :-)

This idea doesn't take away from the requirements that people have for a non-consumer desktop.

I was rolling my eyes reading this and then hit this, which is the real value of the article IMO:

> few Linux platforms (if any?) had taken a series whack at building a consumer grade app and developer experience. We tried, it was not successful, and instead of digging up the past I would rather ensure we can inform the future.

"What not to do, and how not to do it" are at least one valid take away from that whole era.

One of the big issues with their attempt was ~0 support or documentation for porting existing applications. Everything was focused around building an Ubuntu app from scratch using their custom qtquick-based SDK, but that's not what we needed.

edit: for more info: This guy made a beautiful summary of the issues with the dev experience around Ubuntu (Touch): http://www.lieberbiber.de/2017/06/20/my-ubuntu-for-mobile-de... [starts from 6. "The life of an app developer was too hard."]

Since this thread is about the desktop, don't existing GNOME apps just work under Unity Desktop?

Yes generally all apps designed for any desktop environment just work in others so long as supporting libraries are installed.

A few points of division are pulseaudio and wayland. Pretty much everybody now uses pulse and while most apps will work in wayland I don't know of any that require it yet.

The biggest takeaway from the era is that no one fucking bothers to write software for 10 different distributions with 15 different ideas on how the most trivial of things are to be accomplished.

And here is this guy wanting to build number 16. There is an xkcd on this. This train has left the station.

Nah, almost all mainstream (and even most non-mainstream) distros are basically equal. Seriously, maybe I'm wrong but I don't think that's an issue.

As long as your distro doesn't replace glibc for e.g. musl or bionic, and has all the usual GNU (and X11, and DBus if you need that) userland, i.e. no odd stuff - there is no much difference. Most of the time things just work. Normally, the only time you'll have to "write software for some specific distribution" is when the distribution is unusual in its ways, but you still want to target it.

That is, unless you need to target some specific library version that's higher or lower than the usually available, incompatible with the usual version, and you don't want to have a statically-linked release variant. E.g. something that would work only with Qt5.2 but not with Qt5.6. Don't see why not to just throw it all in a tarball and call it a release. Saw this done many times, I just unpacked it, ran it - and it worked.

And that is if that's you who package your software. Usually, some user just takes it further and becomes a maintainer (or a co-maintainer, or just a volunteer who submits patches).

> That is, unless you need to target some specific library version that's higher or lower than the usually available, incompatible with the usual version, and you don't want to have a statically-linked release variant. E.g. something that would work only with Qt5.2 but not with Qt5.6. Don't see why not to just throw it all in a tarball and call it a release. Saw this done many times, I just unpacked it, ran it - and it worked.

In this hypothetical (I hope) example, you've just subjected your users to unpatched vulnerabilities like this one: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0190

Did you actually read the post? I am not suggesting anyone builds anything new, instead that we are realistic in how much work is involved and distributions consolidate around something that already exists.

He advocates flatpak, which is basically desktop Docker. You package all your dependencies so you can choose any of the 15 to put inside your flatpak, and it'll work with any of the 15 outside your flatpak.

You get the normal trade-offs for this approach -- large downloads, disk space, slow security updates, UI inconsistencies but XKCD 927 doesn't really apply.

Does everyone nowadays only write software that is some messy desktop rendition of a website?

The kind of software I write doesn't exist in a vacuum where all it needs is to run AMD64 code, Linux syscalls and a canvas to draw on. It needs to interact with the system, figure out what drives you have inserted, play nice with keychains and whatever..

You can't flatpak that.

Why not? flatpak has access to devices.

Sorry, but I believe this effort is doomed to fail if you don’t provide compatibility with the open web. It is the only online app distribution environment that has really thrived, other than Apple’s and Google’s.

Of course you could do this easily with electron apps. Too much bloat? Fine- go with a ReactNative/NativeScript approach with a JS VM controlling native UI. Hate JS? Fine- compile to it from your language of choice. Refuse to use a runtime? Fine- compile to webassembly. There is no excuse for not having compatibility with the open web.

As a developer, I have no interest in building for Linux- I need to go where the users are. But if I can develop a nice web app that can be deployed natively to Linux and mobile platforms- sign me up!

The big problem with web apps as first-class citizens is UI inconsistency. What I love about native desktop apps is that they should all follow well-defined user interface guidelines and all use the same toolkit/theme. With web apps, you don't get that - every web app uses its own fonts, its own styles, its own UI structure and navigation.

But no major desktop app [1] follows the guidelines because they think branding and novelty trumps consistency.

[1] Except apps written by the OS developer.

> [1] Except apps written by the OS developer.

I assume you mean apple? Because even the apps built into windows 10 are completely inconsistent with one another or any platform standard.

Meh, the real problem is bloat (in memory and CPU cycles) and integration with the larger ecosystem.

the web has been developed to exist inside a browser, not on the desktop.

The real elephant in the room is not a single platform, we already have that (Linux+Gnu+X11).

What is missing is STABILITY. The kind of stability we see over at Windows where win32 binaries from the 9x era can run on Windows 10.

The kind of stability one have achieved with the bedrock of Linux (and that Torvalds gets ragged on for defending), but that the DE devs piss on every time they make a new weekend project.

App stores are a distraction, single platform (more like distro monoculture, it seems to me) is a distraction, And Gnome+Wayland is the last people you want to entrust with anything related to stability (you can get Qt working on things that get GTK screaming about missing dependencies).

Correct me if I am wrong but wouldn't the best move forward just be supporting and tuning https://electron.atom.io to make it more performant and supported on linux? Yes it is a battery killer, but I can see it being better if everyone put their tasks to making that a non issue.

edit: why the down votes? This is a platform agnostic framework. I understand the performance is bad, but the one reason that linux doesn't have the same applications as windows and OSX is the window manager. A lot of amazing apps have been created using electron which has allowed people to even remotely think about moving over.

Programming languages or platforms aren't the issue. Software packaging and distribution is. Porting is easy. Getting your software to users is hard.

Look at the Minecraft pocket edition (and its Windows 10 respin), one of the devs said that it would be trivial to port that to desktop Linux but they would have to set up their own payment and distribution system, which just isn't worth it for that tiny market.

Github, Gitlab, Bitbucket, it would be great if these platforms had an option to allow non-technically users to install software from them. It would eliminate the need for developers to push to a software platform.

Browser-based apps still kinda suck. Battery-wise, UI-wise in terms of integration, accessibility-wise, etc. And they're a huge step down in programming language availability vs native apps.

Exactly. If using Linux means getting stuck with apps that are horrifically slow and your battery life is awful, whereas just switching to Mac or Windows eliminates these problems, that's not going to make Linux a very attractive alternative.

Most languages have the option to compiling to JS, all I am suggesting is that electron be the framework that people target. Having language support is possible by extending that framework.

Transpiling just makes things more complicated. You have to know your own language, the target language and how all the idiosyncrasies are converted between the two. I delivers the worst of every world.

Bad for battery and ram. Fixing this is probably difficult to impossible. I have 10 apps open imagine if they were all using 1-2GB of ram.

Maybe something like Go + the system web view. Only question is what is "the system web view" in Linux.

The issue is that electron is running a new chromium process for each application. This could be fixed easily sharing that process and making chromium more resource friendly.

And go back to the 80's where one app crashing can take down the whole system? No thanks. Apps would be able to overwrite each others memory then too, you'd get the full Amiga experience.

So make the singular processes run in a tighter sandbox where performance is necessary

Once you sandbox that much you've just reinvented processes.

> Fixing this is probably difficult to impossible.

It is absolutely possible to make a browser engine-based shell that is more efficient than Electron is. Electron has the wackiest setup imaginable, mashing together Node and Chromium, with two versions of V8 to boot.

That is what I am talking about. Who is making this happen!?

It seems like this would end up being very similar to Chrome OS. Presumably people are still using a "real" desktop instead of Chrome OS because they do not want this HTML+JS-based future.

I would like to see the main distros collaborate on/ invest resources in an IDE for GNOME or w/e desktop environment they choose to standardize on. Seems like there is one already but I don't know how actively it is being developed (https://wiki.gnome.org/Apps/Builder).

I still think the whole Linux Desktop problem can be summarized in one sentence:

There is a lack of a simple desktop app development environment.

Yes there is GTK and yes there QT. But regardless of how much people may hate Xcode, it allowed people to create solid desktop applications in a fraction of the time that was needed to do the same in either GTK or QT. It's better documented, it's smoother, it's easier to structure your application in terms of the framework rather than programming language.

The whole thing is a little like the Rails vs. Flask or Go argument. Yes Flask is really cool, and in Go you can build really cool stuff and it's modular, you select a muxer and stitch it together, it does more requests per second, but if you just want to bash out a quick web application you're better off picking the first option.

The app store is hard argument is so far down the line... If you look at all the things Apple did before they pushed their app store it almost doesn't matter.

I agree. I commented earlier about how I think they should pool their resources to create an Xcode for linux. Seems like one kind of already exists (https://wiki.gnome.org/Apps/Builder) but I don't how much is being invested in it. And honestly I don't really care that much about the language or the UI framework so long as they just pick one.

That looks like glib. Which is kind of nasty in my opinion. At some point they pushed for Vala, it makes the whole thing a bit more pleasent. But personally I had a feeling it was on life support the entire time. Some bindings were plain broken and impossible to fix, interop had really crappy documentation. At some point I just gave up.

(I'm mixing IDE with language/lib right now, but for Gnome it does go hand in hand IMHO)

With the flatpack integration, Builder really has the potential to become the Xcode for Linux.

I hope that Ubuntu starts to support Builder. Ubuntu tried something similar with qtcreator and the Ubuntu sdk, but that was a really bad experience. Let's hope that the switch to Gnome also means that Ubuntu switch their efforts to Builder.

flatpack solves a deployment/distribution issue. distribution is irrelevant when you have nothing to distribute.

The biggest issue is the distribution.

One of the devs of the Minecraft Windows 10 edition said that it would be trivial to port that to desktop Linux but they would have to set up their own payment and distribution system, which just isn't worth it for that tiny market.

Having packaging and distribution built into an IDE goes a great length to solve that issue.

Except they could throw it on to Steam for Linux - it's a business decision not to put it on there and let Valve take 30%.

I hope so, but honestly I feel like they are trying to keep it too general. I was looking at some of the critical components like Glade (https://en.wikipedia.org/wiki/Glade_Interface_Designer) and noticed this: Glade is programming language–independent, and does not produce code for events, but rather an XML file that is then used with an appropriate binding (such as GtkAda for use with the Ada programming language)

Maybe Ada is more popular than I know, but I would think it's more valuable to spend time making the development process better for C++ devs (or w/e) than build a system so general that it can support Ada.

Red Hat have been sponsoring Christian Hergert (https://blogs.gnome.org/chergert/) to work on Builder full-time for a while now, with a specific focus on Flatpak integration, and there are other contributors, including GSoC students working on specific features.

The missing piece is public server infrastructure for accepting Flatpak packages from GNOME Builder and distributing them to GNOME Software clients, and that is currently in development as https://flathub.org/

There are a multitude of different dev environments I don't think we need a new one that will probably have less effort invested than current popular environments.

Racket is well documented, has a well working (if slightly heavy) IDE, and packages an app by running "raco exe" (Around 6.5 mb for a "HelloWorld". That could be worse.). And you can package for Windows just as easily using Wine. I've found the error messages of Racket very friendly also. It has never been easier to build GNU/Linux Desktop Apps.

http://racket-lang.org/

Extremely easy to do GUIs, and they have weird DSLs, for example for video editing and shell scripting:

http://docs.racket-lang.org/video/index.html http://docs.racket-lang.org/rash/index.html

> There is a lack of a simple desktop app development environment.

Does anyone think that Xaml Standard + GTK + dotnet core might be a potential path forward? Supposedly Microsoft is working on a GTK implementation, and very much intrigues me.

edit: Discussion here http://www.xamarinpodcast.com/41 21:30 - New "backends" for Xamarin.Forms - macOS, GTK#, and WPF

Something of a dark horse for now, but there's Flutter. Maybe if it succeeds on mobile they'll add the missing desktop widgets.

It is foolish to pursue consumer space in this age. The muggles want mobile.

This is a wonderful opportunity for us original computer nerds... with the mainstream leaving for their terrible mobile devices computers can finally go back to being tools for power users. The appliance-like expectations of the mainstream was the worst thing that ever happened to traditional computing.

In some ways, I COMPLETELY AGREE. UI 'cleanness' killing 'functionality' is so late 2000's, please. Let's move on. I use my box professionally and need to get shit done. I don't need bouncy. I don't need address bars that hide things and make it non-copyable. Yes, date-modified is a useful sort. Don't hide it like MS did. Yes terminals are awesome and should be front and center. Don't hide them and pretend they are embarrassing and try to hide them under some menu.

But in other ways I disagree. There are plenty of options for the power-user to adapt their environment right now. How are we hurting? (Unless you are corporate and they restrict you to some gimped UI.

Reply on news.ycombinator.com