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

411–420 of 422 posts

Re: Make Apps for Linux

#411

Post by account42 »

deafpolygon wrote: post #12

This is one of the biggest issues holding the Linux platform as a whole. It's often cited as a strength, but I don't see it as such. Many times, the plethora of choice is pushed forward by devs as an advantage of Linux ("you have so many choices to pick from!") but for many users this presents the paradox of choice - and pushes many people back to the platform they came from. You get less choice on macOS and Windows,…

> How many different tiling window managers do we need?

As many as people want to create.

Re: Make Apps for Linux

#412

Post by account42 »

askonomm wrote: post #148
hnlmorg wrote: post #68

Earlier quoted context omitted.

Personally I think KDE is light years ahead of macOS and Windows. In fact I find macOS to have been be of the worst window managers of all the popular platforms (sure it’s pretty and easy to use, but trying to do anything beyond the basics requires magical incantations that are impossible to discover organically). Each to their own though.

KDE _functions_ well, but my god does it need someone with an actual design education to help out.

To do what? Add more unremovable whitespace everywhere? No thanks!

Re: Make Apps for Linux

#413

Post by account42 »

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.

The problem is that most design and UX is not "well-thought" but just cargo-culting and bad intuition. Almost never is there any real user study to show the design improves things in the real world.

Re: Make Apps for Linux

#414

Post by joveian »

penteract wrote: post #377
joveian wrote: post #375

Earlier quoted context omitted.

Note that this is not a fair comparison since that code is almost 50 years old, predating ANSI C and before even the 8088 existed. Still, there is only one actual error in gcc 13.2.1 which is the use of =| instead of the later standardized |=. I'm not sure if that was a common thing back then or if it was specific to their C compiler. Either way, I don't think gcc has a switch to make it work. Switching that around i…

Thanks for the details, I did give compiling it a try and saw some of the things you mention, but my knowledge of C, pre-standards C, and libc wasn't enough to fully make sense of them. I'll agree it looked better than I expected; I've seen much worse cases of single-decade old programs not compiling/working (one in Haskell and another involving C++ and Java, although they were much larger programs). But I don't thin…

My extremely limited experience with Java is similar, it seems to do much worse than C at compatability over time. Of course you are right that it is a fair example of early Unix code, I just didn't read the comment you were actually replying to carefully enough :(. Pre-standard C has more issues, so I don't think that is fair vs Windows but that is not what you were replying to. Source availability gives some additional options that you don't have with only binaries but I think you are right that without it being open source the use is limited (and potentially negative, like how the BSDs were limited by the USL lawsuit in the early 90s). Useful open source software is likely to be maintained at least to the point of compiling, though it may take a while to break enough for someone to bother (sox is in this middle stage right now with package systems applying a few security patches but no central updated repository that I know of).

Re: Make Apps for Linux

#415

Post by chefandy »

skydhash wrote: post #397
chefandy wrote: post #366

Earlier quoted context omitted.

Yeah the architecture for electron is absurd, but it's important to not relegate UI flexibility to mere aesthetics. For most of my career, I was a back-end web developer, but more recently I've done a lot of interface design after getting some formal education in it. The overwhelming majority of developers I've worked and interacted with conflate aesthetic and interface usability. Heck, even I did before I really sta…

There are many factors influencing adoption, including prior experience (I'm using it at work) and network effects (that's what my friend use). What native controls offer is seeing the whole OS as one thing. But with the advent of branding in software interface, people are expected to relearn what a control is for each software (Spotify vs Music). > When you've got an inflexible, counterintuitive UI kit that develope…

Common practices do not equate to widespread approval. Most developers don't like electron-- even the ones that build with them much of the time-- but they're everywhere. Designers' opinions are no more generalizable than developers opinions.

As someone who's studied and professionally practiced interface design, I can assure you that there's nothing magical about system UI elements to the vast majority of users. Developers often focus on that because managing them is such an important part of developing interfaces, and developing with them is way easier... but in design, it's a small slice of the components that make a real difference. A lot about usability, as is the case with any other communication medium, is extremely nuanced, and native UI kits suck for creating that nuance. It's usually possible, but once again, especially now that HTML/CSS/JS isn't the accessibility catastrophe that it used to be, the extra effort to get polished results using native stuff just doesn't pay off.

As a long time developer before I became a designer, I am intimately familiar with the sort of blind spots and misconceptions developers have about interface design. Having a working mental model of software in your head significantly shifts the way someone works with computers. Developers see interfaces as a way to expose application state, data and functionality to end users, but to nontechnical end users, the interface is the application. That is not a trivial distinction. Many things most end users prefer chafe most developers. Most things that developers prefer are absolutely unusable to most non-technical end users. And most importantly, most developers assume that their technical understanding makes them better at knowing how interfaces should be designed, when in my significant experience, it makes us worse at it. The curse of expertise obviously stymies in documentation and education-- they're the two most obvious communication mediums in software. Most developers don't even consider that the interface is the most visible and consequential communication medium in any GUI application, and going based on your gut instinct about what that should be works as well as going based on your gut instinct about making a tutorial for nontechnical users. It doesn't.

Re: Make Apps for Linux

#416

Post by skydhash »

chefandy wrote: post #415
skydhash wrote: post #397

Earlier quoted context omitted.

