Qt ticks all your marks (though the "easy" part is through QML which is a superset of JS), + mobile, (+ one day web maybe https://msorvig.github.io/qt-webassembly-examples/window_ope... though that's fairly experimental).
Also you can't statically link the GPL version which is just a bit of a pain.
I agree if it allowed static linking and wasn't huge it would be perfect. Even so there aren't any better alternatives, but it sucks you can't make something as small and portable as e.g. putty.exe, or depends.exe.
This way, you can get under 20 megabytes: https://youtu.be/mbs3-XE0HNE?t=1180
Sadly I don't think it's possible to have at the same time "portable" (including to platforms without UIs at all, like DirectFB on linux) and small. Putty and depends.exe aren't portable at all.
In case of dynamic linking, it is possible, but not mandatory, to keep application source code proprietary as long as it is “work that uses the library” – typically achieved via dynamic linking of the library. In case of static linking of the library, the application itself may no longer be “work that uses the library” and thus become subject to LGPL. It is recommended to either link dynamically, or provide the application source code to the user under LGPL.
> If you statically link against an LGPL'd library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application
The only thing that matters from the point of view of the LGPL is that your users are able to update the LGPL parts in your app. This is possible with static linking. Else for instance how would LGPL be possible with languages that don't even have a notion of linking (eg script languages), or which only allow static linking ?
See also : https://stackoverflow.com/a/15322678/1495627
I certainly wouldn't base a business on that risky interpretation, and the one business that I have been in that used the LGPL version of Qt dynamically linked it. It's just less risky (plus you don't need to build it yourself then).
The difficulty is that people used to agree (and at varying times, sue each other) over which metaphors to use. The desktop platforms are growing further apart on this front.
Linux has so much work-in-progress happening at any one time that sustainable fusion is closer than a finished and implemented Wayland. Windows is still pushing a "modern" UI metaphor that no-one can stand. Apple has to my knowledge never shown any interest in what you're proposing at all.
That leaves the option of creating another UI layer on top for the app to sit in, and Electron/HTML5 isn't a terrible fit for that.
Maybe trying to get rolling with LLVM and emscripten to run the Electron logic is your answer, or Typescript if it helps ameliorate some of the JS qualms for you.
I think you hit the nail on the head. A UI common library should not provide metaphors but direct access to the renderdable elements, their layout routines, etc. A proper UI library would resemble a modern 3D game engine more by its interface.
The level where UI metaphors step in would be built on top of this basic substrate.
There are oh-so-many projects out there trying to use this pattern but for some reason they've not reached popularity.
We should just go back to Delphi, it was/is one of the best ways of doing GUIs.
Recent discussion: Why I use Object Pascal | https://news.ycombinator.com/item?id=15490345 (2017Oct:268points,233comments)
Delphi forms are in one of two formats.
1) Binary serialization of the form data (this is the older versions, pre 4/5)
2) A textual representation.
The code for a Delphi form was pre-XML, but it looked like a set of standard markup. There were resources (Form, Button, Edit, Label - these types of control) and they were laid out in a hierarchical developer readable form in blocks. The form code was streamed to/from the file (the files were embedded as resources in the Eve, and the form was read and re-constituted at runtime as well as design time.) Borland made a massive deal about the "two way editing" one could do to the forms. The developer was able to cut and paste controls, and the controls were cut/copied as straight text, which could be pasted to notepad (for example) IIRC.
As for the rest, sorry for being so blunt, but it is just not wanting to learn.
We we were writing applications across multiple OS and hardware architectures for ages now.
It is easy, no, as it requires actually putting some effort into a proper architecture and OS/hardware abstractions, but it is surely doable.
It feels like devs now want to write apps without spending any real effort on them.
I think what people are fed up with, is to spend effort learning the "method du jour" of putting a button on a screen and updating the view on a click.
This is pretty much a solved problem, and has been since MVC was invented in the 70s (not saying it's perfect, but it does the job). So there should be an easy an portable way of doing it for decades now.
QT seems to be the kind of framework, but it's C++ so i won't qualify it as "easy".
And in general, I don't think developers are being lazy by going for higher level languages like java, c# or python. Ease of use has a lot of value, particularly if the underlying problem you are trying to solve isn't simple.
The last thing is forward compatibility. If I write an objective-c app, it will only be compatible with apple's platform. Say a new kind of platform appears that takes a significant market share (AR?), there is a lot of value in your app being compatible with this platform without needing even to recompile it, just because the cross platform framework you use will be ported to that platform.
Ergo developers taking the easy route to the expense of user's overall UI/UX.
Thankfully all web based mobile OSes bombed so far.
As consultant and polyglot developer, using C++ and eventually something else for the view isn't a problem at all.
And it doesn't have to be C++, there are other portable native languages to choose from.
Also web developers don't have any issue changing frameworks or languages that compile into JavaScript, almost every month.
Can you clarify specifically what you mean by _It_ there? Maybe (working backwards up the comment chain...) C++, Qt, MVC, "writing apps without spending any real effort", duplicating "applications across multiple OS and hardware architectures" (my vote for most likely), Xamarin.Forms, "easy to use portable desktop application framework", or something else?
http://qmlbook.github.io/en/ch04/index.html
it's really easy
I was experimenting a few weeks back, and was able to put together a Hacker News reader app using only JavaScript and QML.
Granted, it was a fairly simple app; but once I knew what I was doing, the QML/JS combo didn't feel any slower to develop with than the React-based web stack I'm familiar with.
The bajillion constantly changing web frameworks says that people are perfectly delighted to spend the effort to learn the "method du jour" to do those things.
GNUstep could have picked up from where Apple left off in 1998 to be a major contender in cross-platform software development. Indeed; it could have attracted former OpenStep developers who liked the cross-platform nature of the API and were stranded when Apple stopped development of Yellow Box for Windows. But for various reasons GNUstep's development and adoption has been slow, and alternative APIs such as QT and GTK ended up winning out in terms of popularity. But I don't think it's too late to promote GNUstep, especially now when a vocal minority of Mac power users are increasingly becoming discontented with the state of the Mac and are looking for high-quality alternatives.
Original announcement is here, and macOS support was recently added. Language development seems pretty slow, though. http://www.red-lang.org/2016/03/060-red-gui-system.html?m=1
There's always PyQt which works cross platform
100MB/app is in the range of "I am not going to download it" unless I have a damned good reason to. Doubly so for updates...
Calibre (https://ic.tweakimg.net/ext/i/1324631500.jpeg)
Spyder (https://github.com/spyder-ide/spyder)
Orange (https://orange.biolab.si/screenshots/)
QGIS (https://live.osgeo.org/_images/qgis_style.png)
OpenShot (http://www.openshot.org/static/img/gallery/clip-overview.jpg)...
They should have used something like this instead for backend: https://github.com/memononen/nanovg
I'm not even sure which one I'm hoping for at the moment. Xamarin seems to have bet fully on mobile. Avalonia looks nice but feels like it would need some enterprise backing.