Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: How to do cross platform GUI?
207 points by anang 35 days ago | hide | past | favorite | 388 comments
In essentially every discussion about desktop applications there are a lot of comments about how not to build desktop apps, but very little sharing of resources showing how to do it right.

I’ve seen people defend electron, talk about core logic in a cross platform language and native gui code and any number of other options.

As a middle of the road developer I think it’s difficult to find any consensus (besides electron being both simple and hated).

What resources are there for building quality, functional cross platform desktop application?




If you require a UI that is pretty heavy, here is my pro* tip to save time when developing for both Windows and macOS.

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!


> 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)

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.


> Instead you should ask if your users [...] would be sufficiently put off to look for alternatives.

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".


Well here's the thing - developers have a finite amount of time on which they can work on something. Instead of spending that finite amount of time trying to create great software causing the release to be delayed, you could focus on the core functionality, with a slightly subpar user experience, and start delivering value to your users earlier.


I seem to remember a lot of Windows programs back in the day were webviews (backed by IE of course) and it was the most horrible unprofessional looking thing, especially when an Alert would pop up which revealed it was just an IE page.

Webviews are okay on mobile though.


> I seem to remember a lot of Windows programs back in the day were webviews (backed by IE of course)

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.


> Webviews are okay on mobile though.

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.


You can use asterisks to emphasize something, it will turn it into italic. See guidelines.


> Basic things that would work in IE10 are known to break on desktop webviews

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.


I think they just missed the memo that Windows now has a modern Chromium-based Edge option for a web view component. I mean, before that, the situation was really pretty bad, but now I'd expect it to be fine. (Have not tested it yet.)


Actually this is not just a Windows issue, it's also something that impacts Mac OS. There have been instances where the native webview on MacOS had bugs that were not resolved until the next major release of OSX. (Can't seem to find a link, will add one later).

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.


Webapps have been dealing with this for years, it's not anywhere as painful as you are making it seem. Pick a base version to support, use feature detection to add anything new, and you're golden. The existing browser APIs cover 99% of all apps' needs already, and when you're doing this you can always hand-off things to the native layer as needed.

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


It still might be a reasonable tradeoff for me, for some projects but regardless: thank you, that adds some nuance that I didn't get from your earlier comment.


> irrespective of the edition or number of updates installed on the user's computer.

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.


Slack uses electron if I am not wrong.


Don't use Electon. Your users WILL notice and complain about performance.

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?


Electron is a full instance of chromium. Running an electron app is essentially running a browser, which is a heavy application. All that heft translates to inefficiency.


As opposed to a "native webview", which is totally not essentially running a browser.


My impression was that running 10 Electron apps would be like having 10 separate installations of Chromium running at the same time (with no shared memory). But running 10 WebView apps would be like having one browser with 10 tabs open, but where a lot of the the browser resources are shared.

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?


The native webview use another instance of the engine, without running a complete web browser. If all apps did, the amount of resources required would be lower as they would share some common components.


With options like Firefox's SSB, you can use pages like 'apps' but at use the browser's resource pool instead of spinning up multiple Chromium instances.


... but that's not what electron does.

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


It's my understanding that since each app is shipping with its own Electron version/runtime, that the resources of these are not and can't be shared or managed centrally. A chromeless web app running via the browser would effectively be just another tab use the current browser's resources (and extensions +1).


Agreed. Sorry, I took your previous comment as arguing against the comment it was in reply to.

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...


To be fair, I haven't used Electron. At some point, I did try using Essential Object's EO.WebBrowser component for .NET which used similar amounts of RAM. People complained about the RAM usage, not performance.


I think the biggest problems with electron are memory usage, startup time, and possibly disk usage. All of which are because it's running a full browser instance.


I do agree on avoiding electron if possible as users do notice. I've seen folks who perhaps don't know the intricate details of software run into performance issues.

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.


When I see apps going Electron to me they're saying "I care more about making this easily available and focusing on features other than performance" - which is absolutely fine it's a value statement.

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.


A blanket statement about Electron is just bad advice.

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/


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

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/


According to those docs:

> 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.


A preview build vs Internet Explorer/Trident based rendering engine. I'd take my chances.

Or just use Electron


I agree regarding templates, the ones I’ve used all were pretty low quality. Something like this may be more appropriate: https://news.ycombinator.com/item?id=24030581


that's how the start page of Autodesk Civil3D's and InfraWork's are built (steps 2 and 3 only). Screenshot here: https://knowledge.autodesk.com/support/infraworks/learn-expl...

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.


But you'll lose quite a few things offered by Electron, such as notifications, taskbar/menubar, FS access, etc.


