1) Buy a basic HTML template online for your app's dashboard.

2) Don't use Electon. Your users WILL notice and complain about performance. Instead, use the native WebBrowser control in .NET for Windows and WebView using macOS to display your UI. Disable right clicking and highlighting using HTML/JS. To the user, it'll feel like any other native app. Add this meta tag to the HTML file to ensure the WebBrowser control knows to use new versions of IE to render the UI: <meta http-equiv="x-ua-compatible" content="ie=edge"> (and/or look up how to add the FEATURE_BROWSER_EMULATION registry key)

3) Use the built in script calling functions to transfer settings back and forth between the UI and main app in JSON. Do the back end stuff in native code.

4) You can then re-use most of the UI code you wrote to easily port over to macOS. Use the same functions and logic you wrote on Windows to make your Swift functions.

* I've been making a living from building/maintaining my desktop application for about 5 years and had no regrets setting it up this way. I've also seen a number of other expensive, high-end, "professional" software using the FEATURE_BROWSER_EMULATION registry key trick.

Good luck!

Going to heavily disagree here. Whether or not your user's will notice is debatable in itself, but you shouldn't really factor that into your decision making.

Instead you should ask if your users would care that it uses Electron, and more whether they would be sufficiently put off to look for alternatives. And in a vast majority of cases the response to that question is going to be 'No'.

But the second part of this comment, I disagree with even further. DO NOT USE A NATIVE WEBBROWSER CONTROL FOR YOUR DESKTOP APP's UI.

Sorry for yelling, but that really is that terrible an idea. Most native webview components lag behind the embedded chromium instance Electron uses by a lot. Basic things that would work in IE10 are known to break on desktop webviews. Primary reason for this is that these webviews are only updated with OS updates.

End result is you will have to bend over backwards to get your UI working as expected on all these native webviews. This is just too much work and will end up diverting attention from developing core features of your app to fixing rendering bugs instead.

This is probably sound business advice, but it's also a bit sad to shift the goal from trying to create "great software" to "not horrible enough to make all potential users run away".

Webviews are okay on mobile though.

Just how far "back in the day are we talking? 'Cause I've see stuff ranging from VB (just VB, no .NET or WinForms) all the way back to MFC based UIs back in _my_ day. :)

I just feel like we should get our timescales calibrated.

IMHO, I guess for 'us' (this community of savvy power-users/developers) they'll be flaky when it comes to logging-in whilst switching apps to generate passwords and 2FA codes...

But to the average user that reuses the same login and password on several websites, it'll probably be good enough.

Do you have examples of that? I believe the majority of users will be running a quite recent version of Safari and Edge in these circumstances.

In addition, while Windows may now have an up to date version of Edge based on Chromium, which it now uses to render it's webviews, do you know that these Edge installations are not auto updated like Chrome/Firefox for Enterprise installations?

That means they will quickly fall behind from the current latest Chromium, and will throw bugs at some point in the future, when you rely on newer Chromium features. In addition, you will also get bug reports about your app being broken on some windows installations but not others and you will spend way too much time trying to figure out the issue, only to come to the conclusion that you can't really do anything other than change your code back to the older feature-set.

In addition, using Electron and bundling the Chromium along with it, allows you to control the Chromium version used, and you can be 100% certain that everything that works on that Chromium version will continue to do so, irrespective of the edition or number of updates installed on the user's computer.

Electron sets a very unrealistic eternal-greenfield-development standard that is nothing like developing for the web.

That is the problem though, some user expected software to meet the platform he is using, use latest function the platform introduce, meet the brand new style guide. Claims the software is creepyware if it isn't.

And of course, the developer don't have infinite time and can't meet every demands the users request.

Making functions works between different platform is tough enough. The developer is unlikely to have enough time handles all extra optional platform best practices under the situation that developer don't have enough time to make one software for each platform at first place.

How will people notice if you are using Electon, but not if you are doing this? Is Electron doing something that makes it unnecessarily slow or are you saying that people are just conditioned to think Electron apps are slower?

In that case, I would expect a large difference in memory footprint, although both options would be bad in terms of having a non-native user interface and user experience.

Is this incorrect?

Unless I'm missing something that I really don't understand...

I was quite keen on chrome apps, as they allowed you to share the chrome browser runtime in a similar way. If you add a native desktop shortcut, and use the chrome-hiding features then you can basically replace electron with a shared runtime. I have a dim memory that it may have been killed/hobbled now though...