There are many factors influencing adoption, including prior experience (I'm using it at work) and network effects (that's what my friend use). What native controls offer is seeing the whole OS as one thing. But with the advent of branding in software interface, people are expected to relearn what a control is for each software (Spotify vs Music). > When you've got an inflexible, counterintuitive UI kit that develope…

Common practices do not equate to widespread approval. Most developers don't like electron-- even the ones that build with them much of the time-- but they're everywhere. Designers' opinions are no more generalizable than developers opinions. As someone who's studied and professionally practiced interface design, I can assure you that there's nothing magical about system UI elements to the vast majority of users. Dev…

I'm not saying that native controls are better because they are native. Or electron is suffering from some defects that impair usability. With equal time and effort, a software built with native controls will be more usable. A random user will not be able to distinguish which is which, but I dare say that the native ones would felt better if the only difference is what is used to build the interface.

When designing native controls and using common patterns of the OS, you lessen considerably the amount of efforts required to learn that application for the user of the platform. Most non-technical users only use one platform. Creating the same interface for two or more platforms is impairing users on that platform. And I include the web as a platform.

Re: Make Apps for Linux

#417

Post by p_l »

account42 wrote: post #398
p_l wrote: post #253

Earlier quoted context omitted.

The OS provided memory allocators - HeapAlloc, its wrappers GlobalAlloc and LocalAlloc (remainders of 16bit era), VirtualAlloc (page granularity, can be compared to MAP_ANONYMOUS with mmap(), and CoTaskMemAlloc which can be shared across COM processes + their respective "free" functions. malloc() is explicitly called out in documentation as "runtime dependant". Similarly other OSes used to have memory allocation serv…

malloc in (g)libc isn't any more language dependent than HeapAlloc or VirtualAlloc. Both have a stable ABI that can be used by any language.

HeapAlloc and VirtualAlloc do not bring the whole language runtime with them, like glibc does, nor are they specified as part of a specific language runtime only (the unix primitive for allocating memory is sbrk() and mmap(), not malloc()).

And with how applications are linked by default on linux, whoever loads glibc first sets the stage for every other module in the program, which makes for "fun" errors when you get a library that happens to be compiled with newer version (or older). And even if you force windows-style linking (good luck, lots of infrastructure needed), you end up dealing with modules passing each other malloc()ed blocks and possibly trying to call free() from different allocator on it.

Anyway, for all practical purposes, glibc has no stable ABI at all.

Re: Make Apps for Linux

#418

Post by mkup »

account42 wrote: post #383
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.

Stop spreading FUD, X and OpenGL have maintained stable ABIs. There is Wayland now but even that comes with Xwayland doe maintain compat. Sound is a bit more rocky but there are compatibility shims for OSS and alsa for newer audio architectures.

Stop claiming that I'm spreading FUD and show me at least one Linux app which was compiled to the binary code in 1996 and exactly that binary code still runs under modern Linux desktop environment and has similar visual style to the rest of builtin apps.

Got no counterexamples? Then it's not FUD at all, rather a pure truth.

Re: Make Apps for Linux

#419

Post by em-bee »

account42 wrote: post #400
em-bee wrote: post #236

Earlier quoted context omitted.

not when you actually want to sell the games for money.

Distributing source code is not an obstacle to selling games as for all but the most trivial games the meat is in the assets and scripts. You can open-source game (engines) while continuing to sell the rest - which is what e.g. allows you to run Doom on any device imaginable.

yes, but a game with non-free assets is still not going to be picked up by linux distributions to package, i think

Re: Make Apps for Linux

#420

Post by ausbin »

whartung wrote: post #349
ausbin wrote: post #284

Earlier quoted context omitted.

> 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…

> What you are doing I would consider unconventional

It wasn't before JavaFX was removed from the Oracle JRE. That is my point. JavaFX used to be a trivial dependency, but now it is quite painful in otherwise identical configurations, definitely not "low-impact."

> If you want to ship a cross platform jar

We do. Isn't that the point of Java, "write once run anywhere"?

This program is also used as a library in autograders. We do not want to distribute 5 versions of each autograder for 2-4 assignments. The autograder should be distributed as 1 jar. Undergrad TAs are creating that jar and may not have knowledge of complex CI pipelines etc.

> then it's probably worth your time to require a JDK with FX already installed.

That is not appropriate here. This is an educational tool, and students are enrolled in other courses that use Java frequently. We should be able to use the same JRE that students already have installed — it is unreasonable to require installing a different third-party JRE to run a digital logic simulator. It also adds another hurdle for freshmen/sophomores who may not have a natural ability for juggling different JRE installations. (Source: We tried requiring Azul and it was painful for everyone.)

> I do not have ARM versions of any of my code yet.

We have >900 students in this class, so it is necessary to support M1/M2; in fact, a large portion of our students had M1/M2 laptops. It sounds to me like you could just provide a fat jar in your case, actually. Supporting aarch64 is where we hit problems with our fat jar[1], since the aarch64 native libraries have the same name as the x86_64 libraries.

To summarize my point: yes you can make the build/install process more convoluted and avoid this problem. But we have an installation flow that has been battle-tested by thousands of students for 13 years (download circuit simulator .jar and run it) we have no good reason to abandon. The combination of the arrival of M1/M2 and JavaFX getting yanked from the JRE has made supporting our existing (extremely reasonable) flow nothing close to "low-impact."

1: https://github.com/ra4king/CircuitSim/pull/93/files#diff-648...

Post reply on HN