Most of the app will still be c++/c#/java/whatever & be able to do these, only the UI will be HTML/css/js via the OS's web view.


It's awful how many apps have to rely on their own separate engines though. Isn't there a way to rely on the new "Edgium" engine, which should be mostly at the same version that Chrome is and kept updated by the OS?


I also do this on my mobile apps given how difficult it's to work with Android layouts.


Can you give us any idea of the kinds of apps you've been doing with this approach? What kind of UI complexity are we talking about here?

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


Can you provide an example of an app that does this? I'm just curious to see how to looks.


You can look at OP's profile.


The stable options for native cross-platform GUI are:

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/


Just to get a feeling, see screenshots of Sciter Notes application on major desktop platforms: https://notes.sciter.com/

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/


Is there any way to get a GPL-compatible version of Sciter?

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


I’m not sure how you’re coming up with the development time estimates but personally I’ve found Qt to be fast to develop in, both Widgets (using designer) and QML. Hell, I mostly do React web UIs nowadays for various reasons, but I find QML a lot easier and faster than web UI’s, especially for layout (vs bootstrap style layouts as well as flexbox and css grid).


What is your estimation of creating something like this: https://notes.sciter.com/ ?

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.


It’s difficult to estimate and I don’t know enough about that applications requirements either, but to give some kind of indication, two years ago I wrote a tool to control an LED (neopixel) strip, or, rather, to create an animation that would be played back on the neopixels. The animation was a json file containing a timeline of events and parameters (think “at time t fade pixels 2 through 10 from rgb x to rgb y over 5 seconds). You could have four parallel timelines that got blended together.

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.


You can add Flutter to this list which is becoming a viable option for desktop UIs. The downside is Dart, but that's not so different from picking Pascal/Delphi just for its UI framework.


I would say the downside is Google, because they may just kill Flutter and/or Dart even if they get popular. I just can't make myself hitch anything important to Google's tech anymore.

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


Flutter is open source though, no?


So is Tensorflow but do you really think volunteers could maintain it?


I am not sure what you mean when you say that the development time on Lazarus is slow.

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


Lazarus allows you to design the UI quickly, but theres a lack of third party libraries when compared to the mainstream programming languages.

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

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

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


Lazarus already comes with tonnes of components (over 200) and lots of libraries but yes, it is still possible that you want to access some functionality which is not provided natively by the built-in components. But then, you may not.


True. Lazarus/Delphi are the "APEX predators" for UI building. Their only caveat is their lack of resources (Lazarus) and weird costly licensing (Delphi).


Yes, the Delphi licensing cost is horrible. However, if you are using Lazarus you don't need to use Delphi at all.

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.


Tk is probably also native since version 8 or so. But somehow the tutorials for Tk usually have ugly examples (not pleasing the eye).


At least on Linux, Tk apps still tend to look like remnants from before Windows 95. (Which personally is the main reason I avoid Tk apps whenever possible, including Tkinter apps.)


There's tkinter.ttk that makes your widgets look slightly more modern.


Do you have to update code to take advantage of native widgets? I use SCID [1] because it's the best FLOSS tool for its purpose, but the interface is still absolutely horrific looking. It doesn't even respect the DPI hints that GTK and QT programs do, so the fonts are too big on my computer.

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


One another viable option may be java with JavaFX.


Does SWT count as stable? Its website looks identical to when I used it (and liked it!) 10+ years ago, so I'd ray probably so :) https://www.eclipse.org/swt/widgets/


WxWidgets worked fine and it was very easy to integrate on small C++ projects when I tried. If you just need some basic windows it's the way to go.

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


I second wxWidgets. It can produce small executables, like 50K, that sport a complete modern UI. Just look for the AUX addition, that the more modern and customizable version.


"Native" GUI toolkits that do not fully implement pen and touch UI are not really native, are they? Do NOT assume your users are on devices that are limited to 20th century UI hardware! (Win10 can fully leverage both pen and touch, iOS does touch well and pen fairly badly...)


Qt (Widgets as well as QML) doesn't use native controls and it is fairly easy to customize (even Widgets, lookup "stylesheet").

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.


I dont know if Lazarus compiles as fast as Delphi, but I'd argue that dev time for Delphi is equal to compile time for Qt app.


You've overstated the comparative advantages of Sciter so much that, upon clicking through, people might flash back to when they found out was a Segway was and shout, "it's a @#$&-+) scooter?!?"


In particular, it's very weird that "doesn't use native widgets" is presented as an advantage, given that apparently the result is that your apps end up looking like this on every platform: https://notes.sciter.com/


You can use native platform widgets with Sciter. If you will find one suitable.

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.


