Cross-Platform GUI Toolkit Trainwreck (2016) • Hacker News Board

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#161

Post by slezyr » Fri, Apr 26, 2019, 1:43 PM UTC

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.

I can make a GUI in Qt and it will work on android, but I developed a simple time and there was a huge problem. When device goes to sleep it don't runs any code in background and I couldn't play or do anything on timeout. Does your framework solves any problem?

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#162

Post by netrap » Fri, Apr 26, 2019, 1:57 PM UTC

Weird article. Why write an entire cross-platform GUI toolkit when he could port IUP to OS X? :)

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#163

Post by Retra » Fri, Apr 26, 2019, 3:42 PM UTC

Wowfunhappy wrote: post #150

jcelerier wrote: post #134

Earlier quoted context omitted.

I want the complete opposite. I use the three systems almost daily, and I freaking hate to have to context-switch to the platform's look-and-feel. Thankfully KDE apps work mostly everywhere nowadays. Most of the users of the FOSS software I'm developing also switch platforms depending on the project they're in, but they want the software to be the same everywhere for instance.

Are differently-styled UI elements really a mental burden? I'm not advocating for wholly different UI's on each platform—just that if your application uses checkboxes, and I'm on a Mac, I should see Mac checkboxes.

It's probably more the behavior things. Keyboard shortcuts, focus behaviors, menu placement, file dialogs, etc. Settings panels in MacOs should take effect immediately, while in windows you have to click ok/apply... inconsistencies like this can lead to frustration.

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#164

Post by [deleted] » Fri, Apr 26, 2019, 4:40 PM UTC

rapsey wrote: post #46

ausjke wrote: post #29

Earlier quoted context omitted.

exactly, unless he really has something super special, QT should fix all his jokes. I don't use QT, but I think QT rarely has competition as far as cross-platform desktop GUI is concerned. the only true "cross-platform" alternative is electron, which is a bit bloated and slow, but vscode is built on it, along with many others and worked fine. I personally prefer electron these days.

Qt and wxwidgets pretty much force you into using C++ and maybe python. If you have to deal with all that baggage, then you might as well go build the UI layer native.

[deleted]

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#165

Post by pknopf » Fri, Apr 26, 2019, 4:41 PM UTC

rapsey wrote: post #67

grawprog wrote: post #61

Earlier quoted context omitted.

Huh? https://wiki.qt.io/Language_Bindings 5.1 Qt for Python (PyQt) 5.2 Qt for Ring (RingQt) 5.3 Qt for Rust (Rust-Qt) 5.4 Qt Quick for Rust (qml-rust) 5.5 Qt Quick for Rust (qmlrs) 5.6 Qt for Crystal (qt5.cr) 5.7 Qt for Go (qt) 5.8 Qt for C#/Mono/.Net (QtSharp) 5.9 Qt for C#/Mono/.Net (Qml.Net) 5.10 Qt for D (QtE5) 5.11 Qt for Haskell (qtHaskell) 5.12 Qtah 5.13 Qt for Julia (QML.jl) 5.14 Qt Quick for Haskell (HsQML)…

Most of these are limited to the point of uselesness.

I am the author of Qml.Net.

With it, you have the full power of .NET Core and QML. There really isn't any limits.

https://github.com/qmlnet/qmlnet

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#166

Post by canada_dry » Fri, Apr 26, 2019, 4:43 PM UTC

amedvednikov wrote: post #100

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'm working on something that might do #4 and #5: https://vlang.io/#ui 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).

V looks pretty slick, though your 'comparison' to nim (https://vlang.io/compare#nim) is incomplete.

i.e. you don't actually write comparable code. Instead, you just lambast how slow the compiler is.

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#167

Post by jcelerier » Fri, Apr 26, 2019, 5:18 PM UTC

Retra wrote: post #163

Wowfunhappy wrote: post #150

Earlier quoted context omitted.

Are differently-styled UI elements really a mental burden? I'm not advocating for wholly different UI's on each platform—just that if your application uses checkboxes, and I'm on a Mac, I should see Mac checkboxes.

It's probably more the behavior things. Keyboard shortcuts, focus behaviors, menu placement, file dialogs, etc. Settings panels in MacOs should take effect immediately, while in windows you have to click ok/apply... inconsistencies like this can lead to frustration.

this, and also the need to write three (or four if you want to do separate stuff for KDE & GNOME) times the amount of documentation to accomodate for the different "default" behaviours.

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#168

Post by Wowfunhappy » Fri, Apr 26, 2019, 6:40 PM UTC

Retra wrote: post #163

Wowfunhappy wrote: post #150

Earlier quoted context omitted.

Are differently-styled UI elements really a mental burden? I'm not advocating for wholly different UI's on each platform—just that if your application uses checkboxes, and I'm on a Mac, I should see Mac checkboxes.

It's probably more the behavior things. Keyboard shortcuts, focus behaviors, menu placement, file dialogs, etc. Settings panels in MacOs should take effect immediately, while in windows you have to click ok/apply... inconsistencies like this can lead to frustration.

But not doing this brings about an even worse kind of context switching—between apps on the same platform.

As annoying as it is to switch form cmd+C to ctrl+C when I go from Mac to Windows, it's even worse when a Mac app uses ctrl+C.

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#169

Post by ScottFree » Sat, Apr 27, 2019, 2:07 PM UTC

joezydeco wrote: post #24

ekingr wrote: post #12

Earlier quoted context omitted.

He jokingly mentions Qt in the caption of the final picture. I guess since he excludes GTK2 at the beginning for size concerns, wxWidgets and Qt would fall into the same category.

Making a Qt app smaller would mean statically compiling the app and stripping the libraries but, hey, there’s an angry blog post that needs to get written.

Can you link us to your blog? I'd like to read that angry post if and/or when you post it.

Re: Cross-Platform GUI Toolkit Trainwreck (2016)

#170

Post by joezydeco » Sat, Apr 27, 2019, 2:39 PM UTC

ScottFree wrote: post #169

joezydeco wrote: post #24

Earlier quoted context omitted.

Making a Qt app smaller would mean statically compiling the app and stripping the libraries but, hey, there’s an angry blog post that needs to get written.

Can you link us to your blog? I'd like to read that angry post if and/or when you post it.

I don't have an angry blog post about the size of cross-platform libraries.

Instead, I took the (longer) time to hand-tune Qt source and qconfig.h. My cross-platform desktop builds are under 2MB in a single executable, which appears to be something the OP wanted in the first place.