Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Make Apps for Linux

makealinux.app

Post reply on HN
Print view View original

341–350 of 422 posts

Re: Make Apps for Linux

#341

Post by hnlmorg »

sph wrote: post #324
hnlmorg wrote: post #233

Earlier quoted context omitted.

People with actual design education created macOS and Windows 11. Both of which strip back features in the name of design purity. I see KDE more like a professional piece of equipment. And when viewed through that lens, I think it’s designed rather well.

It is very naive to believe that professional equipment do not benefit from well-thought design and UX. Design does not have to be fancy colours and flashy animations. Design does not mean Fisher-Price UI and massive amounts of whitespace. Ask Dieter Rams.

> It is very naive to believe that professional equipment do not benefit from well-thought design and UX.

I know. I never claimed otherwise.

> Design does not have to be fancy colours and flashy animations. Design does not mean Fisher-Price UI and massive amounts of whitespace. Ask Dieter Rams

I never said it did. You’ve completely misinterpreted my comment.

My point was that commercial operating systems have design specialists and the end result is they suck for a great many professionals. Whereas KDE, despite “not having a design specialist” (I don’t actually know if that’s true, just quoting the GP) feels like it has the same well thought out design that specialist technical hardware does.

I’ve worked closely with designers (because I have zero design skills myself) and seen first hand how an arguably less beautiful design can actually be more intuitive for users

So at no point am I claiming that design is just about fancy graphics. If anything, I’m making the same point you were.

Re: Make Apps for Linux

#342

Post by arp242 »

pjmlp wrote: post #336
mkup wrote: post #329

Earlier quoted context omitted.

Much of the Windows compatibility is "just" stable API for Windows controls, GUI event handling loops, 3D graphics and sound (DirectX). Linux has stable API for files and sockets (POSIX), but that's all.

This is also the biggest different between proper desktop operating systems since forever, and the fragmented Linux distributions. Available API means the whole stack, everything needed to write applications end to end, regardless of their purppose, not CLI and daemons.

And I am saying you don't need to rely on any of that. You can just ship it yourself (statically link, or use LD_LIBRARY_PATH). That's what Windows applications that rely on GTK or Qt do as well, and it works fine, which works well, and it works fine for Linux too. The basics (libc, libX, etc.) are stable, and the Linux kernel is stable.

And this is what Windows does too really, with MSVC and dotnet and whatnot redistributables. It's just that these things are typically included in the application if you need it.

It's really not that different aside from "Python vs. Ruby"-type-differences, which are are meaningful differences, but also actually aren't all that important.

Re: Make Apps for Linux

#343

Post by oritsnile »

I recently tried to create an executable from a Python script, Mac and Windows worked wonderfully, on Linux I had massive problems when I tried to run it in a different system then it was packaged. Linux caused the most problems, in the end I decided it was not worth it, 99% use Windows or Mac anyway.

Re: Make Apps for Linux

#344

Post by hulitu »

zer0zzz wrote: post #34

I think the premise is wrong when there still doesn’t exist a core set of frameworks that are abi stable on Linux. On competing platforms there are way more frameworks out of the box (CoreImage, CoreAudio, CodeML, SceneKit, AppKit, etc) and they don’t break as often. I know in Linux they have fun things like snap and flatpak but it is really solving the problem using a bit of infrastructure and package management ins…

> there still doesn’t exist a core set of frameworks that are abi stable on Linux

Motif ?

WxWidgets ?

Openstep ?

Gnome and Kde do reinvent the wheel with every release, but they shoouldn't be taken seriously.

There is a general problem on the SW world. They like to reinvent the wheel every now and then.

Re: Make Apps for Linux

#345

Post by emptysongglass »

Longhanks wrote: post #252
emptysongglass wrote: post #214

There's a lot of complaints that there isn't much in the way of tooling to create cross-OS compatible apps but I disagree. Just looking at solutions which aren't Electron: - Telegram uses Qt and ships a performant native app across all three OSes - Flutter compiles down to native code across all three (and mobile) - Kirigami is a QtQuick framework that will give you an executable app across all mobile and desktop tar…

Except Flutter is a subpar experience on every platform because of just how slightly different it behaves and Kirigami / Qt Quick is just not a viable thing, there's barely any community and/or "serious" project on Windows, macOS or mobile. I'm not trying to discredit the KDE folks, but that is reality. Also, Qt Quick licensing is not so easy (or very expensive if you go commercial) for iOS. Whereas electron has a) b…

> Except Flutter is a subpar experience on every platform because of just how slightly different it behaves

I'm not sure this is true. If you check the pulse of social media, most Flutter devs think Flutter is great for Android, iOS and desktop but needs help on web. Canonical at least rewrote their installer in Flutter and anything new they develop is in Flutter. Devs are hoping that the WASM support currently shipping in `master` [1] will solve for web.

[1] https://docs.flutter.dev/platform-integration/web/wasm

Re: Make Apps for Linux

#346

Post by emptysongglass »

jwells89 wrote: post #303
emptysongglass wrote: post #214

There's a lot of complaints that there isn't much in the way of tooling to create cross-OS compatible apps but I disagree. Just looking at solutions which aren't Electron: - Telegram uses Qt and ships a performant native app across all three OSes - Flutter compiles down to native code across all three (and mobile) - Kirigami is a QtQuick framework that will give you an executable app across all mobile and desktop tar…