I'd rather disagree about Qt/QML. It is fast.

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.


Perhaps Xamarin as well, not sure if it works on Linux.


It does but by default it uses GTK2. You won’t get the same experience on all platforms with Xamarin Desktop. Each platform has a different rendering engine.


Pascal is still going?


Whatever library you decide to use, you should definitely look at its accessibility.

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.


I agree that developers should try to make accessible software! I don't have those needs myself, but I have to imagine it sucks when you want to use a piece of software but can't because the developers didn't put in the extra time/effort to make is usable for everyone.

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.


> 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.


Then go ahead and make the argument! I'd love to see how you juxtaposition "the right to not be tortured" or "the right to not be enslaved" next to "the right to be able to use Dreebly Chat"...

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.


> I'd love to see how you juxtaposition "the right to not be tortured" or "the right to not be enslaved" next to "the right to be able to use Dreebly Chat"...

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).


There is some pretty consequential conflation of the difference between "public" and "private" above. I don't have to make my house wheelchair accessible because it's my house. And I'm not violating anyone's human rights by foregoing the above (and neither are you).

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.


While I of course do not oppose accessibility or Electron per se I think this is bad advice.

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?


The thing about accessibility is it's only hard if you wait until the end to do it. There's an ongoing conversation in the web development world about this now. if you build your UI out of accessible elements, or better yet semantic HTML elements then your site will be accessible by default. All it takes is keeping this in mind to begin with, because it's no harder to do it accessible than not.

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.


> 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.

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.


Would you really create an open-source chat software for companies?

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.


> Would you really create an open-source chat software for companies?

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.


> 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".


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

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.


As someone with presbyopia, and light myopia that first developed around the time I hit 30, who used to have excellent vision, I promise you that sooner or later you'll regret not thinking about accessibility.

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


Replying to myself to add: the suggestions to "just use the browser or OS controls" are beside the point. It's not only possible but easy to give users more control over the font size and maintain control over the layout and look of the site. Just cranking up size locally doesn't take into account design factors for text and other UI elements. https://www.w3.org/TR/WCAG20-TECHS/G178.html

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


You can change the text size on Hacker News, or any other site, without really affecting everyone else though. Ctrl+Wheel is a common way.

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


> You can change the text size on Hacker News

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


Zooming!=change font size


There are myriad ways to increase the font size of a simple site like HN (browser settings, OS level, etc). Is this really a problem?

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


G178: Providing controls on the Web page that allow users to incrementally change the size of all text on the page up to 200 percent: https://www.w3.org/TR/WCAG20-TECHS/G178.html


Electron is fine on its own, sure. The main gripes I read with it are excessive RAM use because it's basically Chrome, and it piles up the more Electron apps we use day-to-day.

Java on Linux/Mac is fine.


> 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.

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

GTK user tapping head


Please do test out FreePascal and the Lazarus IDE.

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


Just adding another note to my comment above:

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


Double Commander, which is done in Free Pascal/Lazarus, doesn't look or work too integrated on OSX—though I don't know if that's possible by spending more effort. It's using Qt for the looks, as the Cocoa variant works even worse—and that's for some reason inconsistent, compared to other and perhaps simpler Qt apps that aren't made with Pascal.

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


Could you please explain the relationship between FreePascal and Delphi? Is there one besides common ancestry? The page here makes it sound like it's just a class library and not a separate environment: https://wiki.freepascal.org/Delphi

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/


Free Pascal is the language and Lazarus is the IDE. In the case of Delphi, Object Pascal is the language and Delphi is the IDE.

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


Thank you! That makes much more sense.


You are welcome! Please do give it a shot.

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.


Were you a 68k-era Mac dev, by chance? That's my biggest mental association with "Object Pascal". I was only old enough to be a beginner-level user in those days and never got to ('had to'?) program anything on them, but it always seemed like it would be fun to revisit and see that Other Side of my childhood System 7 :)


No, I started with Turbo Pascal in the late 80s and early 90s and then moved onto Delphi, Turbo C etc later. I programmed in Delphi till about version 7/8 when Borland decided to implode by going after "Application Lifecycle Management" etc.


Nothing on the wiki page you linked to is about Free Pascal at all. It's about the history of Delphi.


Aside from being on the FreePascal wiki? :p


Aside from that, yes.

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.


Thanks for mentioning Lazarus IDE. I like it a lot.

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.


Cool! Do you have it available for download?


How does one usually go about finding documentation related to Pascal? Does one need to download a package from https://packages.lazarus-ide.org/ and view its documentation from there?


The Lazarus IDE has built-in help. Apart from that you can get component-specific documentation as well.

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


