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

361–370 of 422 posts

Re: Make Apps for Linux

#361

Post by freedomben »

rubymamis wrote: post #309
freedomben wrote: post #264

Earlier quoted context omitted.

Well dang! I didn't realize it was that big. That is impressive and definitely changes my opinion a bit. It's quite unfortunate to have such low paid numbers with that many downloads. By logseq's on-disk format, it is local first but it's a stricter subset of markdown with a handful of extensions. The strictness is because Logseq parses all the markdown into an in-memory graph database, and in order to make that work…

Thanks! With Plume I use a tree data structure (just with parent child relationships), although in the future I would probably use Boost::ptree. The things is, the underlying data structure is just plaintext, so having an ID for each block will make the plaintext look out of place (say, if you wanna move your files to another app). But I'll add some special syntax to allow this feature for specialized blocks.

> so having an ID for each block will make the plaintext look out of place (say, if you wanna move your files to another app).

Indeed, this is definitely a problem for Logseq. For example here's some of my recent Logseq notes. This is one page where you can see an "ID" (represented by `id:: ` is created. Then helpful images/diagrams are displayed. This is then referenced later:

    - Parts of a [[Neuron]]
      id:: 64f4bdc3-29de-4b6c-bc41-20a5f052badf
      - Dendrite: https://en.m.wikipedia.org/wiki/Dendrite
        - ![Anatomy_of_neuron.jpg](../assets/Anatomy_of_neuron_1693760694470_0.jpg){:height 411, :width 718}
      - Axon: https://en.m.wikipedia.org/wiki/Axon
        - ![Blausen_0657_MultipolarNeuron.jpg](../assets/Blausen_0657_MultipolarNeuron_1693760712899_0.jpg){:height 471, :width 718}
Then in a different page, this is referenced by ID. In this case it is "embedded" but you can also reference and other possibilitie:

    - #vocabulary [[Brain Myths Exploded]] #Notes
      - {{embed ((64f4bdc3-29de-4b6c-bc41-20a5f052badf))}}
      - Encephalization Quotient (not a good measurement)

Re: Make Apps for Linux

#362

Post by seba_dos1 »

sph wrote: post #323
lupusreal wrote: post #56

Earlier quoted context omitted.

There are some programs that sell binaries but also give away the code. The premier pixel art editor Aseprite is free (source available, not open source) if you're willing to build it from source yourself, but most users buy the prebuilt binaries. I think this way you satisfy both the privacy conscious / cheapskates, and also the developer's economic needs. RMS doesn't approve I'm sure, but you can't please them all.

RMS totally approves, and selling binaries (as long as they are accompanied by source code) is explicitly approved by the FSF. Open-source has never been about hating money or working for the glory.

Approves selling software, but doesn't approve making it non-free - and Aseprite is non-free (it used to be free in the past).

Re: Make Apps for Linux

#363

Post by zer0zzz »

rollcat wrote: post #334
zer0zzz wrote: post #106

Earlier quoted context omitted.

None of that core is standardized across even a hand full of distros.

Which is the entire point. Having working software beats having a standard. (Naturally having working software that adheres to a standard is even better, but at least they got their priorities right.)

That's great, but then don't complain to your community for creating more distros? Thats the thing they are good at, because they have been given great tools to do so.

Re: Make Apps for Linux

#364

Post by michaelmrose »

isodev wrote: post #316
michaelmrose wrote: post #294

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

TLDR: Release GTK/QT apps with menubars and xdg-desktop-portal on flathub and use stripe to impliment any and all desirable business models. You can do this today and your app wont look any more out of place than the browsers and office suites. IAP are the STDs of business models.

> You can't stop people from making crap apps, they exist even today.

The particular crapware that exists on Android is notably absent from built in software management GUIs so it looks like you CAN do this.

> To make an app feel at home, it needs to "blend" with the rest of the OS

68% of desktops are GTK based, 26% are KDE which themes GTK apps the same as KDE apps. Superficially apps blend well. Looking deeper you will notice many similarities. Many common shortcuts and the same, common UI paradigms, idioms. Look a little closer and you'll note differences especially gnome with its client side decorations which cram a toolbar + window controls into a single line with extra spacing, QT apps with the more traditional menubars and certain shortcuts in common. Then there are incredibly common apps that are obviously not fully consistent with any, firefox, chrome, gimp, libreoffice, thunderbird.

https://linux-hardware.org/?view=os_de&formfactor=notebook

What one ought to realize shortly is that there is no singular Linux desktop to blend into and it works fine as is.

If you make a GTK app with a traditional menubar you will look reasonably at home on virtually all desktops. At least as at home as most of the most popular apps listed above.

> Then comes the question of system integrations - how do you offer a unified photo picker experience

xdg-desktop-portal

>how do you ensure you always ask for the right permission to access the camera, the clipboard or network APIs

