4 ms·

This thread doesn't inspire confidence. It's mostly small and unproven projects, some maintained by hobbyists. I think the mess we're in with GUIs is because w

This thread doesn't inspire confidence. It's mostly small and unproven projects, some maintained by hobbyists. I think the mess we're in with GUIs is because we've failed to find a way to convey at a very high level what the inputs and outputs of software are. In a utopian world, you'd define what you want the user to see and how the user can interact with the information. Something would then work out how to lay that for you (in a way that makes sense to a human) and construct a GUI using native OS APIs. Instead, we have only three options that I'm aware of: * Use a framework that ignores the native APIs, throws away the OS design language and does all the rendering inside * Build separate applications for each platform * Use Electron and potentially reuse work you already did on the web version When looking at it this way, it's easy to see why Electron is popular. Not that I'm a fan of it in any way. I think what we need is a lot of really smart people to come together to reinvent the presentation layer.

mjevans 5y ago
It's often trivial to cross-compile a basic command like program, OS filesystem specifics might be a small issue but there it's generally Windows vs everything else. Building one (mostly shared) codebase for different platforms is fine; or even shipping a script that's run locally. However the solution to this problem needs: * To already be installed on every updated OS * Work, mostly, the same across every OS * Include the widgets we know from the last 20-30 years. It's mostly that first bullet-point that's the killer. Windows needs it. OSX needs it. Neither the end user nor the application developer should have to worry about it staying updated. I'd be happy enough if, across all the major OS today, I could use a pipe or localhost socket to talk to the browser and use it to render a webpage within a basic OS window (ZERO other browser decoration or interactions, still OS decorated). If THAT alone worked on every operating system that would be enough of a basic step for 99% of the CRUD style apps out there. Small extra bonus if a message-passing interface worked between the two.
armchairhacker 5y ago
I think part of the problem is that different OS chromas have different native widget sizes, and possibly different layouts. If you create a UI for Windows and just switch to the macOS chroma, it will have weird spacing, and I don’t think there’s a general way to fix this. Converting to the iOS chroma is even worse, with checkboxes -> switches, radios -> tables, and the combination of smaller screen + bigger controls. So the solution for cross-platform apps is to use a non-native chroma which is the same for each OS. But that brings you to Qt or JavaFX or Electron.
greysphere 5y ago
3 seems like a subset of 1.

mjevans 5y ago

It's often trivial to cross-compile a basic command like program, OS filesystem specifics might be a small issue but there it's generally Windows vs everything else. Building one (mostly shared) codebase for different platforms is fine; or even shipping a script that's run locally. However the solution to this problem needs: * To already be installed on every updated OS * Work, mostly, the same across every OS * Include the widgets we know from the last 20-30 years. It's mostly that first bullet-point that's the killer. Windows needs it. OSX needs it. Neither the end user nor the application developer should have to worry about it staying updated. I'd be happy enough if, across all the major OS today, I could use a pipe or localhost socket to talk to the browser and use it to render a webpage within a basic OS window (ZERO other browser decoration or interactions, still OS decorated). If THAT alone worked on every operating system that would be enough of a basic step for 99% of the CRUD style apps out there. Small extra bonus if a message-passing interface worked between the two.

armchairhacker 5y ago

I think part of the problem is that different OS chromas have different native widget sizes, and possibly different layouts. If you create a UI for Windows and just switch to the macOS chroma, it will have weird spacing, and I don’t think there’s a general way to fix this. Converting to the iOS chroma is even worse, with checkboxes -> switches, radios -> tables, and the combination of smaller screen + bigger controls. So the solution for cross-platform apps is to use a non-native chroma which is the same for each OS. But that brings you to Qt or JavaFX or Electron.

greysphere 5y ago

3 seems like a subset of 1.