Is it declarative or imperative? I wouldn't really want to go back to doing GUIs imperatively.


It is via a drag and drop designer.


I tried, and build my own widget (not sure how it was called), and the IDE kept crashing constantly.


The IDE shouldn't crash by itself (it is extremely rare for the IDE to crash, it used to be less stable at the past but that was around 2006-2007 or so).

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.


Thanks. I understand now. I somehow thought the IDE would use at least some sandboxing


I'm not sure if this is possible, AFAIK this is common in any development environment that allows you to work with live instances of your objects - i think even IDEs like Netbeans have the same issue with custom controls.


Was this with a newer versions of Lazarus? It has become far more stable now.


An underused option is to include a local HTTP server in your native app and open it in the user's default browser. This avoids some of the resource consumption and security issues that make Electron bad, but still lets you integrate native code with a web UI.

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


I've worked on some applications like this, and it works pretty well. But be aware that a port on localhost is accessible to any local user - depending on the application you may need to prevent other users accessing it.

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.


Can't this concern be easily alleviated by the backend requiring credentials, and sending them along from the frontend? Getting around this as an attacker means already possessing enough rights to not need sniffing the traffic to the backend. Or is there more required?


It can, but getting the credentials to the browser & storing them there isn't entirely simple. If you launch a browser process to a URL containing a token, an unprivileged local attacker can see it in the command line arguments (at least on some platforms) and copy it. That can be mitigated by launching the browser with a file:// URL which uses an HTML meta redirect to give the browser the token.

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.


Weirdly, Windows makes it easier to do this securely in that you can do NTLM authentication to authenticate local users (maybe MacOS as well, I believe internally it runs its own Kerberos server for the local machine).


AFAIK you can only do this if you disable the local loopback check that prevents windows auth from passing credentials to local host webservers.


Why did they put that in in the first place? To stop cracking of local passwords?


Usually if it's already local, you don't mind localhost connections. If you do, you can negotiate a shared cookie or other auth mechanism. Otherwise, you should at least check the host header to prevent DNS rebinding attacks.


You can capture most keyboard shortcuts in the browser these days, and the native server side can handle registration of global keyboard hooks if your app needs those.


I'm thinking more of the user experience if you take over shortcuts people already use for their browser.


This is how Electron style apps should work, instead of wrapping an entire browser instance around each app to maintain the illusion of it not being at all web based.


No. I want to be able to Ctrl-S and it save the changes I made to the file (for example, but this is the most annoying thing for me) That doesn't work with actual browser.


Yes it does. Just preventDefault() the keyDown event.


And now you start a download and the modified file goes into the User's download folder as file(n).whatever instead of wherever they opened it from.


No, remember that you have a local server running native code. The server can handle writing the file to any path you want.


But if you do that, you also have to handle file opening from the native local server side too (because browser file browser will not tell you actual file path). And of course, that dialog won't be a modal of the browser.

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)


> And of course, that dialog won't be a modal of the browser.

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.


They are called PWAs


PWA refers to the client-side app only. They are not related.


How do you figure? You can locally host or package a PWA same as Electron. Chrome at least is closing the gap in capabilities too.


Is there a good way of doing SSL with this that doesn’t require hacking self signed certs into the users browser? A lot of newer web APIs are requiring SSL.


Most modern browsers should consider http://127.0.0.1/ or http://[::1]/ as trustworthy.

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


In my experience, it's http://localhost that is considered secure, but not http://127.0.0.1. This may have changed since I last checked.


I believe that Chrome treats all localhost connections as secure now. Not sure about other browsers.


You can access those APIs using SSL from the server, which then relays the results to the client.


> security issues that make Electron bad

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


The server binds to the loopback interface, so it's not exposed to the network at all. Then as long as you use CSRF protection and an appropriate Content Security Policy it is safe.


But if you want to interact with local file-system (like open dialog) it start to get complicated.


It all depends on the nature of your application. A video editor and a command line utility are so different!

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...


You’re right, I definitely could have been more specific. Something along the lines of an office app.

Cool recommendations, thanks!


You should definitely try Godot as tlack recommended.


The "best" way to do it is like you said, "core logic in a cross platform language and native gui code". The general path is this:

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.


This was my approach most recently although I swapped out MVVM for a Redux / Elm style shared architecture and wrote platform specific views.


For my cross-platform app, I was originally using Qt for desktop platforms and Android. I was fairly happy with Qt on the desktop, but less so on Android, in part because I was using Qt Widgets - Qt Quick is the newer, preferred way to build GUIs in Qt, at least for mobile. Around 2016 I started looking into an iOS port - at the time, Qt for iOS was fairly immature and there was (is?) some uncertainty about licensing requirements for statically linking Qt on iOS. Having already spent more time than I wanted fighting various problems with Qt on Android, I decided to consider alternatives and ended up creating my own SVG-based GUI library that I now use across desktop and mobile:

