Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ElectronCGI – A Solution to Cross-Platform GUIs for .NET Core

blinkingcaret.com

Post reply on HN
Print view View original

41–50 of 87 posts

Re: ElectronCGI – A Solution to Cross-Platform GUIs for .NET Core

#41

Post by vips7L »

tannhaeuser wrote: post #30
vips7L wrote: post #23

Earlier quoted context omitted.

Swing is probably the wrong choice if youre going java. I do electron everyday for work and we use stdin/stdout to farm json to a Java process as well. Given the chance I would probably use JavaFX over Electron or Swing. The FX app will be easier to style than swing and Gluon just announced native compilation support via Graal for new FX apps [0]. [0] https://gluonhq.com/gluon-substrate-and-graalvm-native-image...

Last I checked (late last year) JavaFX hadn't HiDPI support.

According to the release notes for version 8 HiDPI is supported.

Re: ElectronCGI – A Solution to Cross-Platform GUIs for .NET Core

#42

Post by vips7L »

thomascgalvin wrote: post #40
vips7L wrote: post #35

Earlier quoted context omitted.

Makes sense. The tornadofx hello world is pretty minimal too: class HelloWorld : View() { override val root = HBox(Label("Hello world!")) } class HelloWorldApp : App() { override val primaryView = HelloWorld::class } I've bee conflicted in my research on choosing Tornado or default JavaFX

I'm waiting for Tornado to support Java 11+ before I jump on the bandwagon. It's getting closer[1], but it's still not production ready, from what I can tell. [1]: https://github.com/edvin/tornadofx/issues/899

Well I guess that makes it easier. I'd rather write Java than Kotlin anyway.

Re: ElectronCGI – A Solution to Cross-Platform GUIs for .NET Core

#43

Post by tabtab »

What's really needed is a standard GUI markup language (SGML) and probably a dedicated browser, or at least a browser pluggin. Emulating desktop-like GUI's using JavaScript and DOM has proven clunky and unreliable, largely because HTML browser makers do what they want when they want. A dedicated GUI browser wouldn't break GUI's because doing GUI's is its sole purpose.

HTML browser makers usually don't care if they break a particular JavaScript library by adding or tweaking features. It's a matter of focus. The SGML browser's only job is to do GUI's right. But HTML browsers have 100's of jobs. If changes harm a few of those, they become roadkill.

But using JavaScript as the starting point of a SGML may be the only way to gain momentum. However, the end game should be using mostly markup to manage a GUI, not JavaScript.

Standard and common GUI idioms and behaviors should be done in a declarative fashion using such markup, such as having a button open (make visible) a given window. While some client scripting may be needed, most of the processing could and should be done at the server if the SGML browser does most of the UI grunt-work.

Re: ElectronCGI – A Solution to Cross-Platform GUIs for .NET Core

#44

Post by belinder »

miguelrochefort wrote: post #31
belinder wrote: post #15

Earlier quoted context omitted.

One of the comments on that blog leads to WinUI, which I would assume Microsoft would recommend first https://github.com/microsoft/microsoft-ui-xaml/blob/master/d... Not sure if it's cross-platform though.

Uno Platform attempts to make WinUI cross-platform. https://github.com/unoplatform/uno

Oh that looks good. Wonder what the timeline on these technologies will be. Sounds like it will be after .NET 5

Re: ElectronCGI – A Solution to Cross-Platform GUIs for .NET Core

#45

Post by azhenley »

tabtab wrote: post #43

What's really needed is a standard GUI markup language (SGML) and probably a dedicated browser, or at least a browser pluggin. Emulating desktop-like GUI's using JavaScript and DOM has proven clunky and unreliable, largely because HTML browser makers do what they want when they want. A dedicated GUI browser wouldn't break GUI's because doing GUI's is its sole purpose. HTML browser makers usually don't care if they br…

I like your idea and Microsoft probably hoped for XAML to become that standard.

Re: ElectronCGI – A Solution to Cross-Platform GUIs for .NET Core

#46

Post by localhost »

belinder wrote: post #15
Hawxy wrote: post #3

