The year of the linux desktop is upon us.
Make Apps for Linux
281–290 of 422 posts
Re: Make Apps for Linux
#282Earlier quoted context omitted.
Well, Swing is still bundled with Java. Netbeans uses the "Flat Look and Feel" and looks ok to me. I find Swing a lot more work compared to FX. JavaFX used to be bundled with Java, but was removed. Some JDK distributions bundle FX like it was before, and adding FX to a new project is simple and straight forward. Maven packages it nicely, and it includes the platform specific binary parts. If you can use Log4j, you ca…
Java FX seems better than swing, but it's an external dependency now though, isn't it? I thought it got removed from the jdk a few years ago.
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.
Re: Make Apps for Linux
#283Earlier quoted context omitted.
-dev contains the headers, that ones pretty easy. The number is a version for when they provide more than one that can be installed at once (excepting where it's part of the library name, presumably like xcb1). I.e. at some point you could probably install libgtk-3-0 and libgtk-2-$something at the same time. They likely leave it that way when they get rid of libgtk-2 so that existing tutorials that reference libgtk-3…
> but I've never looked into what that accomplishes ABI versioning.
Oh, that makes perfect sense. I assumed there was a valid reason, and that makes far more sense than anything I could think of offhand.
Re: Make Apps for Linux
#284Earlier quoted context omitted.
Java FX seems better than swing, but it's an external dependency now though, isn't it? I thought it got removed from the jdk a few years ago.
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 lines, we would be very grateful. All we want is one .jar with JavaFX in it that supports many OSs and architectures.
Re: Make Apps for Linux
#285Earlier quoted context omitted.
The Linux enthusiast community actively fights against anything like this because they want everything to be modular and made to fit specific applications. Linux does have a de facto set of standards, they're not quite as stable because they change them and deprecate old stuff, but it's better than it looks, and with Snaps you can at least partially solve the issue. But people choose distros that don't have those sta…
The so-called "Linux enthusiast community" is better described as the Linux corporate enterprise community. Understanding this makes your comment make a lot more sense. The "specific applications" are in fact merely the priorities of the giant corporations who fund the overwhelming majority of Linux development for the purpose of accumulating profit.
That's certainly not my experience. Practically every rant about systemd includes the idea that evil corporations are trying to force it on everyone rather than letting them use some random login daemon whose last commit was in 2008.
Corporate interests are generally biased in favor of avoiding hyper-specific modifications that mess with their own economies of development scaling, not seeking them out.
Re: Make Apps for Linux
#286Earlier quoted context omitted.
Yet I still can't compile an app on some arbitrary release of some arbitrary distro and just run the darn exe on another and be 100% sure it will work.
On other platforms people don't even try to support anything but one "distro". You could make an AppImage or snap that would work across pretty much any mainstream non-hobbist-oriented distro, and Snap/AppImages is pretty much the Linux equivalent of EXE. Raspberry Pi OS just moved to NetworkManager and they have PipeWire, which was the last reason I had to deal with less common software stacks, so it seems like stuf…
+1 AppImages. And the beauty is you can make them portable by creating a folder with the same name as the AppImage and append .home to the end, and boom: portable software. For example
image-editor.AppImage
image-editor.AppImage.home (folder, all settings are stored there)Re: Make Apps for Linux
#287What software is used to make the graph on the main page under the Target heading?
Re: Make Apps for Linux
#288I 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…
Ensuring an app looks and feels the same across various distributions seems quite challenging when it’s not only different flavours of the OS but also different desktop environments. At the same time, the OS flavours don’t seem to offer a unified way for handling payments, subscriptions and in-app purchases which is a significant burden to implement from scratch by every app developer.
Why do distributions need to offer this when SDKs exist for services like Stripe and PayPal?
Re: Make Apps for Linux
#289Earlier quoted context omitted.
Hold on mate, isn't that what Java was supposed to solve. I remember before the days of electron when I was a wee lad in the 2000s, all cross platforms apps were Java. Look at Ghidra, it's a Java app for Windows, Linux and Mac. The "holy trinity" of operating systems, covered with one language and framework. So what happened? Did devs forgot Java exists and felt like reinventing the wheel but worse this time?
Java is great for making huge well-organized codebases with a lot of developers, especially if you've got good tooling support or a rich ecosystem of existing code to work with. Outside of that... If it was a good development ecosystem for native gui-based apps targeted at end users, why wouldn't the preponderance of native user-facing apps be written in Java, anyway? Ask nearly any experienced mobile app developer i…
It’s about branding. Swing and JavaFX looks like other desktop app (aka not cool to a lot of designers). And it has a high barrier of entry (ever tried QT, AppKit or Win32). Electron is easy, but it’s shoehorning a document process to software interfaces.
Re: Make Apps for Linux
#290Earlier quoted context omitted.
The so-called "Linux enthusiast community" is better described as the Linux corporate enterprise community. Understanding this makes your comment make a lot more sense. The "specific applications" are in fact merely the priorities of the giant corporations who fund the overwhelming majority of Linux development for the purpose of accumulating profit.
The corporate enterprise community is who appears to create most of the attempts at user friendly, one size fits all, stable standards, because.... that's what seems to sell, and what saves development budgets not having to support lots of different OSes, as Windows has shown. Many of the non corporate hobbyists are fine with everything needing tweaking and maintenance, they chose Linux specifically because they want…
[deleted]