https://github.com/styluslabs/ugui


Can a screenreader user use an app written with this library? That’s a major thing Qt and pretty much no other cross-platform UI system get right.


Can u tell us more about this lib or any write up? Seems really cool and a lean approach!!


Clojure is a very pleasant language to develop in. I have found it easier to develop a JavaFX-UI program in Clojure than in Java.

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.


Clojure is a fantastic language, as far as dynamically typed languages go. ClojureScript turned me off to both languages however. I routinely encountered scenarios where accidentally passing values of the wrong type to core standard lib functions produced wildly unexpected behavior that would take hours or even days to debug. Reporting these issues almost always resulted in “don’t do that WONTFIX”, and often very hostile responses if I pressed the issue or even offered to contribute a fix. Ultimately I decided I’d be more productive in a language that embraces correctness as a core feature. And ultimately that led me to take the great FP techniques and philosophy I learnt in clojure and apply them as idiomatically as I could in a statically types language. Now most of my work is in TypeScript, and while I miss a lot of what Clojure has to offer, I would never go back


>I routinely encountered scenarios where accidentally passing values of the wrong type to core standard lib functions produced wildly unexpected behavior that would take hours or even days to debug

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?


> Could you provide a concrete example?

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.


ClojureScript has some oddities compared to Clojure but in my experience acts much nicer than plain JS

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


> ClojureScript has some oddities compared to Clojure but in my experience acts much nicer than plain JS

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.


Recently I've been working with cljfx for developing a JavaFX app with clojure. cljfx does a great job of creating a re-frame like development experience for JavaFX.


Have you considered Qt?

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/


Are there any canonical resources for learning qt with common language bindings? I know pyqt exists, but there’s a lot of info out there and it’s hard to know what’s good and what’s not. I’ve also found that generally any guides are either kitchen sink level or not much more than hello world.

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


I learned from this guide (well the PyQt4 version). It starts off small and works up to the kitchen sink if that's what you need:

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.


Someone else linked a beginner type PyQt tutorial, but just FYI the PyQt API is pretty much exactly the same as the C++ API, down to capitalization. I only use PyQt but still use to the official Qt documentation which is for C++. The only issue can be finding which module a class needs to be imported from in PyQt, which usually can be resolved with Google and then later by looking at old code and copying the few lines of import statements you build up.


PySide2 is the offical Qt Python bindings, and so the Qt website has reference docs and examples for it. PyQt is a separate project by Riverbank Computing.


Beware of there may be Qt licensing issues.


Not really. It's not 1997.

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


PyQt is "GPL but allows you to link from popular open source licenses" what is this supposed to mean?


Ah, I see I'm not quite right there. PyQt _used_ to include a file listing the usual open source licenses (MIT, BSD, Apache, Python and so on) as ok to use with their GPL code base, but they since removed that, because in the meantime it has become clearer that the GPL is already giving people that freedom.

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


Your statement sounds like GPL is giving a "freedom", so like you could use GPL code in an MIT licensed project (sorry if I misinterpreted your statement); this is not true, see https://www.tawesoft.co.uk/kb/article/mit-license-faq "Can I use GPL-licensed code in my MIT-licensed project? No. The project as a whole must conform to the terms of the GPL license and must be distributed under the terms of that license. Therefore such a project as a whole must be distributed as GPL, but can still contain MIT-licensed software."

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


The keyword here is "linking exception". It is a hack to sidestep the licensing problems caused by dynamic linking. e.g. If I encase gcc in java, and release gcc.class under GPL3+, but use it extensively in a separate proprietary java program, does that infringe on the terms of the GPL? Does providing copies of the two together, with a single installer make a difference?

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


Free PyQT does not have the linking exception (which would be lgpl); only the commercial version has.

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


Are there any modern applications / examples built with Qt? This is the screenshot from the Wikipedia article:

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.


Maya, Krita, Octave, OBS, Scribus, Virtualbox, Wireshark. These all have fairly modern Qt GUIs and you can find screenshots around easily enough.

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.


Besides, QtWebEngine allows you to embed chromium into a QT app which means you can effectively get a similar stack as electron but also have the option to use desktop native widgets


Check out Ripcord - https://cancel.fm/ripcord/. It's a third-party Slack & Discord client written in Qt.

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.)


>I just never seem to see common examples with it compared to something written in Electron.

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


I believe many modern car digital dashboards are written in Qt too