A public example: Dwyrin is a YouTube streamer playing Go/Baduk. After most streams he reviews the game and likes an app called Sabaki. About 8:10 minutes in, he remarks on the performance of the app (https://youtu.be/vrX4qlbpQfU?t=492). Sabaki is an electron based app.

I do however disagree with removing right click / highlighting. That makes copy paste difficult or impossible for the typical user. I spent years working on Silverlight and UWP and one of the things I recall the team looking back on particularly with Silverlight and regretting was that TextBlocks by default didn't have highlightable text. Its too useful for users sharing error messages with you as the developer or data with each other to get their jobs done.

Electron likely helped Sabaki focus on other features with good enough performance, while being the best looking and most skinnable Go app by a country mile (I created a How to train your Dragon skin to temp my partner into learning Go :D)

Only so many hours to dedicate to a project, you have to pick what you value most. This comme T is partially because I'd hate for the people involved with Sabaki to not hear that at least some of their users "get it" and love it.

If you are making an application that you expect users to run as a background process, perhaps Electron isn't the best option.

If Electron is for an application users will open, use, and close, Electron is an excellent tool for the job.

My two electron applications as examples:

Video Hub App: https://github.com/whyboris/Video-Hub-App & https://videohubapp.com/

Simplest File Renamer: https://github.com/whyboris/Simplest-File-Renamer & https://yboris.dev/renamer/

I've never had good experiences with templates. They usually have too many dependencies or too many custom tweaks. There's one I'm using on a project at work (was chosen before I joined) and it's a huge mishmash of Bootstrap/Material Design and other stuff. Proper mess.

Much easier to just choose a style framework like Bootstrap and build it yourself.

2> Instead, use the native WebBrowser control in .NET for Windows

Use WebView2 instead. It uses the new Edge/Chromium rendering engine - https://docs.microsoft.com/en-us/microsoft-edge/webview2/

> The WebView2 Preview is intended for early prototyping and to gather feedback to help shape the API. You should not use the preview in your production apps because there may be breaking changes.

Or just use Electron

There's not much more to it than you can see, there's the BIM360 tab on the left that allows browsing through a cloud directory structure, and Civil3D also has a learning content tab.

Qt-based Software uses Qt WebEngine instead of the .NET stuff. The reason we're using HTML + JS is that we wanted to share the start page between different applications and HTML + JS is the lowest common denominator so to say, something that every team could integrate.

I suspect that the needed complexity of the UI factors in heavily as to how well this approach will work.

1. Sciter

- Languages: C++/Python/Go/Rust/Pascal (optional: HTML/CSS/tiscript)

- Development time: fast

- Resource usage: light (space and performance)

- Visual customization: easy, doesn't use native widgets.

2. Qt

- Languages: C++/Python (optional: CSS/JS/QML)

- Development time: slow

- Resource usage: quite heavy (space), but well performant

- Visual customization: QtWidgets: hard, QML: easy, doesn't use native widgets.

3. WxWidgets

- Languages: C++/Python

- Development time: slow

- Resource usage: light (space and performance)

- Visual customization: hard, uses native widgets.

4. Lazarus

- Languages: Pascal

- Development time: slow

- Resource usage: light (space and performance)

- Visual customization: hard, uses native widgets.

[1]: https://sciter.com/ - https://quark.sciter.com/

[2]: https://www.qt.io/

[3]: https://www.wxwidgets.org/

[4]: https://www.lazarus-ide.org/

The application uses exactly same code on all platforms: https://github.com/c-smile/sciter-sdk/tree/master/notes

It even runs on Windows 2000: https://sciter.com/necromancing-sciter-on-windows-2000/

I couldn't tell, just from glancing at the website/github.

UI, application logic and data storage.

QML is far not enough for this I think.

It took me 3.5 months ( https://notes.sciter.com/2017/09/11/motivation-and-a-bit-of-... ). But I shall admit that this does not include architecture time as I knew internal architecture of EverNote upfront.

I wrote a GUI editing tool using QML that had three main UI elements: a visualisation of the LEDs, a properties widget and a timeline. It also had start, stop, rewind buttons so you could play the animation back on the visualisation panel. The visualisation panel was also interactive to select individual leds. The timeline had time labels at the top which you could click to select a time and four “swimlanes” where you could draw the effects on, which controlled start time and duration (the rest of the parameters could then be set in the properties window, for the selected effect).

The led visualisation and timeline components were custom made (I don’t remember if they were made using custom QSceneNodes, QOainter or composed out of nested QML elements). The end result wasn’t particularly pretty, but I was going for functionality over look and the audience was limited to myself and one other person. The entire application (including the code to actually drive the leds, which ran on a raspberry pi, but shared code with the GUI tool to make the playback in the UI as realistic as possible) took 3 to 4 days. I’m sure given a few weeks I could have made it look really slick and given a few months could have made the UX something I would be happy to have other users use.

So I don’t know how long your application would take me, especially if it has to look identical to what you have, but I have been quite productive in QML, even when custom components were needed.

I’m not trying to say it would have been a better choice for you, though, just that I often find Qt and QML being under appreciated and underrated.

Although the Qt companies recent behaviour and aggressiveness in getting people to switch from open source to paid license had really put me off to the point where I’m not sure I’d use it for a new project, but those reasons are all not related to anything technical.

I do think Dart itself is a fine language, though.

I would actually say that it is perhaps the fastest in the list.

1.1k https://github.com/topics/pascal

27k https://github.com/topics/cpp

161k https://github.com/topics/python

The lack of sufficient developers who are familiar with Lazarus/Freepascal is a problem though. But again, this is a chicken and egg type of issue.

Getting up to speed in Lazarus does not take very long though because the IDE itself guides a person through in the components and you can clearly see the properties and components they have etc.

Compared to the challenge of wrangling many of these cross-platform frameworks to develop a desktop, it is a piece of cake in Lazarus.

Sadly, what keeps Lazarus back is the fact that most people aren't even aware that it exists and a perceived notion that it is not a cool/capable framework.

[1] http://scid.sourceforge.net/

Qt is good but it requires you to go fully into the Qt ecosystem (build tools, etc) not sure about QML though.

For wxWidgets, there is wxUniversal, which draws custom controls, thus easier to customize - not sure how well it is maintained though.

I'd argue that dev time is quite fast for all - Qt, wxWidgets, Lazarus.

It is just that there are absolutely no standard platform widgets (at least on Windows) for this UI. https://notes.sciter.com/wp-content/uploads/2017/09/notes-sc...

And even if there are some, integrating them with what your app is needed will lead to some mess like here:

https://notepad-plus-plus.org/assets/images/notepad4ever.gif

Custom components a la Windows 2000, some in Windows XP with default styled Windows 8 stuff - the zoo.

What people initially miss about UI libraries is composition features. Which are over the top for QML and not so to put is softly for Sciter.

Even if you're not legally required to implement it now, and even if you don't think this is a basic human right (which you should), there are legal changes coming, and you never know when you will be forced to implement it.

If you choose a library with great accessibility support, even though your app might not be accessible initially, fixing this won't be that hard. If you choose a library without one, though, when the time comes, you will either need to completely rewrite your app using a different library, or dig deep into native OS code and figure out how to interface with accessibility APIs, which is not an easy task.

This is a risk/reward scenario. The downside of choosing a library that supports accessibility usually isn't that bad, putting personal feelings about Electron aside. However, if you need accessibility someday, however unlikely that might now seem, you really don't want to be forced to drop everything and focus on rewriting that GUI layer fast, before the regulators catch you.

It seemed very unlikely that game developers would ever need accessibility, so no one cared. Then, the US government mandated that all chat systems must be accessible, and a lot of games include chat systems. That was not a pleasant experience for anyone. You never know what is coming, and you don't want to shoot yourself in the foot.

Now for some pointers. Electron is fine. No, really, Electron, is, fine. There's nothing wrong with it. QT is fine too. GTK works, as long as all your users are on Linux, as accessibility for other platforms is nonexistent. Java works on Windows, not sure about Linux and Mac. Anything that uses native widgets, so WX and native OS frameworks are the best, but not everyone can afford the luxury of choosing those. Game frameworks and small, minimal libraries are a no go.

That said, what happened to the last couple of generations? When did freedom stop meaning "free" and start meaning "fair" or "the right thing"? How did our culture get things so tangled up that our urge to "not potentially offend anyone" started eroding the very principals we think we are upholding? You must be young. /rant

Suggesting accessible software is a human right? You have to know how silly that looks compared to the list of other things that qualify as human rights.

I'd argue that what's truly silly is refusing to recognise that software/the web is becoming (if not has already become) as much core global infrastructure as physical equivalents are. We can't push for and actively build an increasingly online world and then plug our ears and pretend that the accessibility of online spaces isn't as important as the accessibility of physical ones.

Don't get me wrong. I agree with the OP in their ideals! Software is an increasingly important part of our lives, and accessibility should be taken seriously for any serious venture.

But legislation? Human rights? It's this kind of rhetoric that divides minds and undermines goals. By all means fight for what you think is right! Progress isn't inevitable. But attempting to impose change rather than affect change is the most classic mistake in the book. You must also be young.

Maybe by actually reading the charter and grasping that not every human right set forth in it necessarily concerns matters as grave as torture and slavery.

In fact, to quote it directly:

- Everyone has the right to freedom of opinion and expression; this right includes freedom to hold opinions without interference and to seek, receive and impart information and ideas through any media and regardless of frontiers (Article 19).

That right is eroded if the media platforms on which the vast majority of people communicate and disseminate information are not accessible to everyone - especially so when literal heads of state have taken to very active participation on said platforms.

- Everyone has the right of equal access to public service in his country. (Article 21 (2))

That right is eroded if public services are increasingly gated behind online channels that are not accessible to all. If one can't fill out the online form and then has to resort to a paper filing that might take days or even weeks to be processed, that's not equal access.

- Everyone has the right to work, to free choice of employment, to just and favourable conditions of work and to protection against unemployment. (Article 23 (1))

That right is eroded if one's (potential) employers move all their important processes online/into the software realm, behind products that are not accessible to people with disabilities. Yes, if employers are widely making Dreebly Chat (otherwise known as, say, Slack, HipChat, Discord, and so on) an essential work tool, then it's an erosion of disabled people's right to work if Dreebly Chat lacks accessibility.

And those are the more obvious ones from the original Universal Declaration of Human Rights, dated 1948. As I'm quite sure you are aware, the UDHR is and was intended to be the foundation of further articulation of globally-recognised rights and other legal frameworks - including the Convention on the Rights of Persons with Disabilities, a human rights instrument that became active in 2008. It goes into interesting detail on how the various articles of the UDHR specifically apply to disabled people.

But I'm quite sure you knew that already.

> But attempting to impose change rather than affect change is the most classic mistake in the book. You must also be young.

And you must also be of that curious class of people that regardless of age believe that legislation and politics are things to clutch pearls over rather than an integral part of society that people directly engage with daily, and then bloviate about how change "should" happen while remaining blind to how it actually does happen (largely through legislative and other political action).

Similarly, I'm confused by your example of an employer moving essential services to non-accessible software because your are not blaming Dreebly Chat for making non-accessible software, rather, the employer for choosing to move to a platform that discriminates against its employees. You seem to understand where the blame lies... and it doesn't support your premise.

My critique is certainly levied against legislation, not "other political action". In your haste to make a counter-argument you may have forgotten what you are arguing against.

0) All advice depends a lot on the product. Most general advice is just useless.

1) Preparing for potential changes in legislation is most of the time not a good idea. As you said you never know what is coming and so you should not try to prepare for everything. Also said games you mention could probably disable the chat if implementing accessibility features was to costly. Also these changes don't come over night.