In native apps none of this is controlled at all. Don't install things you think might look at you through the camera and upload your nudes to the cloud. In flatpak the permission to do so is front loaded into the permissions required by the app. Don't install things that require camera and network permission if you think they might upload your nudes to the cloud. Flatseal provides a way to modify this permission after the fact if you want to install something and modify what permissions it gets.

> I strongly disagree - what if you want to offer a "try before you buy",

The most obious thing to do is time or feature limit your usage and "unlock" your app by opening a url and handling payment on your website with stripe and then having the user copy a code and or open a link to communicate it to the app. This is relatively easy AND lets you keep 100% of the money and no capricious app store rejection can keep your users from using your app. If you for any reason were ever to have a challenge distributing your work on the official source both flatpak and traditional package management has the concept of multiple sources. Customer adds your source and your apps and official apps are displayed in the same integrated app store interface.

Flathub is supposed to introduce one off paid apps/subscriptions. I'm not clear what the progress on that feature is. I do not believe there is any plans for in app purchases however. Probably because 99.9% of the use case is dominated by porn, shitty games, and adware. Asking why non-gross environments don't impliment IAP is like going to the whore house and shouting "where all the gonorrhea at!"

It is better from the user perspective if payments/subscriptions are either managed on the website for the service or better yet one a singular store interface where customers can make an intelligent decision rather than having the dev low ball them and them ride the sunk cost fallacy and FOMO to a fuckin payday.

Re: Make Apps for Linux

#365

Post by paulddraper »

FirmwareBurner wrote: post #145
chefandy wrote: post #103

Earlier quoted context omitted.

People like to shit on tools like Electron, but there's a reason they're popular. If you need to reach a broad audience with a native tool, using heavy-handed web-based plumbing is a bigger win for Linux users than supporting only windows and macos where like 97% of desktop users are.

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?

If Java applets were anywhere as popular as JavaScript web apps, I'm sure Java desktop would be as popular as Election.

But Java applets aren't popular.

Re: Make Apps for Linux

#366

Post by chefandy »

skydhash wrote: post #289
chefandy wrote: post #211

Earlier quoted context omitted.

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.

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 started digging into it professionally. I think it's because applications that have experienced designers make a good, usable interfaces will also likely hire visual designers to do aesthetic/branding work, and especially in waterfall environments, developers get it all handed to them as a "design." And for many reasons I will (uncharacteristically) not rehash here, FOSS lacks both.

However, a good interface and a pretty interface are not the same thing-- both are communication mediums that communicate through the software interface, but visual/branding/identity designers communicate things to the user about the brand as a marketing device, and interface designers figure out how to communicate the software's features, status, output, etc. with the greatest efficiency and reduce unnecessary cognitive overhead. Branding and identity is a very specialized form of design that's usually done by design houses-- even huge companies with big teams of designers often contract this work out to specialists. They might go so far as to recommend certain animations for interaction, but you don't want them designing your interface. In small companies, the designer will probably have to implement their design to conform to the design document, but they're using tools like gestalt, alignment, color grouping and type to create information hierarchies, existing expectations for layout and functionality, etc. that tell the user what they need to know as effectively as possible, and how to act on that in the ways they need to.

A good example of the power of interface design is in many dark patterns. You can simply have a plain system-standard dialog box asking if a user consents to some creepy analytics that nobody really wants, but instead of "OK" and "Cancel" in their normal spots, put "Off" in bold letters where "Ok" would normally be, and "Consent" in non-bold letters where "Cancel" would normally be, and I'll bet you at least 60% of users would choose "Consent" having only skimmed the familiar pattern. That experience isn't branded or styled in any way-- it solely uses juxtaposition, pattern expectations, and context to influence users behavior.

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. This is very counterintuitive for most developers because of the curse of expertise. We have a working mental model of how software works on the back end and consider the interface a tool to expose that functionality to the user. To users, the interface is the software, and if you're design is more informed by the way the software works under the hood than the way a nontechnical user thinks about solving the problem they're trying to solve, it's going to be very frustrating for everyone who isn't a developer. Developers like to talk about marketing as the primary reason commercial software is king, and it's definitely a factor, but developers aren't magically immune to marketing, and you can't get much more compelling than "Free." To most users, the frustration of dealing with interfaces designed by and (inadvertently) for developers is worse than paying for software--- hence FOSS nearly exclusively being adopted by technical people.

Re: Make Apps for Linux

#367

Post by chefandy »

zlg_codes wrote: post #325
chefandy wrote: post #255

Earlier quoted context omitted.

Reread what I wrote. I'm not saying they're sane technical decisions and I'm definitely not saying that electron is an objectively good architecture for user-facing apps, and I'm definitely not saying that profit is a good way to determine an ideal engineering strategy. But trying to discuss the viability of an option in real-word software creation without acknowledging that profits are often the driving factor in th…

Part of that is because profit should not take precedence when making a technical decision unless you are a business. The other part is that if we accept only things that lead to easy profit, we'll avoid all sorts of things that take more initiative but become better products. Short-term stock price chasing is not a way to make tech decisions. It's a way to make profit decisions. I seem to be on a website where nobod…