Qt embedded is actually pretty nifty. I converted an old GTK "bare metal" interface UI over to Qt once while keeping the "business" logic basically the same other than a couple of tweaks, it went pretty well. The app was pretty well partitioned between backend logic and GUI logic so it wasn't a bad experience at all. All in C++


How did you do licensing? That’s the killer for me on bare-metal.


I wasn't in on that, we had licensing, and I'm sure it was paid for. It was a medical devices company so they had pretty deep pockets.



I'm very happy with the VNote UI, which uses Qt. It's an open source markdown note-taking app. Check out the dark themes.


Chromium is the best UI toolkit ever created. What exactly are the arguments against 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.

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


>Chromium is the best UI toolkit ever created. What exactly are the arguments against Electron?

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.


The old Skype client using Qt was similar to a Slack using a classic GUI framework. Compared to Slack it was barebones. You had a list of conversations and a view for the conversations themselves. I'm not saying it's bad; I'd probably prefer it in fact. But it's not the same product as Slack. This comes back to my point about Electron vs. others, maybe the reason Electron apps are slow is because Electron apps typically have more functionality. The easiest way to make a program faster is to remove code.

> 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.


>Compared to Slack it was barebones. You had a list of conversations and a view for the conversations themselves. I'm not saying it's bad; I'd probably prefer it in fact. But it's not the same product as Slack. This comes back to my point about Electron vs. others, maybe the reason Electron apps are slow is because Electron apps typically have more functionality

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?


"but it's a giant codebase that does things that would be simply impossible in Qt, GTK, Swing and others. "

Like what?


IntelliJ is written in swing. It’s about the most complex piece of desktop software you’re ever going to use.

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.


> it used to have messaging built in at one point

What year?


Dynamic, server-side rendered views

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.


Not sure what the point is on the first two - you wouldn't even need that with a non crap ui framework.

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.


> Not sure what the point is on the first two - you wouldn't even need that with a non crap ui framework.

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.


>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

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.


"A company like Spotify may want to change the UI without updating the installation"

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...


><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

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 used AOL Instant Messenger in the year 1997. Chromium didn't even exist yet, right? You think that HTML and CSS somehow unlocked some magical powers that had never existed before? That's pretty surprising given that DOOM came out in 1993 and did things several orders of magnitude more advanced than Slack's UI.

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?


There's Tk (https://tkdocs.com) with bindings to several languages. The simplest and the original one being TCL. What a great language to program in!

Although I've not yet tried it myself, there's AndroWish (https://www.androwish.org/home/home). Deploy your TCL/Tk code on Android with minimal changes.


I used the Tk ruby bindings several years ago and it was easy and looked decent.


Flutter looks nice, but it's dart.

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.


In all fairness I think Dart is Flutter's strength, not it's weakness. It is a very well thought out language, unlike javascript(in the spirit of discussing electron).

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...


Also I think having a highly integrated toolchain is really important for this. Building something cross-platform with Flutter feels just like a fresh breeze even for web which is a beta target (Desktop being alpha). I would have never gotten the idea to write a web app in Dart, but with Flutter it feels just fine. Like Typescript but from Google.


Speaking of the web, angulardart got a major update a few weeks ago. And on the subject of web-app-on-dart, my personal site is written in dart (and the 'platform', as some people would call it, is open source for that matter if someone wants to use it or contribute).


Yes. The Flutter team makes it clear that desktop support is still in early stages.

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.


I don’t mind dart, but typescript and electron have the full weight of Microsoft behind them while dart and flutter remain mostly hobby projects.

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.


> while dart and flutter remain mostly hobby projects.

What makes you think that?

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


You'd be surprised how many top-downloaded apps are made with flutter. Electron and typescrypt may have some potential but they have a horrible genetic desease - javascript. That alone makes flutter a clear winner.


Can you Name some?


I don't know download rankings, but some I expect get significant traffic include Hamilton, eBay Motors, Google Ads, Grab, Nubank, Dream11, and Alibaba.

https://flutter.dev/showcase


Dart really isn't that bad. I thought I would hate it, especially going from Kotlin.

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.


>In a sane world we would already have webviews on all platforms and the problem mostly solved for client applications

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?


Delphi's FireMonkey framework offers cross platform on Android, iOS, Windows, macOS, and Linux with a single codebase and single UI. It works similar to how Flutter works in that it uses DirectX, OpenGL, OpenGL ES, and Metal API to draw the native like controls. Plus offers access to some native controls (mixed together) On Linux it uses GTK+.

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


Sounds good but... Is this what's needed to use FireMonkey? https://www.embarcadero.com/products/rad-studio

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



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

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++.


Yup. That is what is need it and for any meaningful work you kinda need to buy the priciest version, which is north of $5000.

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


The way I see it: if you had infinite time and money then you would build a native app for each platform you care about, and when you choose e.g. Electron instead you're making a tradeoff because of your available resources.

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.)