Steve Sanderson (creator of Blazor) is working on something similar that doesn't use Electron: https://blog.stevensanderson.com/2019/11/01/exploring-lighte... From Blazor roadmaps a few months ago, I think the idea is that Blazor will become the recommended .NET Core cross-platform UI choice sometime after .NET 5.

One of the comments on that blog leads to WinUI, which I would assume Microsoft would recommend first https://github.com/microsoft/microsoft-ui-xaml/blob/master/d... Not sure if it's cross-platform though.

Microsoft is not a single entity; there is plenty of room for innovative ideas like what Steve has that challenges the status quo around formerly innovative ideas like electron. We certainly have no shortage of highly successful electron apps at the company either (e.g., VS Code and Teams).

Re: ElectronCGI – A Solution to Cross-Platform GUIs for .NET Core

#47

Post by Crinus »

thesuperbigfrog wrote: post #17
efdee wrote: post #13

Earlier quoted context omitted.

Good luck getting that Swing app to look nice, though. Which is a breeze with HTML/CSS.

Customizing the appearance is one place where Swing's age shows. It is possible to create a custom "Look and Feel", but it is not as easy as HTML / CSS: https://docs.oracle.com/javase/tutorial/uiswing/lookandfeel/ JavaFX does allow CSS to be used to style it: https://docs.oracle.com/javase/8/javafx/user-interface-tutor...

I remember >10 years ago there used to be some "plaf" libraries that provided very easy themeing abilities for Swing that even came with a WYSIWYG tool to create themes. It is a shame something like that never became part of Swing itself and instead you have to create tons of classes just for a theme.

Re: ElectronCGI – A Solution to Cross-Platform GUIs for .NET Core

#48

Post by orange8 »

tabtab wrote: post #43

What's really needed is a standard GUI markup language (SGML) and probably a dedicated browser, or at least a browser pluggin. Emulating desktop-like GUI's using JavaScript and DOM has proven clunky and unreliable, largely because HTML browser makers do what they want when they want. A dedicated GUI browser wouldn't break GUI's because doing GUI's is its sole purpose. HTML browser makers usually don't care if they br…

> What's really needed is a standard GUI markup language (SGML)

What's wrong with HTML? Isn't it already everywhere, including in all browsers?

> HTML browser makers usually don't care if they break a particular JavaScript library by adding or tweaking features.

HTML and JS are two different languages. One is a markup language, the other a scripting language. If changes to the markup language break a library in the scripting one, its clearly the library that needs fixing. Expecting browser makers to somehow keep their HTML engines backward compatible with JS libraries isn't really realistic or practical.

Re: ElectronCGI – A Solution to Cross-Platform GUIs for .NET Core

#49

Post by thelazydogsback »

azhenley wrote: post #45
tabtab wrote: post #43

What's really needed is a standard GUI markup language (SGML) and probably a dedicated browser, or at least a browser pluggin. Emulating desktop-like GUI's using JavaScript and DOM has proven clunky and unreliable, largely because HTML browser makers do what they want when they want. A dedicated GUI browser wouldn't break GUI's because doing GUI's is its sole purpose. HTML browser makers usually don't care if they br…

I like your idea and Microsoft probably hoped for XAML to become that standard.

WPF was great to program in for the most part -- was able to write some really compelling and complex UI's in it, and UI programming isn't really my thing.

Re: ElectronCGI – A Solution to Cross-Platform GUIs for .NET Core

#50

Post by Crinus »

tannhaeuser wrote: post #32
efdee wrote: post #13

Earlier quoted context omitted.

Good luck getting that Swing app to look nice, though. Which is a breeze with HTML/CSS.

Swing can look fantastic if you put in the effort as IntelliJ (based on Swing) shows. I'm not necessarily an IDE guy, but good luck with getting that kind of functionality with JS on Electron even remotely.

The problem with Swing theming is that you need to create a ton of classes "just" for theming your application. I did that years ago myself, but really Swing should have something like those libraries released years (>10) ago that had a bunch of premade themes as well as WYSIWYG editors for them.

There used to be many libraries (most of them were awful, half of them tried to mimic circa 2002 Mac OS X Aqua) so i do not remember any names, though i remember trying one with a visual editor that i gave to a designer at the place i worked at. We didn't ended up using it though because of the price.

Post reply on HN