While the Qt Telegram app runs fine on macOS, most Apple users opt the Swift/Cocoa client for macOS and iOS[0]. [0]: https://github.com/overtake/TelegramSwift

Can you qualify "most Apple users"? I've never met anyone running the Telegram Swift client and this is the first I've heard of it.

Re: Make Apps for Linux

#347

Post by samus »

mnd999 wrote: post #335
samus wrote: post #305

Earlier quoted context omitted.

You're living in the past. Applets and Flash lost against the HTML/JS/CSS stack and Oracle owned up to it. Applets are terminally deprecated now. Edit: admittedly, one of the reasons for that was that the sandbox was indeed prone to security holes. Also, the developer ergonomy of the SecurityManager was unsatisfying for both JDK and app developers. Good riddance.

Applets are still a thing. We just call them webasm and canvas these days.

The crucial difference is that these technologies are embedded differently. Java Applets had access to dangerous APIs that had to be restricted by the SecurityManager. Also, the JVM was installed externally to the browser, turning it into an uncontrollable component which made the browser vulnerable in turn.

The newer technologies were designed from the beginning with a well-defined security boundary and are based on a language that was designed from the beginning to be embedded. Everything is implemented within the browser and can be updated together with it.

Re: Make Apps for Linux

#348

Post by hulitu »

pjmlp wrote: post #82
zer0zzz wrote: post #34

I think the premise is wrong when there still doesn’t exist a core set of frameworks that are abi stable on Linux. On competing platforms there are way more frameworks out of the box (CoreImage, CoreAudio, CodeML, SceneKit, AppKit, etc) and they don’t break as often. I know in Linux they have fun things like snap and flatpak but it is really solving the problem using a bit of infrastructure and package management ins…

That core would be GNOME or KDE frameworks, coupled with the FreeDesktop standards, at least that was the plan about 20 years ago. However as the site says doing distributions is what most folks keep doing, and naturally there isn't a single stack that can keep up with snowflake distributions. In the end, Google took the Linux kernel, placed two core set of frameworks, one in Java, and the other in JavaScript, and na…

There is no standard at freedesktop. Everything is a moving target, just like KDE and Gnome.

Re: Make Apps for Linux

#349

Post by whartung »

ausbin wrote: post #284
whartung wrote: post #282

Earlier quoted context omitted.

It was. Even before it was more "bundled" with the JDK than "part of Java". But, to be honest, that's a real nit. It's a standalone dependency, it's 4 lines in a POM file, it doesn't drag the internet with it, and it only relies on the JDK. So, while it's a large subsystem, it's a "low impact" dependency in terms of side affects and complexity.

> it's a "low impact" dependency in terms of side affects and complexity. I wish that were true in my experience. But we have struggled to support {macOS, Windows, Linux} x {x86_64, arm64} with JavaFX and one .jar for our application. This is a 250-line diff, not a 4-line diff: https://github.com/ra4king/CircuitSim/pull/93/files . We have to manually manage .dlls and .sos by hand. If you know a solution that is 4 lin…

Not sure what your requirements are.

My point about 4 line dependency is to point out that the barrier to entry into FX is low. What you are doing I would consider unconventional, as demonstrated by all of the hoops you're jumping through to achieve it. Packaging, yes, is still a bit arcane at this point.

My project, https://github.com/willhartung/planet packages macOS and Windows installers, and can be run as a fat jar on a Linux machine (tested on Ubuntu). You can look in there to see my POM file, and my build scripts. They're much simpler than what you're doing. I don't have a package for Linux, as I mentioned earlier, it was just a bit to confusing to figure out Linux packaging for my tastes, so I punted. If there was crushing demand for it, I'd look into it deeper.

None of those artifacts are "cross platform". It's not a single artifact for all platforms, they are platform specific. I build the Mac one on my machine, and the Windows and Linux versions on VMs. Currently, the vision for Java distribution is to bundle the runtime with the application. Use jlink and the module system to narrow down your JRE, and jpackage to combine them into an appropriate, platform artifact. jpackage requires to be run on the host OSs. I do not have ARM versions of any of my code yet.

If you want to ship a cross platform jar, then it's probably worth your time to require a JDK with FX already installed. Azul does this, I think there are others. Then the FX, and it's platform specific binaries, are no longer your applications problem.

Also, there is a project, https://jdeploy.com that offers tooling and infrastructure to distribute native FX bundles, it even offers automatic updates. It will install its own JDK in its own directory structure to run your applications. If you have multiple applications, it will share the JDKs among them. It's quite clever, and perhaps worth considering depending on your requirements. I chose to not do that just to make my projects as simple as practical for the end user and myself.

I'll be fair, getting to this point was not drag and drop. jpackage and jlink can be fiddly to get started with. Documentation can always be better.

Re: Make Apps for Linux

#350

Post by justin66 »

pizza234 wrote: post #327
justin66 wrote: post #248

Earlier quoted context omitted.

> I don't consider it backward compatibility in a strict sense. Just in the sense that 100% of the people who use the phrase "backward compatibility" mean.

Sure, from a user perspective, but not from an operative perspective: in the cases of live binary patching, Microsoft required to call the application developer to be legally clear; in orther cases, APIs behave differently based on the executable being run. There's a lot more than just keeping the API stable.

I get that my initial comment was a bit of a throwaway, but I can unpack it a bit. I think it’s a mistake to regard a working backward compatibility functionality as deficient because it requires maintenance and the cooperation of the parties involved. That’s just… engineering, right?
Post reply on HN