> 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.

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.


That's the gist of it. However, I feel the assessment often flies in the face of Parkinson's law. Economics of software development are funny - particularly if software is a part of a bigger company, there's enough inefficiency in both software teams and the greater organization, that Electron vs. 3x native shell + shared core could not be a noticeable difference in terms overall resource expenditure.

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".


> lack of high-quality, mature, cross-platform toolkit using native widgets

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.


> WxWidgets … native

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.


> 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.


Not the person you responded to, but can you explain why if they're using native widgets, every single example application here [1] looks horribly integrated into the desktop? Is wx just really hard to use and every developer screws it up? Does wx use the native widgets correctly but screw up things like padding and highlights? Is the subset of widgets that are supported on every platform too limited, so everyone is forced to use non-native widgets (which apparently always look bad in wx)?

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

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


There are many screenshots here, I'm not sure which one do you mean. But do keep in mind that some of these screenshots (maybe even most of them) are 10, or 20, years old, so what seems non-native to you today might be just the way things used to look.


I really do mean basically every screenshot. But take ECMerge for example. If you switch back and forth between Linux (GTK?) and Win7, you'll see that for example the toolbar is exactly the same color on each. It doesn't integrate with the Windows environment at all. But surely Windows has a native toolbar widget? And possibly even a native icon theme that you could use instead of the GTK icons. And even if not, surely wxWidgets could choose the color of the toolbar based on the desktop theme, and not just fall back to the same default colors?

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.


ECMerge seems to use standard wxToolBar which is definitely a native control, so I don't know why it has the same background on all the screenshots. Perhaps they've explicitly changed it to make them more similar, I really can't say. But if you create a toolbar out of the box, it will look exactly the same as in any other native application. As for the icons, wx does provide a limited set of stock icons, but this will almost never be enough, so you need to either get high quality icons in the style of each platform you support, which is obviously difficult for an open source/free program, or use the same, typically Linux-style, icons everywhere just because this is what is there, for free.

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.


> OTOH all the standard UI elements (buttons, checkboxes, text controls, date pickers, ...) are native

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?


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

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.


Wxmp3gain is from more than 8 years ago, and (it seems) you're basing your judgment on a screenshot, which is not a very solid ground. Using a modern, live, application would be a good test (keeping in mind, that some widgets may not exist in a given O/S).

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.


I mentioned look and feel, and testing out the absence of context menus. This should tell you that I am not judging on a screenshot, but from live applications. I made that screenshot yesterday, and the applications depend on 3.0.4 which is from 2018.

> 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.


It would have been more productive to spend the time to find a technical answer, rather than arguing for the sake of arguing. I did search, and the answer is at the bottom.

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.


I say the opposite: Build with "mediocre-first" cross platforms (all of them are mediocre) is long term the MORE costly option.

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....


That's not the opposite of my point -- you're just rephrasing it.

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.


Thats a fair point, just thinking that most think are in the second scenario (by pressures that also make cut testing, planning, etc) but really are in the first one.

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...


If it wasn’t electron then it’d be some other behemoth FW to fill the void. It’s what we get when computing power is so great. Eventually a bloated, lumbersome, massively layered code base runs functionally OK that it becomes acceptable and universal. As somebody who started writing 6502 assembly and appreciated the elegance (still do), the success of things of bloat like electron is soul crushing.


If I had infinite money I would use something like Xamarin.Native (aka Xamarin.iOS/Xamarin.Android aka Xamarin.Traditional aka Xamarin) to write a 90% shared codebase and develop my own UI dsl with the rest in native code. Codesharing for everything but the UI is a _huge_ maintenance win. The mechanism that Xamarin uses to do its cross platform means that you don't pay much of a performance cost to achieve this, because its mostly just a binding layer to native code (NOTE: not talking about Xamarin.Forms here).


I've been trying to figure this out as well. The simple answer is that there is no consensus and no obviously right solution.

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.


Which one would you pick if you had to?


You should give JavaFX a shot. It's not considered cool here, but does the job well IMO. I have built desktop apps that work seamlessly between MacOS, Windows and Linux using JavaFX with minimal pain. I was already quite familiar with Java and the Java way of doing things though. That probably helps.


For the people having apprehension around Java’s performance, let me tell you that my 12-inch MacBook with a mobile CPU managed to run IntelliJ IDEA just fine (a heavy Java-based IDE) but significantly struggles with Microsoft Teams (Electron-based chat client).