I'm betting you haven't actually had to make decisions like this in a role where you were responsible for getting the most out of a limited set of resources. It doesn't even have to be commercial: even in well-funded non-profits that I worked with, maximizing the impact of your work is more important than maximizing the quality. If we were talking about shaving 5% off labor costs to put the extra trim on the shareholders' Lamborghinis, that's one thing. If good-enough quality will make triple the impact per grant dollar spent, the correct answer is pretty clear. If technical purity means the project isn't feasible with the allotted budget, it's even clearer. It's about how much you can do with the amount you have. Nobody who gives you money to promote childhood STEM education is going to care how much more technically correct your solution is if you run out of money before you can ship, and they certainly aren't going to give their new cancer-research grant a haircut because you wanted to save on end-users' ram usage. Using the existing giant labor pool of web developers to make an electron application isn't just a little less resource intensive than making a Java application for nearly any purpose-- it's vastly less resource intensive. That's just plain old reality. I'm not saying it's good, or worth praising; it's just the way our world works outside of volunteer-driven FOSS.

When I got paid by a nonprofit to work on MIT-Licensed FOSS full-time for years, these questions were as important as anywhere else where resources aren't free. If I had my choice, I'd have chosen Elixir and Phoenix to do many of our web projects because BEAM had built-in tools to solve a lot of the odd architectural problems we had. But if you suddenly had to hire a few Elixir developers to do something that would work fine with Node.js, just not as elegantly, that grant isn't going to get any bigger just because I'm making sound technical decisions. At the end of the day, your software is valuable for what it does for people-- not what it is.

And really, how much does using electron limit the actual utility of the tool itself among people with limited compute resources? I don't mean what's the difference in the memory footprint, I mean how often are people unable to solve their problem using an electron app because their computer can't run it? You obviously don't need bleeding edge hardware to run an electron application as hyperbolically suggested-- it's not much different from using, well, Chrome. Projects that work with really really under-resourced populations, such as the houseless, don't make desktop applications anyway-- one that I can think of off-the-top of my head used SMS because it was so much more readily available than a computer you can install an app on.

Developers like to focus on things like memory and compute resources because they know how to address them. Hammers looking for nails. But if you really dig into users' biggest frustrations with software, as I have in my interface design work, performance is almost never mentioned. When it is, they're almost exclusively dealing with shitty internet access, not slow local application execution. If FOSS projects wanted to do more good in the world rather than having a hobby project to nerd out about, they'd actively solicit designers to figure out what problems real users are actually running into trying to solve their problems rather than just assuming the solution is more technical correctness. They could be one of the few volunteer-driven FOSS projects isn't solely usable by people who already have a working mental model of software development.

Re: Make Apps for Linux

#368

Post by mixmastamyk »

lupusreal wrote: post #357
mixmastamyk wrote: post #317

Earlier quoted context omitted.

That’s only the last line, not quite what they stated. Still a lot slower than emacs or CUA keys, so no it doesn’t fall flat. The kind of person that would use it doesn’t use a terminal.

> That’s only the last line, not quite what they stated Then I wasn't clear, I am talking about using the mouse to position the cursor in the current line being edited. If I am writing a long command and realize I made a typo 50 characters earlier in the second argument, I should be able to click in the second argument to reposition my cursor. And yes, I do use vi-mode and know how to do this the vi-way with just the…

Nonsense—a shell is not a full screen ncurses app like the others you've mentioned and probably wouldn't want it to be due to having to carry the scrollback buffer.

You're the only person to implement this slower/problematic/nifty design in five decades, on a FLOSS operating system. Just a guess but maybe your attitude is also part of the problem.

Re: Make Apps for Linux

#369

Post by seabrookmx »

michaelmrose wrote: post #117
seabrookmx wrote: post #101

Earlier quoted context omitted.

It's still annoying even if you're experienced with Linux. Especially if there's multiple install methods for the same app with different levels of support. Flatpak is the closest thing thus far, but certainly hasn't "won" yet.

This is actually a solvable problem. You provide a single store interface where you install flatpaks and traditional packages. Linux Mint does a pretty good job of this. With Arch you can basically rely on system packages and the AUR for 99.9% of everything. Either way wrapping an interface around 1 or more method is a fairly trivial matter.

It doesn't solve the multiple install methods issue.

Fedora for instance already has this via Gnome Software, but provides a drop-down if multiple sources are available for an application, so it's still fragmented. Even if you removed that and had some sort of heirarchy, one app might have a better experience via Flatpak whilst one might be better via RPM.

Until developers consolidate it's really not solved, IMO.

Re: Make Apps for Linux

#370

Post by xkekjrktllss »

dralley wrote: post #285
xkekjrktllss wrote: post #270

Earlier 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.

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.

Rants are very different from actually influencing the software. The same people rarely care for the alternatives to systemd.
Post reply on HN