181–190 of 289 posts
Earlier quoted context omitted.
And put that in an app store?
Yes, even on iOS.
Earlier quoted context omitted.
Personally I'm fine with application specific UI schemes. It's a bit silly every application would follow the same guidelines as applications are intended to do different things. Platform UX/UI conventions place too strict limitations on innovation. The original point - that people would get confused from non-platform UI schemes - has been proven kind of moot since most games have their own domain specific UI schemes…
> It's a bit silly every application would follow the same guidelines as applications are intended to do different things. Platform UX/UI conventions place too strict limitations on innovation. They really don’t. Have you taken a look at the thriving ecosystem of native, powerful macOS apps that follow platform conventions?
Earlier quoted context omitted.
I don't. The reason is UI kits on different OSs are so different that allowing this stuff makes for haggard looking apps. Using the web at least brings consistency to the experience. There's no workaround I can think of, you either write one UI per OS (even with QT you still need to adjust for conventions, spacing etc...) or you make an OS agnostic UI with Web tech.
> (even with QT you still need to adjust for conventions, spacing etc...) That is what I'm talking about: SwiftUI automatically uses the recommended conventions for spacing, padding, etc. which are different for macOS vs. iOS etc., and it also takes user environment settings into account, like font sizes and other accessibility options.
Earlier quoted context omitted.
Yes, even on iOS.
The LGPL requires end users to be able to view and modify the LGPL portion of the derivative work. Does iOS give end users that level of access to apps? (honest question, my outsider's impression of Apple is that they have stuff locked down more than that)
Earlier quoted context omitted.
For me, and probably others, the main issue with Electron isn't the speed or even resource usage. It's that it ignores common UX/UI conventions you expect from a native app which still makes me prefer native macOS apps.
Personally I'm fine with application specific UI schemes. It's a bit silly every application would follow the same guidelines as applications are intended to do different things. Platform UX/UI conventions place too strict limitations on innovation. The original point - that people would get confused from non-platform UI schemes - has been proven kind of moot since most games have their own domain specific UI schemes…
I emphatically disagree. There are still jokes (from legitimate annoyance) that the main consoles have different conventions for buttons and button names. It's awkward to navigate menu system with a simple up, down, left, right, accept, cancel when accept/cancel move around system to system. At least on desktop computers Spacebar/Enter and Escape are mostly consistent.
As for in-game control schemes, it's generally coalesced around wasd + mouse and USE. Even with that there are jokes (stemming from legitimate annoyances) about putting down a game for a week because you're older, are a parent, and have other responsibilities, then having trouble picking it back up.
This is a major reason I'm incredibly selective about the games I play and one reason I avoid online play. Sure, I'm one data point, and it may not apply to a majority of the cashflow for gaming, but I see it expressed online quite often.
Earlier quoted context omitted.
I imagine the different electron versions and different Chrome versions would make this hard without breaking things. Maybe a config option for "allow chromium between versions x and y" would solve this.
Shouldn‘t Chrome be backwards compatible? I would hope so at least.
Earlier quoted context omitted.
> If you're bothering to include Linux in your list of Desktop platforms at all you may as well include the BSDs. I guess, but the amount of people I know that use BSDs are even fewer than the amount that use Linux. Given that Linux is a hard enough sell to support for most apps I doubt that BSD support would be offered even if the framework supports it. > Besides, Java works fine on BSDs. Why is it that when modern…
You can quite easily bundle the Java runtime with your application. Many Java applications do this. As a bonus, it will still be smaller than the equivalent Electron application.
Earlier quoted context omitted.
So maintain it as a third party set of patches. So I can run proprietary apps (because that's what these self-professed app devs are talking about mostly)? Not gonna happen. Just because upstream wouldn't accept it doesn't mean that it can't exist. No, it just means it's a lot of unnecessary work for a framework that already has an arduous build process. I haven't found that killer Electron app just yet so what that…
It’s clear that you aren’t their intended audience. Due to a choice you have made to not use a more common platform. Your responses sound like you’re upset; why? You made your choice. They made theirs. Accept the reality, accept the trade offs, or make changes. Complaining about the decisions made by other people isn’t useful.
Actually I'm primarily using MacOS as a desktop these days. I've happily paid for a variety of apps (e.g. Omnigraffle, Monodraw, Lightroom).
Your responses sound like you’re upset; why? You made your choice.
Beyond the usability issues that constantly dismissed out of hand by developers, Electron is a crass and dishonest attempt at redefining portable and cross-platform to include a very narrow selection of platforms.
This actively increases the effort to get traction with a non-Electron supported platform and encourages bloated. Who's going to compete with Slack if they already offer a (shitty) desktop app?
Folks hold up VS Code (which I do use) as an example of a good Electron app. It's still slower than native IDEs like TextMate or Sublime and it's still not quite right in terms of native look and feel. Why do I use it? Network effects. The rust community seems to have (sadly) standardized on VS Code.
I'm bullish on Electron. I think it's just a couple of technical advancements away from being the ultimate desktop toolkit. For context, I love and have worked a ton with Qt, and I much prefer Qt UIs as a user. But Electron has brought true cross-platform development to all platforms (Including Linux!). If it weren't for Electron, I wouldn't even have a bunch of the apps I use today. Hell, I wouldn't have a good IDE,…
I'm bullish on Electron. I think it's just a couple of technical advancements away from being the ultimate desktop toolkit. For context, I love and have worked a ton with Qt, and I much prefer Qt UIs as a user. But Electron has brought true cross-platform development to all platforms (Including Linux!). If it weren't for Electron, I wouldn't even have a bunch of the apps I use today. Hell, I wouldn't have a good IDE,…
>> OSes and frameworks have tried to solve this a bazillion ways. What is different today is that Windows 10 and other popular platforms adopted Flat UI. Users no longer expect apps to have “native look & feel” because Flat UI has no recognizable or desirable look & feel. This is a big mistake by Microsoft because there is no longer any reason for independent developers to write native Windows apps. This works to the…