2) I really dislike what people try to cramp into basic human rights.. Do you also expect this from open source software? Do you really think if people spend their free time they are obligated to implement accessibility or whatever else? In my opinion the user of open source is entitled too nothing.

3) Electron, is, not, fine, just, like, that. There are tons of Electron apps out there which have no right to carry hundreds of megabyte with them and consume that many resources. I am pro choosing whatever you want. But please don't advert Electron as "is-always-fine".. If you even want to force accessibility.. what about energy consumption?

You might miss or be unaware of accessibility concerns when developing, but it's easier to go back and fix what you missed than it is to build an entire ui and go back and add accessibility to begin with.

As to electron, if you want to leverage web skills to build a mobile app, it's a cromulent solution. I don't think big companies with resources should use it (slack), but for JS devs who want to build things, it's a great tool. Most people I work with don't realize slack and vscode are both electron apps.

In my opinion, this depends whether the software in question improves the lives of its users or makes the lives of non-users worse.

If it's just another media player we don't have to use, accessibility would be cool, but it's not really that important. If it's a chat solution for companies, accessibility is absolutely crucial, open-source or not. Not implementing accessibility means people could lose their jobs if their companies switch to it. Society would be better off if this software never existed in the first place.

In any case.. if a company would adopt such a software and then fire people because the software is not accessible, then a lot is wrong but it is not that software.

Protect employees' rights properly by all means but don't come up with stupid legislation that forces open-source software to do anything. This will just result in less open-source software or worse quality.

Sometimes I wish we could disable all open-source software for a few days, so people would actually value what others do for free. It seems to me that these days a lot of people think the are entitled to all kinds of things.

Zulip? Jitsi Meet? Matrix and Element? Even GitLab falls into that category. Not strictly chat, but crucial company software nonetheless.

> Protect employees' rights properly by all means but don't come up with stupid legislation that forces open-source software to do anything. This will just result in less open-source software or worse quality.

So, in essence, forbid companies from using inaccessible software of that kind? That's pretty close to what I'm proposing, instead of banning the creation of that software, ban it's use, which, ultimately, comes down to the same thing. Also whether software is open source, freeware or for-pay does not matter in this discussion.

> Sometimes I wish we could disable all open-source software for a few days, so people would actually value what others do for free. It seems to me that these days a lot of people think the are entitled to all kinds of things.

Doing the work for free doesn't justify doing work that harms the society.

If I gave out poisoned food for free, I would still be as liable as if I sold it. Sure, it means there is less free food given out, but ultimately, it's a net gain.

Non-accessible open source software is more like running a food stand at which you give out free food, but the food contains peanuts, which is clearly stated on your sign. "contains peanuts" ≠ "poisoned".

Gitlab is not a chat software.. however my introductory sentence wasn't really important so maybe I just should have skipped it.

> So, in essence, forbid companies from using inaccessible software of that kind? That's pretty close to what I'm proposing, instead of banning the creation of that software, ban it's use, which, ultimately, comes down to the same thing.

No I don't say you should forbid companies from using whatever software. I said protect the employees. Which in this case means that a company should not be able to fire a person that cannot use a software the company introduced.

Besides that it is not even the same thing because not only companies use open-source software.

> Also whether software is open source, freeware or for-pay does not matter in this discussion.

It matters A LOT. Forcing your expectations of what is right on people that create things and give them away for free is entitled. If you want to sell something this is completely another story.

> Doing the work for free doesn't justify doing work that harms the society. > If I gave out poisoned food for free, I would still be as liable as if I sold it. Sure, it means there is less free food given out, but ultimately, it's a net gain.