Yeah. Java's default performance isn't bad, and the floor is quite good (lots of space to optimize if needed). Just avoid bloating it up with enterprise framework when you don't need them.

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 recently finished a project in JavaFX and am looking to build another application. I've been unsure of whether to continue using Java or use native widgets.

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 ship a JavaFX app build with jlink. It includes many JDK modules beyond JavaFX, like `javafx.swing` and `jdk.unsupported` in order to access some features that unfortunately are not available in the standard modules, but even then the download size (zipped) is around 35MB, more like 65MB unzipped.

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


wxWidgets

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


I recently (5 months ago) went this way targeting Windows and Linux and was very satisfied in the end. I might add:

- 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)


Every time an application didn't say it was using WxWidgets and I download it by accident, it still goes directly to /dev/null.

WxWidgets is no better than the other non-native GUI toolkits. It just looks, feels and acts like crap all the same. Great for development, bad for everything else.


I see a lot of people suggesting Qt, is there a reason GTK isn't being suggested at all?

I'm in a position where I'd like to develop a better client for Bitwarden that includes autofill to the point of 1Password, and while I did start with GTK (learning for the first time), seeing no one recommend GTK here (compared to multiple people recommending Qt) isn't filling me with confidence


Unless things changed a lot in the last ~three or so years, Non-Linux platforms like Mac and Windows aren't really in the focus of Gtk+. In the past ~five years a large number of cross-plattform Gtk+ applications redeveloped their UIs in "Not-Gtk+" (usually Qt). Wireshark, Subsurface, Openshot and LXDE come to mind, these are all pretty large, UI-centric projects, so replacing the toolkit is a lot of work and wouldn't be something you'd do just for shits and giggles.

If you really, really want your app to use Gtk+ on Linux and be reasonable elsewhere, consider wxWidgets.


> I'm in a position where I'd like to develop a better client for Bitwarden

Beware that, if you use GTK, you exclude a certain segment of the population who need Accessibility and aren't on Linux. This definitely includes screen reader users, but probably also users of voice recognition, switch control etc. QT works much better here. This is yet another tradeoff to make.


The accessibility system in GTK is being redesigned in GTK4: https://blog.gtk.org/2020/02/17/gtk-hackfest-2020-roadmap-an...

The changes should make it similar to the way Qt works and should make it easier to plug in a Windows/Mac a11y backend. If there is interest in implementing/maintaining this then please help out if you're able.


What kind of misinformation are you trying to spread here? GTK+ has accessibility built into the toolkit itself - it's not optional, and it's always on. In fact, GTK+ had it before Qt did - ATK was written back in 2001 to be a part of GTK+, and the screen reader Orca is written to use GTK+ and the platform agnostic AT-SPI layer. It would take a full ten years for Qt to add an implementation here.


The parent post is saying it doesn't plug into the native a11y, which is true. Running the at-spi daemon on windows/mac would work for some things but it is obviously not ideal.


COnsider that a lot of people who are forced to use GTK aren't actually on Linux, and Windows and Mac accessibility is literally nonexistent.


I'm not in the discussion above, but I would never recommend GTK for any cross-platform application because it enforced a Gnome-only look and feel that is completely alien on any other environment (even on Linux).


I found GTK with Python really nice. With a bit of effort you were able to make it look native on all platforms. Clean API, visual Editor, and quite performant. Unfortunately the project suffers a bit from CADT (Google it) and the devs break backwards compatibly all the time. They seem no longer interested in providing compatibility across versions or for platforms other than GNOME unfortunately. With GTK 2, you could write an app with e.g. GTK 2.16 and it would still run with 2.32, but receive all new features from the toolkit. Now you are expected to constantly change your app with every release.


GTK+ 3 was a bit of a nightmare in this regard, but GTK+ 3 is also feature frozen and will be supported for more years to come, so a new application doesn't have as much to worry about here.

The downside would be the desire to port to GTK+ 4 in some amount of time, which might require a large amount of effort depending on the application. On the other hand, if you're starting today you could also start with GTK+ 4...


That's half of my complaint, that the GTK+ devs consider "stable" to mean "frozen". You are supposed to code against the latest completed version (e.g. the final GTK+ 3), which will not receive compatible feature updates, and then if you want to get the new features you have to port your code to the next version.

Whereas under the old model (GTK+ 2.x) it was forwards compatible (if that is the right word) - you code against a stable but actively developed version, and your code will work with no or minimal changes for multiple years, and you will receive the benefits of new versions (historical examples: changes to file open/save dialogs, theming changes, window resize grippers, dragging windows from menubars, ...).


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: