Earlier quoted context omitted.
Java simply has a much higher barrier of entry. Not only in regards to figuring out the language and resources available but also the fact that creating a GUI still requires external dependencies. Electron isn't just cross platform, it is cross platform based on technologies (html, css and javascript) that also by a huge margin have the largest amount of developers available.
> Not only in regards to figuring out the language and resources available but also the fact that creating a GUI still requires external dependencies. What external dependencies does Java need that's not in the JDK itself? I have an app with Mac and Windows installers (and thus bundles JDKs), it also runs on Linux (via a fat jar), I tested it on Ubuntu, but for the life of me I couldn't figure out how to package it p…
Make Apps for Linux
391–400 of 422 posts
Re: Make Apps for Linux
#392Earlier quoted context omitted.
Well, so I can only tell you as much as I know and understand. Some of this pulls in some outdated information too. So, JVMs and languages that abstract the underlying machine are always going to have overhead. The original interpreted stack-based JVM model is really bad for performance because you can't do great optimizations on the code because you can't have a great view of the operands that are being defined and…
> The original interpreted stack-based JVM model is really bad for performance And we addressed that today by launching a copy of Chrome with every app?
Isn't that a tooling problem, not a language/VM problem?
If the apps were distributed as PWAs, or had a shared VM (kinda like flatpak?), wouldn't that solve your nit?
Re: Make Apps for Linux
#393Earlier quoted context omitted.
The trouble is you're trying to distribute it as a binary yourself. The there are two traditional ways for distributing software for Linux: 1) The system package manager. It will download a binary from the repository which is the right one for that system. 2) make && make install. This is mostly for software in development that hasn't made it into the package manager yet. It will compile from source and produce a bin…
That's the problem. The Linux way of distributing apps is wrong for trying to compete with the other consumer platforms. The ChromeOS or electron style of doing things is another story though.
Alot of you may be looking at it wrong.
Each distribution is a different operating system. You cannot package the "same" app for Windows and mac, so why should you be able to package the same application for Debian and Arch, which, even though they run a lot of the same code, have different underlying layers and assumptions?
Re: Make Apps for Linux
#394Maybe I'm just too ignorant to know the pattern that determines whether I need to specify 'dev' and 'version' on a package or some random trailing '1' or '0', but the first linux distro with a sensible and consistent naming scheme for packages is the one that wins my heart. `libgnutls-dev` `libgtk-3-0` `libwayland-server0` `libxcb1` `libx11-6` `libffi-dev` `libncurses5-dev`
There's gobolinux, which in my view solves everything and isn't as complicated as nix... nobody cared.
This.
And, as for the -dev packages:
1) As always, a tooling issue (aka why is there no IDE for this?) 2) A design issue: no sub-packages/"aspects"
Re: Make Apps for Linux
#395Earlier quoted context omitted.
Yes, I would echo this. In most categories there are loads of subpar efforts when putting all that effort behind the top few would yield a handful of excellent apps. Collaboration can seem daunting and hard work, but it's work that will yield results which is time better spent than that devoted to projects that end up abandoned.
Who gets to take the credit? I'm not convinced these efforts to put everyone's ideas in one place and one software are good. Often, design disagreements arise which are incompatible. Under this model of "everybody love everybody" lameshit, if you can't get the group to accept your idea, it doesn't happen. You don't run into this problem when you write alone.
The point is alot of that software doesn't work with newer compiler, on newer hardware, or solve anybody else's problem.
But if it makes the original author feel good (everybody loves themself?), then it's OK.
Re: Make Apps for Linux
#396Earlier quoted context omitted.
The "feel" of the app is identical across distributions because the app controls everything inside its window and the look only varies slightly in terms of colorscheme and window decoration if that. There is absolutely no legit purpose for in app purchases on a desktop OS. Its not hard to pay for substantial software suites and most of what would be an app on platforms which at one point would have had an anemic brow…
> Nobody needs a bunch of adware apps You can't stop people from making crap apps, they exist even today. > The "feel" of the app is identical across distributions because the app controls everything inside its window To make an app feel at home, it needs to "blend" with the rest of the OS. To achieve this, one can use OS-components to build an interface. Just a simple example, GTK apps are so different from KDE apps…
> how do you offer a unified photo picker experience, how do you ensure you always ask for the right permission to access the camera, the clipboard or network APIs
XDG Portals do that
Re: Make Apps for Linux
#397Earlier quoted context omitted.
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.
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 developers must fight with to get the results the interface designer carefully put together, you hurt the usability of that tool for end users a hell of a lot more than mediocre performance does.
I have not encountered a UI kit that does not expose the 2D context to create a custom UI. But designers always want to redo native controls instead of properly using them, creating only the necessary ones. I don't believe anyone can argue that Slack UI can't be better.
Re: Make Apps for Linux
#398Earlier quoted context omitted.
What language independent allocator? I'm unaware of any memory interfaces in programming languages that aren't specific to that language. What would you use instead of malloc and free?
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.
Re: Make Apps for Linux
#399Earlier quoted context omitted.
Cuplrits are mostly glibc devs with their manic abuse of version names (and very recently, a GENIUS who added a new ELF relocation type): this is a pain for game developers to provide binaries which span a reasonable set of distros in time. Basic game devs install one of the latest mainstream and massive distros, build there, and throw the binaries on steam... but that recent distro had a glibc 2.36 and now their bin…
> If it is already that hard for game binaries, good luck with apps. Video games are some of the most complex and most difficult pieces of software both to build and to get right. Modern games are coded so poorly that driver makers have to release patches for specific games. It's the gamedev world that can't get its shit together. Valve settled on an Arch-based distro for the Deck. The specific distro doesn't matter…
> Video games are some of the most complex and most difficult pieces of software both to build and to get right.
Actually as far as binary distribution goes, video games are some of the easier to build software as they tend to need limited operating system integration besides creating a (possibly fullscreen) window, getting user input, driving a graphics card to display the result and output audio somewhere. Only completely headless programs like command-line tools or servers have it easier. Contrary to the popular meme, creating Linux binaries for games which will run on all (current) distros and will keep running in the future is not rocket science. Not completely trivial, but something that any competent developer should be able to manage.
Where things get really hard is desktop applications which users will expect to have a much tighter integration with the rest of the environment. Neither Qt nor GTK have a long-term stable ABI and shipping them with your program just means you have a million more unstable ABIs you depend on.
Re: Make Apps for Linux
#400Earlier quoted context omitted.
Isn't the solution to this problem to just distribute the source code. Let package maintainers worry about creating binaries for their distros.
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.