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

Cross-Platform GUI Toolkit Trainwreck (2016)

blog.johnnovak.net

Post reply on HN
Print view View original

101–110 of 177 posts

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#101

Post by billfruit »

doubleunplussed wrote: post #77
rapsey wrote: post #67

Earlier quoted context omitted.

Most of these are limited to the point of uselesness.

I ship nontrivial PyQt apps. PyQt can basically do anything Qt can do. Multiple inheritance of QWidgets can be dicey, but desired results can usually be achieved by defining mixins that don't subclass QWidget. It works brilliantly, far from "the point of uselessness". For me, cross platform GUIs are a solved problem, and I really can't wrap my head around all the noise to the contrary, or the claims that electron is…

Python QT bindings are poorly documented, much of the documentation is out of date. Also it appears to me, far too much churn.

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#102

Post by holy_city »

phtrivier wrote: post #93

So many sub-debates hidden in this "cross-platform native GUI": 1) I want to write a GUI code once 2) I want to ship something that works on Windows / Linux / MacOS 2.1) I want to ship something that looks the same on Windows / Linux / MacOS 3) I want to ship a binary that works on Windows, a binary that works on Linux, a binary that works 3.1) I want to ship a small and efficient binary 4) I want to ship something t…

webview kind of satisfies 1 + 2.1 + 3.1 today.

Same idea as Electron but it wraps the OS webview instead of Chromium (Cocoa/Webkit, gtk-webkit2, MSHTML, and soon EdgeHTML). The minimal test app is 255kb in size, the static lib is just 48kb (MacOS).

https://github.com/zserge/webview

And I get, "but Safari/IE/whatever are still different platforms!" I'd argue that the edge cases between browser rendering of HTML + CSS + JS is much better to deal with than the architectural and language differences between the native GUI APIs on each platform. As long as you're not pulling in an obscene amount of JS dependencies, webview is very sane.

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#103

Post by holy_city »

ashsys wrote: post #43
saagarjha wrote: post #3

To date, the best solution to this problem that I have seen is to write all your core code in a shared library using something like C++, and then hooking it up to a thin layer of completely native, platform-specific code for the UI. It’s fast, lightweight, looks good, and requires minimal extra code if you do it right.

Shameless plug: https://github.com/AshampooSystems/boden We are working on providing exactly that thin native wrapper in modern C++ without much bloat.

Do you guys plan on supporting desktop apps or are you sticking with mobile?

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#104

Post by kitsunesoba »

almostarockstar wrote: post #84

We already have browsers installed that are designed to render arbitrary cross-platform GUIs based on HTML/CSS. Why can't I write a desktop application that just asks the OS for the users preferred browser and provides it with HTML/CSS and UI interaction callbacks / events? Render it in a native looking window. We shouldn't need Electron at all! It's like we all have this fantastic rail transport network but insist o…

The most common reason I’ve heard is that devs want to be able to use cutting edge features and the update cycle for OS bundled browsers is too slow to accommodate that.

I find this argument a bit silly, because there are few applications that actually need said cutting edge features and even if you’re one of the handful there’s always polyfills, but maybe I’m missing something.

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#105

Post by afturner »

PorterDuff wrote: post #78
simion314 wrote: post #9

Earlier quoted context omitted.

It is still a lot of work if you need advanced things then the basic widgets. Thinks where usually you need to extend existing widgets like you want an advanced datagrid/table with sortable/dragable columns, with custom item renders for some columns (like a chart widget for the Trends column). In this advanced cases you will need to create custom widgets for each platform, hope that all platform have the advanced dat…

Exactly. There's GUIs and there's GUIs. When I've looked at libraries, I always consider how you'd implement the Visual Studio interface with them.

Right. Things like trees, multiple windows, theming, advanced components (with deep composition), collection views, etc. These are the real use cases for a library like this, but no such thing exists apart from Gtk and friends.

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#106

Post by holy_city »

almostarockstar wrote: post #84

