These days, Xamarin looks interesting. Can target windows, Linux, Mac, Android and IOS. I have not used it yet but if I get a project that needs full Cross platform distribution, I would probably use xamarin with a F# code base where possible.
Cross-Platform GUI Toolkit Trainwreck (2016)
91–100 of 177 posts
Re: Cross-Platform GUI Toolkit Trainwreck (2016)
#92Anyone got experience with this? https://webkit.org/wpe/
Here it is in use on raspberry pi https://medium.com/@decrocksam/building-wpe-webkit-for-raspb...
A long video on it: https://m.youtube.com/watch?v=klfE6m1oCkg
A short video on it: https://m.youtube.com/watch?v=wVSwkj9McCU
It says: "WPE is the reference WebKit port for embedded and low-consumption computer devices. It has been designed from the ground-up with performance, small footprint, accelerated content rendering, and simplicity of deployment in mind, bringing the excellence of the WebKit engine to countless platforms and target devices."
I'd be interested to know how to use it.
Re: Cross-Platform GUI Toolkit Trainwreck (2016)
#93So 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 that looks like a Windows app on Windows, a Linux app on Linux, a MacOS app on MacOS, etc...
(By definition, "I want to ship something that looks the same everywhere and looks like an app of my host" is meaningless, right ?)
The "holy grail" seems to be:
5) "I want to write a GUI code once that generates small efficient binaries that looks exactly like an app of the host OS, and if possible looks the same everywhere, and let me go back to writing my business logic rather than agonize over drawing a button."
It's seems from the debate that nothing obvious fulfills 4 and 5.
Then it comes to which requirement you're ready to drop.
If you're ready to drop requirement 2) , I suspect you're doing MacOS specific, go for it ;)
If you're ready to drop requirement 1) , I suspect your managers / salespersons disagree.
I suspect your manager / salespersons do not care about requirement 3.1), but it's debatable. Use Qt/Electron, and ship something.
I suspect your manager / salespersons do not care about requirement 4), and I suspect they're esthetics, which can not be defended.
I gave up waiting for someone to make 5, and don't have the resources / skill / time to do it myself. And maybe we should stop caring and watch the sky instead.
I hope someone is able to get to 1 + 2.1 + 3.1 someday.
I'll use that.
Re: Cross-Platform GUI Toolkit Trainwreck (2016)
#94Earlier quoted context omitted.
Why do I need a browser just to show components on a screen? It's overkill to do that.
I agree, but we're not really talking about simple components on a screen. If that was the case, everybody would be happy to use tcl/tk, or swing or whatever. Plus, it's not overkill when you get the browser for free.
Well, I'm happy to use Tcl/Tk -- although using it on a mobile device doesn't result in a usable touch-based interface.
Really, that's the crux of the problem is that there are different paradigms that are not just a little bit different but fundamentally different. This is especially annoying on my Chromebook running Android apps -- they very often expect you to be using a touch-based system without a keyboard. The way this works with a docked Chromebook and a mouse is the mouse is treated as a VERY precise finger touch.
Additionally, on Android and other touch-based systems you're usually not using a Window Manager so, for example, using an Android mail client on my Chromebook, I can't start the reply in a new window so that I can read the message in one window while simultaneously replying... and I especially can't have a bunch of unfinished replies while reading other emails to gather information for the reply.
Creating a meta-layer that can represent the fundamentally different modes from the same data is VERY difficult. HTML and CSS do a terrible job as well unless you model your HTML in a very specific way, which cannot accommodate all GUI semantics.
Re: Cross-Platform GUI Toolkit Trainwreck (2016)
#95One warning: if you try to implement your own gui widgets in opengl, unless you're really careful you're not going to support accessibility tools such as screenreaders or Japanese/Chinese text input at all.
If people cared about those things they wouldn't be making crappy webapps with custom look n feel and no accessibility.
Re: Cross-Platform GUI Toolkit Trainwreck (2016)
#96Earlier quoted context omitted.
Sure. However long it takes to read 120mb off a disk (most likely less, if the application is only using some of the GTK dlls). 120mb of RAM. 120mb more to read when restoring from suspend. 120mb extra data use over your home internet connection. (I'm not going to talk about antivirus time because if you're using antivirus in 2019 you deserve whatever happens to you). It's still all irrelevant . Put a monetary or hum…
> I'm not going to talk about antivirus time because if you're using antivirus in 2019 you deserve whatever happens to you If you develop enterprise applications (which many Electron applications are, in fact :-) ), you really have to talk about antivirus time. It's not something you can wish away. And it's not something that you should ascribe to customers being irrational, either. If malware compromises your users'…
> If you develop enterprise applications (which many Electron applications are, in fact :-) ), you really have to talk about antivirus time. It's not something you can wish away.
In enterprise applications you totally can just wish AV away by turning it off. It's useless at best and mostly serves to just gum up the works and slow things down without providing tangible benefit. There are much better ways to handle security in an org.
Re: Cross-Platform GUI Toolkit Trainwreck (2016)
#97So 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…
This is a particularly good summary, thanks for that. At the end of the day, the only way for 5 to happen, is for a development project to architect the requirements and complexities way before even starting to code.
Re: Cross-Platform GUI Toolkit Trainwreck (2016)
#98We 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…
With Microsoft embracing Chromium as the built-in Windows rendering engine, enabling multiple Electron apps to run on a single instance, we're moving in the direction of Electron being the standard train your app can live in on any railroad.
Re: Cross-Platform GUI Toolkit Trainwreck (2016)
#99Wonder how the author didn't come across Qt or wxWidgets in his research?
I have the same question. There are many things that are problematic about Qt (personally, I loathe anything that feels the need to interject itself in the middle of the build process) but to completely ignore Qt without explanation - and subsequently post detailed experiences with libraries I've never even heard of - led me to believe the author exists in some uninteresting-to-me parallel plane of existence.
You mentioned it but, the strange meta object macro processing that qt depends up on, has been something I dislike. If I remember correctly GTK or other toolkits does not do anything similar.
And qt python bindings seems to be very poorly documented, same case with Java bindings.
Re: Cross-Platform GUI Toolkit Trainwreck (2016)
#100So 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'm working on something that might do #4 and #5:
An example of a small GUI app:
https://github.com/vlang/v/tree/master/examples/users_gui
The app is about 100 KB on all platforms with zero dependencies and uses native toolkits (WinAPI, Cocoa).