Both of these statements are utterly ridiculous. Harming society with a (free) software that is not accessible? Comparing poisoned food with open-source software... I don't even know what to say about this. I will drop out of the discussion. Good luck on the accessibility crusade.

For the record, the default choices for text size here on Hacker News are an example of ignoring basic accessibility.

Also, pushing responsibility for dealing with poor accessibility onto the person with disability is exactly the attitude that itself perpetuates the problems.

Personally i have strong myopia yet i heavily dislike how large fonts are everywhere and i prefer Hacker News' font size.

This I know. However, better-designed sites allow the user to customize the default font size.

If one was required to achieve 100% consensus on default font size, nobody would ever get anything done.

Java on Linux/Mac is fine.

Never have to comply with the law if you never have any users to begin with

GTK user tapping head

Why?

1. Cross platform - Mac OS, Linux and Window and Raspberry Pi https://www.lazarus-ide.org/

2. VERY fast development and compile-run cycles. You are talking about WYSIWYG designer and compilation in seconds.

3. Fully native binaries which are very small and very fast.

4. It is a full fledged RAD environment with full support for GUI development using a very powerful designer.

5. There are GUI as well as non-GUI components - example: Database components, Database-aware grids, database aware-listboxes, search filters etc.

6. Very diverse set of components. And very easy to develop new components from scratch or customise and existing component.

7. The object structure is very powerful - with support for read & write properties, composite components, property setting pages, internationalisation etc.

8. It is possible to interface with C/C++ libraries as well and that isn't complicated

9. Lazarus has a built-in debugger which is quite powerful and the development environment has full integration with it.

To see a demo of the Lazarus IDE including the debugger functionality, please see the video in the page below: https://www.getlazarus.org/new/

10. Lazarus is 100% open source and is under active development with the last release in July 22, 2020.

Lazarus is not a new fad language. It has been in existence for decades and there are existing apps which are developed in it - example, the Transmission GUI client.

Other projects done in Lazarus: https://www.getlazarus.org/community/showcase/

Projects by category. This is not a full list: https://wiki.freepascal.org/Projects_using_Lazarus

A file manager has to plug into multiple native features, e.g. the list of app associations—and DC does that sorta half-assedly.

I ask because I'm a big fan of PowerArchiver as my go-to archive manager on Windows over the usual 7-Zip/WinZip/WinRAR/etc, it's a Delphi app, and it has a nice GUI: https://www.powerarchiver.com/

So it is best to see Free Pascal & Lazarus as the free and open source alternative to Object Pascal & Delphi respectively.

Of course, now the term Object Pascal is not used at all. Delphi is used to refer to both the language and the IDE now.

About Free Pascal, it is largely compatible with Delphi/Object Pascal but there are minor differences. https://wiki.freepascal.org/Lazarus_For_Delphi_Users

Here is a write up on the advantages of Free Pascal: https://www.freepascal.org/advantage.var

I am not associated with the Lazarus project at all but I did develop in Delphi over 22 years ago and I still do some development using Lazarus. I hope to do some tutorial videos on this to help those new to the environment.

Worth mentioning that at least one excellent piece of commercial software, Beyond Compare, targets Windows with Delhi but Linux and MacOS with Lazarus.

https://www.scootersoftware.com/

I haven't tried the Linux version but it'd be useful to look at, for the sake of comparison.

A few months ago I developed a Kanban tool to organize my personal tasks. I use the tool under Windows and Linux, it works fine.

For me the big advantage of Lazarus/FreePascal is that you have to write the business logic only once and you compile the code for different environments to get native binary files (no interpreter used). In case of operating system specific code you can use conditional compilation (e.g. {$ifdef MSWINDOWS}) but in my case that wasn't really necessary.

Freepascal Runtime Library documentation: https://lazarus-ccr.sourceforge.io/docs/rtl/

Lazarus Component Library: https://lazarus-ccr.sourceforge.io/docs/lcl/

Freepascal Component Library: https://lazarus-ccr.sourceforge.io/docs/fcl/

Freepascal Wiki: https://wiki.freepascal.org/Lazarus_Documentation

Something else I should have added in my original comment: Lazarus has a very capable built-in debugger.

That is invaluable if you want to step through and understand how things work.

EDIT: Other sites:

Some demo projects here: https://www.getlazarus.org/

Lazarus project showcase: https://www.getlazarus.org/community/showcase/

The Transmission Bittorrent GUI client was done in Lazarus: https://sourceforge.net/projects/transgui/

Other apps done in Lazarus from the Lazarus website shown by category: https://wiki.freepascal.org/Projects_using_Lazarus

However packages (which includes your own widgets) are nothing more than native libraries that become part of the IDE, so any bugs in a package will cause the entire IDE to crash. This is a double edged sword since on one hand you can get a less stable IDE from your own bugs, but on the other hand when you work with a component or widget in the visual editors, you are really working with a "live" instance of that widget that is then serialized as part of the form or data module instead of a mock stand-in object that some other GUI-only designers will give you. Also this allows you to use any TComponent-derived object through a visual editor, not only visual/GUI objects.

I wrote a little framework for this: https://github.com/jdarpinian/web-ui-skeleton

Running inside a real browser also limits the keyboard shortcuts you can use, because you don't want to clash with the browser's own shortcuts.

The obvious way to keep the browser authenticated is a session cookie. But cookies are shared between all ports on a domain, so a local attacker who tricks you into visiting another localhost service in the same browser can steal the cookie. localStorage doesn't have that issue, but it's not so convenient for authenticating requests.