We already have browsers installed that are designed to render arbitrary cross-platform GUIs based on HTML/CSS. Why can't I write a desktop application that just asks the OS for the users preferred browser and provides it with HTML/CSS and UI interaction callbacks / events? Render it in a native looking window. We shouldn't need Electron at all! It's like we all have this fantastic rail transport network but insist o…

>Why can't I write a desktop application that just asks the OS for the users preferred browser and provides it with HTML/CSS and UI interaction callbacks / events? Render it in a native looking window.

You can:

- webview (I mentioned it elsewhere) https://github.com/zserge/webview - sciter https://www.google.com/search?client=firefox-b-1-d&q=sciter - ultralight https://ultralig.ht/

Granted it's not "user's preferred browser" but it fits the bill. They all have issues, largely solved by Electron packaging the browser engine with the binary, and even that isn't perfect.

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#107

Post by simion314 »

afturner wrote: post #105
PorterDuff wrote: post #78

Earlier quoted context omitted.

Exactly. There's GUIs and there's GUIs. When I've looked at libraries, I always consider how you'd implement the Visual Studio interface with them.

Right. Things like trees, multiple windows, theming, advanced components (with deep composition), collection views, etc. These are the real use cases for a library like this, but no such thing exists apart from Gtk and friends.

Exactly, and I see people that will say you can do X with html/css and js but when you look at that example is full of bugs(for corner cases), missing features(like missing essential events), are not efficient etc.

If you look at a mature GUI library advanced widget you will see how many events and thing supports and how many bugs were reported because there are many corner cases that need handling.

I worked a lot with Flex4 I loved the fact that the widgets were optimized, you could have a list or tables with 1 million items and it would not affect performance. In Web I see the pattern where you use a lot of pages, you show like 12 results and you have the user hit Next and Next when you could have fitter a lot or even all the results on a large page, especially if is all text

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#108

Post by kitsunesoba »

sesteel wrote: post #35
lmm wrote: post #11

What is this ridiculous obsession with executable size? How much time did this author spend chasing down alternatives to a measly 120MB? If they're working on art project then fair enough, but if they're working on a useful program then surely anything else they could have done with that time would have brought more value to end users than shaving off 3 cents' worth of disk space.

Electron usage has forced me to spend some of my yearly dev budget on a 32GB machine; this comes to an extra $400 if purchased preinstalled. Now, had I not relied on so many Electron apps I probably wouldn't have required a new laptop at all. Memory management (or what I like to call memory hygiene in cases like these) is a concern. For far too long developers have brushed aside the memory usage of their applications…

Developers assuming that all users have hardware and internet speeds anywhere close to as good as their own is a huge problem.

Not only is there a huge chunk of people who are using low-to-midrange laptops ranging anywhere between old and ancient, but manufacturers are still selling brand new machines with CPU power and RAM roughly on par with the average laptop from 2007 (C2D class CPU, 2-4GB RAM, 5400RPM HD). Those users aren’t going away any time soon, and by casting resource consumption aside as a total non-issue, developers are also casting these users aside.

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#109

Post by [deleted] »

FraKtus wrote: post #47
josteink wrote: post #40

Earlier quoted context omitted.

> another reason not to like Qt is that fact that they recreate the native look on each platform it's highly inefficient on macOS. Given how everyone jumps on Electron these days, I don’t think thats a particular concern for anyone who just wants something to “simply be” cross-platform.

He complains that this creates enormous (in term of MB) application. My users sometimes have to rely on a lousy network connection to download. It can be because they are far away (China) or on a job. My users are in the event business and often have to rely on the WIFI of the hotel or the conference center.

[deleted]

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#110

Post by jonfw »

phtrivier wrote: post #93

So many sub-debates hidden in this "cross-platform native GUI": 1) I want to write a GUI code once 2) I want to ship something that works on Windows / Linux / MacOS 2.1) I want to ship something that looks the same on Windows / Linux / MacOS 3) I want to ship a binary that works on Windows, a binary that works on Linux, a binary that works 3.1) I want to ship a small and efficient binary 4) I want to ship something t…

> I suspect they're esthetics

Totally unrelated to your point, but I'm curious as to what this word means in this context.

Post reply on HN