This post analyses some good cross-platform software:

http://blog.johnnovak.net/2016/05...form-gui-trainwreck-2016-edition/

His conclusion is to write apps like HMH if you need the highest level of quality.
(Do you guys have any experience with Qt BTW? I'd like to use it in mobile coding...)

pragmatic_hero

But hasn't that already happened though?

By far, most "serious" cross-platform desktop apps do not have native look and feel.
Almost all content creation tools certainly don't.
Unity, Blender, IntelliJ IDEs, Kontakt5, flstudio, 3dsmax, maya, etc, etc

I would argue that these are very special use case applications for which using special UI is OK.
By regular desktop apps I mean application with some buttons, text entry, maybe db connection or something similar. For those you want consistent behavior. Editing 3d content or writing code is really and edge case.
And if writing custom UI is acceptable for these cases, then no library or framework will help much. There's no point of looking into cross-platform libraries. These apps will use custom solutions for that - good examples is Unity and Blender (I have no experience from others in your list).

mmozeiko

pragmatic_hero

But hasn't that already happened though?

By far, most "serious" cross-platform desktop apps do not have native look and feel.
Almost all content creation tools certainly don't.
Unity, Blender, IntelliJ IDEs, Kontakt5, flstudio, 3dsmax, maya, etc, etc

I would argue that these are very special use case applications for which using special UI is OK.
By regular desktop apps I mean application with some buttons, text entry, maybe db connection or something similar. For those you want consistent behavior.

Yes, and those regular desktop apps(LOBs and CRUDy apps) are exactly the type of desktop apps which are being replaced by the web stuff.
And the web-stuff is anything but consistent (apart from editing text-fields i guess?)

In some way, these days one could argue that anything but the web-browser is a special use case application - and they increasingly use non-native solutions mostly as that is the safest way to deliver a high-quality, consistent experience across platforms.

Just to be clear, it is pretty straightforward to make an imgui that doesn't render at 60fps.

1. Only call the top-level gui call after receiving input
2. If a GUI widget has a one-frame latency issue, have the widget set a flag that means 'draw one more frame', and then add that exception to #1
3. If the app spontaneously changes state (network input, timer, whatever), the GUI needs to be re-run once
4. If you have animation (like a flashing cursor), have each widget post when it next needs to be drawn (actually update a global variable to compute min of 'float seconds until next animation'), set a timer with that duration, and re-run the GUI when the timer fires

I've never done #3 or #4, but I did once make an IMGUI that did #1 and #2. The old framework I have allows the main loop to return a flag indicating whether it's 'animating or not', the former means 'render at 60hz' and the latter means 'wait for input', and so for #2 it would report for one frame it needed to animate, then switched back to waiting for input.

You do still pay the cost of retraversing/rerendering the whole scene even if you're just updating a cursor, so you will still be wasting power on a mobile device, but you shouldn't take up an entire hyperthread blinking a cursor if you do this.

Nice thread you have going here! I saw Abner share it on Twitter and I got really excited because is one of this topics that drives me crazy. I truly believe that if all the efforts put in JS (or the JVM, or GCs) would have been put somewhere else the (tech) world would be a better place.

I come from iOS development and there the effort to built cross-platform apps has ended up with React Native being the clear winer. I truly believe that it has really good things, good things that any cross-plattform framework should have, obviously I'm biased to "app UI framworks".

- React style layout and rendering. This is probably the biggest thing that has happened in UI app development lately. The way I see it is a structured imgui API with the advantages of retain UI (which is basically what any platform provides). React serves as a layer on top of the native gui frameworks, which brings me to my second point...
- It has to leverage the native frameworks (specially on mobile). There is no need to reinvent all the UI in all the platforms, and maybe redoing it would bring more benefits, but looking and feeling native to the platform is really important so it's much better to use what is already there. Even electron Apps try to do this with the menu bars, etc.

This two points are really important, then it only need to be done with a proper language (call it C, ++, Swift, jai... whatever). It is a bunch of work but I think that wrapping what is already there has more future than reinventing everything. And the selling point of all this frameworks is when they say "uses truly native components".

Also this style of UI (as with imgui) brings to the table something that is super common in JS (and why people loves it so much) live/hot reloading without having to wait for recompiling.

Good points alex. I'm also finally learning React Native for a new job I have to deliver on Android and iOS.

I agree that conceptually its like imgui, but its not simple and predictable - its a lot of code to make it happen in the browser.

One could also argue that a "handmade" style on the browser would be to manipulate the DOM with JS ie the DOM is Casey's bitmap..

hugo

One could also argue that a "handmade" style on the browser would be to manipulate the DOM with JS ie the DOM is Casey's bitmap..

Even further would be to build your whole UI inside a HTML5 canvas. You would gain a victory over relying on how the browser decides to play with your DOM, and you wouldn't need to stab in the dark with CSS. But you would also suffer a defeat with accessibility (no screen reader could read your site) and search engines (your site would be a non-semantic mess in the eyes of a crawler).

React has a lot of appeal in the way it allows mixing logic into layouts, but the cost is pretty heavy performance-wise, as usual with any web library these days. Also, the mantra of always storing the state in the component makes for a lot of messy code that needs strict structures like flux/redux to keep it sane, but that in turn bloats the code and every time you need to make a change, you need to modify multiple files. In my experience the complexity in a React project can get out of hands pretty soon; even in my current project which I'm programming alone, it's started to get hard to navigate already with a pretty tiny (~15k LOC) codebase.

hugo
One could also argue that a "handmade" style on the browser would be to manipulate the DOM with JS ie the DOM is Casey's bitmap..

That's definitely the way to go on the web. Unfortunately, it still doesn't make a webapp desktop-worthy.

I worked briefly at a company (my only real programming job) that used Qt and even QML for the software on their high end embedded mashines. The result were awefull. It took forever to boot, and the interface was sooo slow, the binary was huge, and the compile time was hours. And the program wasn't even big. QML is kind of like JavaScript, and is definetly worse then Qt, but I would never use any of them for anything.

I feel that SDL gives me all I need for cross platform development, and am using it happily to develop Glyphin. But I realy dont see the reason to make anyting feel "native".

An issue that is easy to forget is accessibility: allowing blind or poor-of-sight users to make use of your application.

In that regard writing your own custom UI is risky, because this issue is easy to forget. You otherwise have to implement the platform-specific APIs for UI enumeration. One example is Microsoft's UIAutomation: https://msdn.microsoft.com/en-US/library/ms726294(vs.85).aspx

Has anyone given some thought about that?

At this point this is one big advantage of using either native controls or HTML.

Another advantage of Qt, it supports accessibility across multiple platforms.