This is getting weird very quickly (not to mention that Ctrl-S in browser windows saving file without confirmation is a UX I wouldn't want to use)

There are several decent options. You could build a modal that displays a view of the file system sourced from the server. Or you could pop a real native file dialog from the server, and I'm betting it's possible to either make it a real modal of the browser window or do a good enough simulation depending on platform. Or in the future you could use the native file system API that is currently in origin trial.

I submit that this is not weirder than most cross-platform UI toolkits that implement their own whacky replacements for the native file dialogs.

See https://www.w3.org/TR/secure-contexts/#is-origin-trustworthy

Exposing a HTTP port with application state is a million times worse for security

Sounds like you already know the big players so I won't repeat them. Instead, here are some off-kilter ideas:

1. Casual use, general interest, notification-requiring, simple single-file data requirements, tolerant of desktop / mobile split sessions? Try making a chat bot for Telegram, FB, Discord, Slack..

2. Dynamic, visualization-focused UI with simple options that need to be tweaked interactively? Try Imgui[0] or Godot[1]

3. Scientific or data-centric stuff pulling in data from here and there, but meant for interactive exploration? Try Wolfram / Mathematica or an IPython notebook / GoogleColab

[0] https://github.com/ocornut/imgui/wiki/Software-using-dear-im...

[1] https://medium.com/swlh/what-makes-godot-engine-great-for-ad...

Cool recommendations, thanks!

1. design things using an MVVM pattern and share all your business logic

2. write all your native gui code manually as you tease out the patterns

3. over time, you can start moving the UI generation into the shared code by writing a custom DSL

The problem with platforms like React.Native and Elecron is that they are based on having a JS runtime, which is a de-facto performance hit and forces an async communication flow to the "native" side (flutter also has this issue). Xamarin does not have that same restriction, and is my preferred framework for this. Xamarin.Native (aka Xamarin.iOS/Xamarin.Android aka Xamarin.Traditional aka Xamarin) has a very minimal performance overhead for what it gives you in terms of native bindings and a shared codebase. Xamarin.Forms is a higher level abstraction that sits on top of Xamarin.Native and lets you theoretically write 100% shared code (by essentially being a community developed UI DSL like I outline in step 3 above), but it is buggy and has much worse performance.

The hardest problems you will have to solve using this approach are navigation and lifecycle. For the most part these are well understood issues and you will find lots of postings with different strategies on how to approach them.

https://github.com/styluslabs/ugui

As a Mac user I prefer native applications if available. But still, I would consider a well-written Qt application.

For example, qBittorrent is quite alright.

https://en.m.wikipedia.org/wiki/Qt_(software)

https://www.qbittorrent.org/

Where should I look? I’m willing to put in the work!

http://zetcode.com/gui/pyqt5/

There are a few others here:

https://wiki.python.org/moin/PyQt/Tutorials

The 2020 one there may be what you're looking for, more than hello world but doesn't quite all the way get to the kitchen sink, just maybe the silverware drawer.

Qt is LGPL. PySide is LGPL. PyQt is "GPL but allows you to link from popular open source licenses".

https://riverbankcomputing.com/pipermail/pyqt/2014-February/...

So it is more like MIT licensed projects give you the freedom to use in a GPL project.

https://en.wikipedia.org/wiki/GPL_linking_exception

https://riverbankcomputing.com/commercial/license-faq

https://upload.wikimedia.org/wikipedia/commons/e/e8/Qt_Creat...

I always see Qt mentioned, so I'm definitely not trying to discredit it. I just never seem to see common examples with it compared to something written in Electron.

The comparison to Electron is somewhat flawed though. I mean, the GUI in an Electron application owes much more to whatever library they choose than to the fact that it runs inside Electron. Electron provides no particular GUI elements to the developer.

Now, don't let the screenshots color your impressions as to what kinds of UI designs are possible under Qt: Ripcord's UI is bare-bones on purpose; it's a selling feature. I bring up this application because it lets you do a more apples-to-apples comparison: IM clients these days are a poster child of an Electron app that uses orders of magnitude more resources than they should for the functionality provided. Ripcord lets you compare the experience and performance with a native app, implementing the same features but without overhead and gratuitous UI shine.

(And personally, I do use it for Slack/Discord instead of official clients.)

Autodesk Fusion 360 uses Qt[1]. (It's 3D CAD modeling software like Solidworks/Inventor). Some screenshots of its UI : https://www.google.com/search?q=%22autodesk+fusion+360%22+ui...

CAD/CAM modeling software is resource intensive and users always complain about slow performance when manipulating big files so writing that type of app in Electron/Chrome/Javascript browser engine would be worse than native C++/Qt.

That said, another competitor Onshape is browser-based and yes, people do complain about its performance.

Some other well-known desktops using Qt are Autodesk Maya and Wolfram Mathematica.[2]

[1] https://forums.autodesk.com/t5/fusion-360-api-and-scripts/wh...

[2] https://en.wikipedia.org/wiki/Category:Software_that_uses_Qt

If you want to go the route of running a server on the user's machine and serving it through the user's browser, ClojureScript and Reagent/Re-Frame are excellent choices. Re-Frame, https://github.com/Day8/re-frame, in particular has very nice documentation.

Clojure lets you use anything in the Java universe while ClojureScript gives you access to all the JavaScript stuff, including Node.

There is a lot of tutorial information for both languages.

Could you provide a concrete example?

Intuitively I do understand ClojureScript is not as seamless as some people say. First of all, Clojure is kind of a database-programming language with fundamental data types built around concurrency, while JavaScript was single-threaded until recently (and web workers used shared-nothing model). Second, Clojure is build around Java specifically, not any other language. Java has some strict type system with immutable complex objects being pretty much native way of doing things, thus Java is great for implementing dynamic types on top of it.

But I feel like not having undeniable proofs of fundamental flaw in ClojureScript. For example, JavaScript fundamentally lacks copy-on-write complex structures. Thus development of copy-on-write libraries is painful e.g. ProseMirror which can become completely broken until page reload which is bad for Single Page Application. However, could it be that ClojureScript... just works?

I wish I could, it's been years since I've actually written or even read any ClojureScript. But I can offer something more general. Many core functions expecting a collection type would blow up deep in the call stack, usually in helper functions not exposed or documented in the core API, when passed a value which provides no iteration. I would encounter these scenarios frequently when recursing over a nested structure (e.g. oops I passed a keyword or a function to `map`), or when I simply got argument order wrong.

Like I said, this eventually drove me to static typing, and I wouldn't ever consider a language without it again. Most dynamic languages have too large a core interface to commit it to memory, and even "small" languages reproduce that in the libraries we build.

Clj-kondo is good to detect unintended passing, in terms of correctness there are sometimes minor fixes but not at the expense of backwards compatibility which is taken very seriously in core

In terms of doing idiomatic Clojure in Typescript, "good" Clojure is data driven Typescript is type driven

Universal data primitives Vs label everything with types aren't terribly compatible

For the most part I agree with this, but... it's not saying much.

> In terms of doing idiomatic Clojure in Typescript, "good" Clojure is data driven Typescript is type driven > > Universal data primitives Vs label everything with types aren't terribly compatible

Huh? What I said is that I try to apply the principles I learnt in Clojure—yes, including writing code that is data-driven, and more importantly value driven—in the most idiomatic way I can within TypeScript. Yes, the whole point of TypeScript is types (it's in the dang name), but:

1. Types describe data. The only major difference between the kind of data described in TypeScript and the kind of data implicitly defined in Clojure is that TypeScript inherited a runtime where mutability is the default and immutability is more a choice of convention than an actual feature of the language.

2. The TypeScript type system is extremely good at describing and statically validating the kind of dynamic polymorphism common in Clojure.

3. Even if it isn't, small and specific interfaces could be used as contracts to achieve roughly the same thing, just with more keyboarding.

It's slow to render? Wrong, Electron (Chromium) renders faster than Qt. The Skia engine is optimized to an extent that these other toolkits cannot compete with. It even has a Vulkan backend now.

Single threaded? The render process is--you can use any native multithreaded code you want in another process.

Memory? It's 70MB. That's nothing nowadays. Modern OSes can page it in and out when the application is idling. A lot of these other toolkits are quite heavy too, especially JavaFX in my experience. Also what happens when you need a webview in one of these other toolkits? In Qt you get an embedded instance of Chromium[1] so not only do you have the 70MB of Chromium, you also have the Qt runtime (!).

The reason the Electron app you're using is slow or hogs giants amount of memory is the Javascript code itself is slow. Yes, Slack is a slow monster, but it's a giant codebase that does things that would be simply impossible in Qt, GTK, Swing and others. There's a reason we never saw these types of apps when the only frameworks were Qt and others.

[1] https://doc.qt.io/qt-5/qtwebengine-overview.html

Because it looks ugly (i.e. non-native) on pretty much every platform. Qt has different levels of success at that, having most problems with macOS and Android.

Also, there's Qt Quick, which lies somewhere in the middle between classic Qt and Electron.

>It's slow to render? Wrong, Electron (Chromium) renders faster than Qt. The Skia engine is optimized to an extent that these other toolkits cannot compete with. It even has a Vulkan backend now

The reason why classic single-threaded GUI toolkit are the way they are is because you can perform a custom reactive drawing or just reactive UI update in a blink of the eye, so user won't notice any delay. I know there are some bad examples like java-based IDE bloatware, but there are good examples like... Chromium! However, you cannot develop Chromium with Chromium, but you can develop something similar to Chromium with Qt.

>Memory? It's 70MB

Haven't seen Electron application using less than 200 Mb of memory. For example, launching Skype plus chromium SPA takes 550 Mb of RAM on my system. JavaFX has similar problems.

>Slack is a slow monster, but it's a giant codebase that does things that would be simply impossible in Qt, GTK, Swing and others

Like what? I'm not aware of any special Slack's features that could be hard to implement using classic GUI toolkits.

> However, you cannot develop Chromium with Chromium

Why not? You can run Visual Studio Code in the browser and edit the Chromium source code. Perhaps, given sufficient memory, you can also run clang in the browser (WASM) so you can compile and link in Chromium too.

> Because it looks ugly (i.e. non-native) on pretty much every platform.

I'm not sure if you're talking about Electron or Qt because this statement applies equally well to both. Electron, Qt, Swing, JavaFX, Flutter all take the approach of drawing every pixel themselves, not using any "native" widgets rendered by the OS vendor.

Anecdotally all the Electron apps I've used have been beautiful whereas the Qt/GTK ones look stuck in the 90s.

Old Skype was a P2P networking application, which is a way more complex functionality than Slack's client has (excluding Chromium itself), but it was invisible to a regular user. Server side of Skype had only basic things like authentication, simple messaging, contacts data, and telephony gateways (paid service). It didn't even store message history on server side, which was PitA. Contrary, Slack has a lot of heavy logic on server side thus taking heavy financial losses and unable to become profitable.

>Perhaps, given sufficient memory, you can also run clang in the browser (WASM) so you can compile and link in Chromium too

I wass talking about framework/toolkit, because we are talking about framework/toolkits. You cannot run Chromium in WASM to debug it, and it would take days to compile chromium in clang-WASM.

>Electron, Qt, Swing, JavaFX, Flutter all take the approach of drawing every pixel themselves, not using any "native" widgets rendered by the OS vendor

There are no native widgets on Linux and other posixes, so your statement is true for them. However, for Windows Qt is able to optionally use native drawing routines. Firefox and Chromium use native routines too, but the extent is way more restricted. Also, Qt allows you to use fully platform-specific features, which is very problematic in Electron. The most basic example is date formatting, which almost never works the same way native applications work, you always get small differences here and there.

>Anecdotally all the Electron apps I've used have been beautiful whereas the Qt/GTK ones look stuck in the 90s

Heavily depends on applications you used. I don't think you tried to use any 10-years old electron application, because electron itself is 7 years old. Have you used VirtualBox?

Like what?

It’s objectively orders of magnitude more complex than a messaging app. Heck, it used to have messaging built in at one point I remember!

Also, I’ve done a bit of Qt and while I don’t have an example (I’m sure someone else could supply one- finance back/front office?) it’s predominantly used with C++ which scales to millions of likes of code.

What year?

HTML snippets rendered for free (no need for an external HTML renderer)

Lots of little things like <video> being enough to embed a video into the view versus subclassing a C++ Qt class or whatever song and dance it is in other frameworks. It's productivity that's the killer feature. You can theoretically do everything Electron does in Java Swing, but it would require reimplementing most of the web platform.

Video - I drag and dropped video players onto UI forms 20+ years ago. <video> is a joke - you need something like video.js to make it functional in the real world and at that point, good luck on 'simplicity'. Adult sites have entire teams working on their video players, how messed up is that?

The problem today (old fart mode on) is that when all you have is a hammer, everything looks like a nail. And it seems that people don't even just only have a hammer, they don't even know what things that are not hammers look like.

Server-side rendering is a business need not a programming need. A company like Spotify may want to change the UI without updating the installation. To do this on the web platform is a well-supported pattern. To do this with Qt you'd have to implement your own HTML- or JSX-like framework on top of Qt (like Hyperview does for mobile).

Companies that use Electron can just move faster and crush competition. That's why there are billion dollar companies based on Electron programs and Qt people get excited about it being the software behind the radio volume button on the latest model fishing boat.

The topic is about general desktop GUI applications. Some users of desktop applications don't even have internet connection e.g for security considerations. Tell me more about changing application UI without internet connection.

I did that 20+ years ago too and no I didn't need an 'HTML- of JSX-like framework'. Again, when all you have is a hammer...

What are you going to do with the video? Coz that's where the problems with electron begin to appear. For example, you want some controls for seeking, displaying time, copying link, full screen, etc. And suddenly you get yourself a slow youtube-like monster. I really wish I could continue to use flash-based youtube, because I had no performance problems with it.

>HTML snippets rendered for free (no need for an external HTML renderer)

Slack doesn't need to render html snippets.

I mean really. How would any of Slack's UI be impossible in QT? And conversely, if HTML is so good, why have we never actually written any applications with it, and instead rely on templating languages?

In a sane world we would already have webviews on all platforms and the problem mostly solved for client applications. But there's a lot of forces at work that want to artificially suppress web UI. Chromium doesn't have webview on desktop platforms, but Microsoft's chromium edge does. Apple puts in their special restrictions making up rules for any app that uses wkwebview.

Nobody with the power wants to make webUI universally deployable.

At the end of the day you choose one that you'll actually deploy something with. There's no more right or wrong in UI, it's can you get to the goal of deploying a functional app or not.

There is undeniably a problem with flutter however: while it can be used for desktop applications, it's mobile-first, desktop-sec.. well... desktop-kinda-sorta-works...

https://github.com/flutter/flutter/wiki/Desktop-shells

https://flutter.dev/desktop

Still, it seems like Flutter will be a good option once desktop support is more stable.

We did the business case for cross platform, as we’re a non-tech enterprise organisation with 10.000 employees but few developers. We wanted flutter to win, but react native came out like the sound choice.

What makes you think that?

They have spent more than 3-4 years with millions of dollars on it.

https://flutter.dev/showcase

I still prefer Kotlin, but there have been very, very few occasions where I've not been able to do what I wanted with Dart.

Isn't WebView kind of work around for web browser being overbloated? I mean they made single instance of browser and interfaces for embedding that single instance, but do you really need that for desktop?

There are thousands of hours of video tutorials on how to build cross platform apps with FireMonkey on YouTube. But really it is just all built into the IDE. Select the platform. Compile. A Linux machine and a macOS machine are required to compile for those platforms. Because it is an integrated IDE everyone is together so there is less tooling to fight to compile for all platforms.

Plus Delphi has staying power and plenty of history (25 years) behind it just like Python and PHP (verses newer languages and frameworks which may not be around later).

There are other libraries available for Delphi that let you build apps like Electron (webview based apps) or entirely using native controls on iOS using Storyboards if you prefer that way.

If I can self promote for a second here are 100 cross platform sample apps built in Delphi: https://github.com/FMXExpress/Cross-Platform-Samples

Price seems to range from ~$2000 to ~$4500 to use it, which feels a bit steep.

https://www.embarcadero.com/products/delphi/starter/free-dow...

Yeah, I feel like Embarcadero/Borland took a completely wrong turn with their price policy. Instead of making the tool widespread and make small money from huge amount of places, they decided to go on full vendor-lock where you either get all or nothing, so Borland got nothing eventually and ceased to exist. That also burried my carrier prospects in that area, which is so sad considering how good the Pascal is as a language compared to C/C++.

I use Delphi and this is the main reason why is not widespread.

When people criticize Electron, I don't think they're saying "given your capacity, you should have picked a different and better point on the tradeoff curve". I think they're just mad that you had the requirements you had and didn't get to apply more resources than you had access to.

So, at first it sounds like they're making a technical argument against anyone who would choose to use Electron, but I think what they're actually doing is instead expressing some kind of economic disappointment in your situation.

(I would probably use Electron on a small budget, Qt on a medium budget, and native apps on a large budget.)

This is a fair assessment. Still, this disappoinment is worth expressing as it makes it clear the current situation (lack of high-quality, mature, cross-platform toolkit using native widgets) is frustrating. You shouldn't be choosing between spending a lot of resources doing things right and spending a reasonable amount producing an inneficient monster that drains your users' system resources.

The particularly annoying part about economics here is the "limited oxygen" nature of software products. If you and I both develop a software tool, but I decide to rush it with Electron while you take it slow with native app per platform, I get to (assuming the tool is a-ok) "suck the oxygen out of the space" by releasing first, and you may lose the motivation/market to create the better tool.

Which is to say, "good today" may be better than "perfect next week", but the big reason why software products suck so badly is that "shitty today" is considered better than "good tomorrow".

AFAIK, this is not correct, as WxWidgets fits the requirements (it's almost 30 years old, cross-platform and native).

I'm curious though, since I haven't extensively developded GUI applications, which are the pratical tradeoffs against a non-native toolkit like Qt.

I don't buy it, something doesn't add up. The look and feel is somewhat out of place, one can tell with one glance it's not native. https://i.imgur.com/LjDhPOv.png

• The scrollbars are too narrow and have only a down arrow at the bottom instead of a combined up and down arrow.

• The font size is wrong in some places in the hex editor.

• The tab in the tab bar is crooked, not rectangular, and lacks a close button.

• The text has too cramped kerning, most noticable in the word "File".

• The underline for key shortcuts is placed too high.

• The ribbing in the lower-right corner is larger.

• Contrast around the menu bar is too harsh.

• The icon bar does not lock (context menu), and always displays a grabber.

• Menu bar and icon bar do not have a context menu.

• The ribbing on the left-right split bar is different.

• The MDI panel only has a close button but not a detach button. There's a obtrusive gradient in the panel title.

• The progress bar does not have the stripe pattern.

I submit that Wx implements its own non-native widgets.

It does for the widgets that have no native equivalent, such as draggable/dockable tabs/panels that you show. You can't say they differ from native ones because there is just no native version, on any platform.

OTOH all the standard UI elements (buttons, checkboxes, text controls, date pickers, ...) are native and not only they look natively, but also behave natively, which is pretty important and different from Qt.

PoEdit comes the closest to looking genuinely native, but the MacOS implementation is clearly flawed.

[1] https://www.wxwidgets.org/about/screenshots/

Or check "Game Develop". The primary interface is a kind of weird rip-off of the MS Office ribbon, but I assume this is a custom widget. There's also a tab interface though, and this doesn't work on either the Windows or GTK versions: it's weird and has a gradient background.

In general, small details like the padding, coloration, and borders drawn around widgets seem to be slightly off on most platforms with just about very wx based GUI I've seen.

The rest of the controls (ribbon, tabs) are indeed non-native and there are no native equivalents for them, so there is not much to say here.

Generally speaking, there shouldn't be any problem with the colours unless you change them explicitly, which is a bad idea for the native controls. Not sure what is wrong with the padding and borders.

Well, let's verify that… https://i.imgur.com/uHfjoUs.png No, they're not.

> draggable/dockable tabs/panels […] You can't say they differ from native ones because there is just no native version

That sounds wrong. Why should they not be? Do you have any proof?

Sorry, I don't know what is this supposed to prove, but I can definitely assure you that all the mentioned controls, and many others, are exactly native controls under the 3 first tier platforms (MSW, GTK and macOS).

> Do you have any proof?

Proof of absence of something is hard to make, all I can say is that you can go through MSDN, GTK and Cocoa documentation to convince yourself.

Regardless, since you're accusing a very old and widespread project of lying ("it uses the platform's native API rather than emulating the GUI" on their front page, versus "I submit that Wx implements its own non-native widgets."), you should directly ask on an official channel, and have an authoritative answer.

> since you're accusing a very old and widespread project of lying

http://enwp.org/Appeal_to_accomplishment Nice fallacy, don't think you can pull cheap tricks like that on HN.

But anyway, let them defend themselves; veritas liberabit vos. FWIW I don't think malicious or intentional lies are involved, although a mighty good explanation is required to square their claim against the evidence that it is plain to see.

Note that one of the posters you've been arguing with ("VZ"; argument here: https://news.ycombinator.com/item?id=24259040), turned out to be the WxWidgets maintainer. According to the comment though, mentioning this constitutes a cheap trick <rolling eyes>.

Regardless, there is a very interesting concept in the explanation: using native widgets through WxWidgets (and possibly, widget toolkits in general) requires following specific guidelines. Failing to do so will make the widgets look bad, even if they're native.

  First of all: The "VZ" who wrote in the thread you linked, is Vadim Zeitlin, the
   core maintainer of wxWidgets. His word is the highest authority in the wxWidget
  s world.
  
  My 2 cents:
  
      are all the widgets provided by WxWidgets native?
  
  No. But if a native implementation of a control exists on a specific platform, i
  t will be used (i can't think of any exceptions right now, but it's possible the
  re are a few).
  
  Most widgets are native on all platforms, e.g. wxButton, wxTextCtrl, etc.
  
  Then there are widgets that are only native on some platforms. E.g. wxDataViewCt
  rl. Is has native implementations on OSX and GTK, but as no such control exists 
  under Windows, a generic implementation is used there.
  
  Then there are widgets that have no native implementations at all, e.g. wxGrid.
  
  In general, wxWidgets just gives you the toolset to develop crossplatform GUIs. 
  That doesn't guarantee it that they'll look good everywhere out of the box. This
   also requires "good" behavior of the developer. E.g. they should not use absolu
  te values of controls sizes and positions, but use wxSizers (the wxWidgets layou
  t system) instead. Lately they must also be prepared for high-dpi screens, good 
  support for that is only available in wxWidgets for a few weeks now.
  
  Also, many open source developers only develop on one platform and hardly ever o
  r never test on other platforms. Often they just don't want to invest more time 
  to make their application look good everywhere.
  
  Regarding https://imgur.com/LjDhPOv
  
  wxHexEditor uses wxAUI, this is not native anywhere. The window with the hexdisp
  lay could be custom drawn, there is no control that does this out of the box. Or
   it might be a wxGrid, hard to say.
  
  wxMP3gain looks fine to me
  
  easyMP3Gain seems to be one of the case where the developer just didn't care to 
  make it look good.

With native UI, eventually the development will stop. With cross-platform, you will, FOREVER, try to catch up.

P.D: i have used more than +12 main languages and as many or more UI toolkits.

The native UIs are running even close to a DECADE without nothing of significance on maintain. The rest? is rewrite, recode or workaround....

If I can buy a cheap roof for $2k but have to replace it every year, or an expensive roof for $15k that will last 50 years, then LONG TERM the cheap roof is the more costly option.

But if I only have $2k instead of $15k, I'm not wrong to buy a cheap roof. Yelling at me about the long term costs of the cheap roof is missing the point. You're just saying that you're disappointed by my lack of $15k.

This happens a lot, because some of the "advice" in this industry is for "startups that if not ship something like now will die", when the majority of the work is not that disposable...

My constraints were:

- I'm not starting a desktop application project in C++ today.

- I don't want to do the heavy lifting for complicated widgets myself.

- I want to have the performance of compiled code without concurrency limitations (so no Python or Ruby).

- I want at least a reasonable facsimile of native look'n'feel on the three major desktop platforms.

- I want accessibility as at least an option.

If I don't want to buy dev tools like LispWorks or Delphi, then I'm left looking at Java + Swing or a backend in Java or .NET and a web frontend.

Then I look at Dolphin Smalltalk or Corman Lisp which are now open source on Windows, and they're phenomenal development environments that target Win32 directly instead of the layers added above it. macOS has excellent dev tools for just macOS. On Linux, GNOME and KDE both provide excellent environments. And I wonder if I should just forget about it and pick a platform.

JavaFX doesn't seem as snappy as native OS GUI frameworks, but I've found it very nice to develop for. It comes with reactive model out of the box, and there are some extra libraries that take it up to 11.

I'm very comfortable with Java, but one of the issues I've had is the size of the resulting binary with the JRE included (it's possible to not include a JRE of course, but it's much easier to have it bundled from a user perspective). You can use jlink to reduce the size of the bundled JRE so that it only includes relevant modules, but does it actually reduce the binary size by a significant amount?

Also, JavaFX doesn't seem to have backing from larger organizations like Electron does. Are there any well-known apps created with JavaFX. I know IntelliJ was created with Java but using Swing if I recall correctly.

I would say that's pretty acceptable for a real app.

https://github.com/wxWidgets/wxWidgets

runs native on the following platforms:

- wxGTK: The recommended port for Linux and other Unix variants, using GTK+ version 2.6 or higher.

- wxMSW: The port for 32-bit and 64-bit Windows variants including Windows XP, Vista, 7, 8 and 10.

- wxOSX/Cocoa: For delivering 32-bit and 64-bit Cocoa-based applications on macOS 10.7 and above.

- wxQt: wxQt is a port of wxWidgets using Qt libraries. It requires Qt 5 or later.

- wxX11: A port for Linux and Unix variants targetting X11 displays using a generic widget set.

- wxMotif: A port for Linux and Unix variants using OpenMotif or Lesstif widget sets.

Bindings are available for C++ and python

Window Layout Using Sizers

Device Contexts (along with pens, brushes and fonts)

Comprehensive Event Handling System

HTML Help Viewer

Sound and Video Playback

Unicode and Internationalization Support

Document/View Architecture

Printing Archiecture

Sockets

Multithreading

File and Directory Manipulation

Online and Context-Sensitive Help

HTML Rendering

Basic Containers

Image Loading, Saving, Drawing and Manipulation

Date-Time Library and Timers

Error Handling

Clipboard and Drag-and-Drop

- Very small executable (I shipped around 10 MB executable)

- No dependencies

- Handling HiDPI screens (4k+) was OK

- Very fast (Opening felt like restoring a minimized application)