A web app is one of the most cross platform ways to go, is the easiest to deliver, and can be easy-ish to learn, but isn't the easiest. But, you are stuck with JavaScript. If a web app won't work for you, why not? Knowing that will allow people to help you more.
Qt is great, especially if you're using C++ or some other language. It's pleasant and very powerful, but a lot to learn, and deployment to users is harder than a web app.
What are your constraints & requirements?
It is a shame that OP does not want to go HTML/CSS engine, because over the years, I have found that to be the easiest to update, the most reliable across platforms, and (most importantly) the easiest to support for multiple users.
I have tried (and used in production) most of the UI tookits mentioned here.
WxWindows (later WxWidgets), Tk, and FLTK are getting long in the tooth and show it.
Java (SWT, etc), looks wonky across platforms and really do not stand up to the "write once, run anywhere" promise. Also, if you have to do anything even a little out of the lines, count on keeping multiple codebases for different platforms.
Although I had a brief love affair with other VM-type platforms (Adobe Air, Silverlight), mobile mostly pushed support for them out (Air just pivoted to mobile altogether, I believe). They offered single codebase, easy updates, and easy-ish support at a cost of have the user install additional software, but worth the tradeoff in my opinion.
All of the python UI libs are a pain in the ass to distribute, update, and support.
Ultimate++ and Borland Delphi are pretty polished, but you either have to buy into their ecosystems or accept their limitations.
At the end of the day, even though Javascript is a bullshit language for desktop development, HTML/CSS engines (phonegap, Electron, sciter, etc) are just pleasant for maintaining codebase, pushing out updates, doing anything you want with the UI, and support has been a breeze.
Tk is limited, specifically, to being a gui toolkit, and even though the most recent versions look like native widgets, they are limited and the online support (from groups, etc) is limited. All the connecting libraries feel like you are back in the 90's programming again.
WxWidgets is to QT, as Linux is to Mac OS X -- one is cobbled together from amateurs with varying quality of components, and the other is built by professionals and held to professional rigor. The API (and output, in my opinion) is amateurish and dated in comparison. It lacks the polish and ecosystem that the professionally-supported QT has.
If you are making a full-fledged application (as opposed to a user tool or back-end interface) and are hell-bent on using a windowing toolkit (over say an HTML/CSS engine), then QT is currently the only correct answer. There are others around, but they all fall short of QT.
On a side note, Tcl (by the same original author as Tk) is a wildly under-appreciated scripting language.
What can Tk not do, specifically? This thread believes Tk is as good as QT https://news.ycombinator.com/item?id=12380456
http://forum.sqlitestudio.pl/viewtopic.php?f=16&t=334
That post is by the lead developer of a SQLite project competing with the one I'm involved in. The original version was developed in Tcl/Tk, and outgrew it.
Note - I'm not personally familiar with Tck/Tk, I just remembered reading this when you mentioned it. :)
http://www.codenameone.com/blog/comparing-qt-and-codename-on...
It provides API layer which compiles to Win32 API on Windows, Gtk2 on Linux and Carbon/Cocoa on Mac OSX.
Qt only emulates Windows controls, but wxWidgets uses the actual Windows controls via Microsoft Win32 API.
BTW, there's wxQt, a wxWidgets implementation that uses Qt instead of Gtk, but it's still experimental:
https://wiki.wxwidgets.org/WxQt
wxWidgets has been used by some popular projects like Audacity, TortoiseCVS, RapidSVN, FileZilla, BitTorrent, etc.
Another wxWidgets advantage over Qt is the license, which gives you more freedom.
If you're looking for a faster start, take a look at wxFormBuilder which is a graphical WYSIWYG UI editor where you can drop controls in windows/dialogs and hook up event handlers.
You can find links to more related tools/IDEs on the Wikipedia page:
This should not be relevant in any professional technical discussion. Last time I looked there was not an overflowing oversupply of cross platform UI frameworks.
"it didn't ship high DPI support "
This, on the otherhand, might be a critical deficit.
Maybe "wxwidgets has a very antiquated feeling to the API" really means that platform-neutral concepts do not encapsulate well when keeping the UI truly native?
It's still useful to have a single UI library in your code that you can tell to make a text box or open a menu or draw some graphics and have it translate into the correct API calls on each platform under the hood. For all the much-touted rearrangements of UIs, particularly in recent versions of Windows, the reality is that most of the familiar GUI controls haven't really changed that much in decades.
I think the biggest difficulty for any attempt at a cross-platform GUI framework today is probably making sure it does properly handle the widgets or behaviours that really are different or unique on each platform. More generally, if you're building for multiple platforms you also have to deal with all the installation and updating and sandboxing and so on that tends to be completely different from one OS to another, and often the GUI libraries and UI integration is a big part of that too.
This, I think, is one of the bigger but oft-unstated reasons that people actually prefer to target the web rather than targeting native. Javascript's window.alert() is a function with a semantic behaviour-contract; it will alert the user. It doesn't specify how it'll alert the user, that's up to the browser to define. (And, therefore, up to the user to pick the browser whose definition they enjoy.)
Perhaps what I'm really craving, here, is a XAML-like or XUL-like constraint-based declarative view format, which has a very high-level and abstract set of controls available to be specified. Then, different GUIs could have renderer-clients for this system, that rendered those controls in all sorts of different ways. Maybe you could even mix-and-match your favourite concrete controls, like with browser extensions.
> have it translate into the correct API calls on each platform under the hood.
What if instead of writing controls for applications, the applications had low level access to create controls on their own?
For example settings dialogs on Mac are usually not modal and usually apply immediately. Meanwhile Windows dialogs are usually modal and transactional, with Cancel button to roll back and Apply to commit without closing.
Full fidelity inevitability ends up bifurcating the codebase or compromising the nativeness of the UI.
Simple things like button, text box, drop down, check box, radio button that have been in use for 30 years or more are just fine. But look at the list view in Windows; that has grown dozens of options to support Explorer, the file system browser. The deeper you go, the less you can keep common.
I didn't understand why the nativeness of the UI must bifurcate (fork) the codebase. In your example, can't non-modal on Mac vs modal on Windows be a config value in the cross-platform UI?
I also didn't get an answer to one of my questions. Why can't applications have low level access to create controls on their own?
As a simple counter-example, macOS rarely uses Yes/No/OK/Cancel buttons. Instead, dialog buttons have meaningful names based on the task at hand, e.g. "Overwrite File" and "Keep Old File".
With an abstract+declarative toolkit, you would still have to do just as much customization toward your use-case as you would if you were writing one view class for each GUI. You just get to skip the marginal cost of everything that's not that customization. You can have a single code path to create, and show, and receive input from, the instance of the pop-up abstraction.
That latter sentence kinda defeats the argument in your first sentence.
If there's a dearth of options, then there's room for a better API.
A new UI framework is not something you can wish for Christmas. One can implement one (like Blender has done) but other than that, one is limited to the options which are available.
I don't think anyone claims there is no space for new UI libraries. It's not obvious one can simply implement a new one. This is not something someone does for fun over a weekend (at industrial scale) or just to try an epiphany of design over a few months. They are huge, laborious beasts. If one has resources to implement a huge UI framework, then generally, they probably have the resources to implement the UI natively on every platform they wish to deploy on.
"A better API" is kinda moot feature for a UI library since they are technically so demanding, all other factors are more critical.
This is not correct. Many controls use the native implementation of the underlying platform.
Emulating sounds like an extra layer one could do with out.
Add evolution of controls and idioms over time, and it's literally impossible to always unify: not all platforms evolve their non-trivial components in the same direction.
What do you think is the right thing to do? To have a common denominator kind of approach where a control works on all platforms but with fewer features, or to reimplement the control?
Do you have an example handy of a control/idiom that caused this problem?
It sounds like reimplementing (emulation) is a good thing.
I don't think this is actually what you want on Windows. The standard common controls are pretty outdated. Anyone who has built a complex program with a lot of widgets using common controls (or a framework that wraps them) can probably tell you that they're really slow and they have problems with flicker. They also use outdated font rendering (GDI rather than DirectWrite) and they don't natively support alpha-blending. Even Microsoft avoid using common controls. Task dialogs, Aero wizards and most control panels are built with an internal toolkit called DirectUI. Office is built with similar technology, and obviously WPF and Windows Store apps don't use common controls.
This makes Qt pretty much what you want on Windows. It uses the native theming APIs so its controls look native, but they are rendered with a high performance raster engine that supports alpha-transparency and eliminates flicker. Also, I think the latest version of Qt uses DirectWrite for font rendering.
Tk widgets look native on Windows and macOS (if you use the right ones — see [5]), though their behavior is implemented by Tk itself. On Linux it draws its own widgets in several styles; GTK and Qt theme support is immature. Lazarus and wxWidgets use native widgets on Windows and macOS. Both can use GTK2 on Linux but Lazarus also supports GTK1 and Qt.
If I had to deliver a cross-platform desktop GUI application by midnight today, I would go with Tk, write the code in Tcl (which necessarily has the best Tk integration) and package it in a static binary Starpack [6].
[3] http://wxlua.sourceforge.net/
[4] http://www.lazarus-ide.org/, http://wiki.lazarus.freepascal.org/LCL
(1) Maybe there is some option for it somewhere, but if so, having antialiasing disabled by default is weird.
Within its domain, Tk is a very capable tool that easy to use, well-documented, versatile and relatively bug-free.
Future versions are planned to acquire antialiasing and other improvements, no doubt it will be a while before it's available.
Besides antialiasing on a canvas, does antialiasing also work in text in labels, buttons, etc? Can I get in Tk all the fonts I can get in a Mac? Is Helvetica there?
Why can't I find on the web screenshots of Tk apps running on Mac OS X? Is the only way to get Tk to look good on a Mac using Tile http://tktable.sourceforge.net/tile/screenshots/macosx.html ?
From what I'm reading now there might be 4 options: Tk, wxWindows, QT, and a custom "thin layer".
Tile was integrated into Tk with version 8.5 (2007). The Tile button, label, etc. are now built in.
Is there anything Tk can't do?
Also a question on fonts. Does Tk make it possible to use webfonts I see on websites?
But I did not say that. In the reply to the comment you've linked you write that "this thread believes Tk is as good as QT". I am puzzled by this conclusion because I do not see any comparison to Qt at all. Certainly, I didn't want to suggest any with my comments.
If you want to know my option on how Tk compares to Qt, I currently believe that, for the most part, they serve different use cases, with some overlap in the middle. Tk is better than Qt in one area (roughly: small-to-medium applications developed by a lone hacker ASAP) and Qt is better than Tk in another (roughly: medium-to-large applications developed by a team on some sort of a schedule).
Qt does a lot more than Tk. It comes with more features, e.g., networking abstractions. Compared to it, Tk is limited. Qt looks better, too — much better on *nix. I would not recommend Tk over Qt in the general, catch-all, could-become-a-kitchen-sink-application case. (In fact, working well in the general case seems to be a major selling point for Qt.) If you develop one, chances are you will find yourself wanting to do something that Tk can't. In other words, I would expect a large application to outgrow Tk before it outgrows Qt.
I recommended Tk specifically for making a GUI quickly. It is good for prototyping and rapid iteration and has neat widgets like canvas and the text editor that help a lot with that. Tcl with Tk is expressive, so you can do a lot in under 1000 lines of code (toy example: [1]). The Tcl REPL helps more still, as does a great binary deployment story. After the prototype or MVP, once you understand what you want to do better, you may stay with Tk if you decide it suits your needs or switch to something else.
>Is there anything Tk can't do?
That is a very open-ended question. One thing that comes to mind is integrating with the host platform's accessibility features. Most cross-platform GUI toolkits suck at it. There is a wishlist wiki page [2] that might offer some hints at what other things Tk users find missing.
>Does Tk make it possible to use webfonts I see on websites?
Not easily. See [3].
[3] https://www.reddit.com/r/Tcl/comments/456ydh/is_there_a_way_...
Actually, I would argue the opposite. I found it easy to create GUIs using Qt Designer and to use connect() to bind functionality together. (Albeit, this was with Python, it might be harder in C++).
> widgets like canvas and the text editor
Is there something particularly unique in Tk's canvas and text editor?
The poor look on Linux is definitely a big downside. You can ameliorate it somewhat with a custom theme [1] but your GUI will still look out of place in any major desktop environment. TileGTK and TileQt [2] aren't maintained.
I haven't used it myself, but Tk has at least some CJK support [3]. One thing to keep in mind from the start, though, is that Tcl/Tk suffers from a UTF-16 code unit limitation similar to Java's; it only handles the Basic Multilingual Plane [4] natively.
As for antialiasing, what do you mean when you say it is disabled by default? Is that in a particular Linux distribution? A recent Tk release (post-Tcl 8.5) should render antialiased text unless you compile it with "--disable-xft" or your font is raster.
[1] E.g., http://chiselapp.com/user/skoro/repository/tclapps/artifact/....
[2] http://www.tclcommunityassociation.org/wub/proceedings/Proce...
[3] Per https://tcl.wiki/CJK.
Sorry, I was thinking about antialiased drawings (canvas). Text was antialiased if I remember correctly.
IIRC Tk only has linear gradients, no fancy gradients that is needed to make your GUI look good.
* iOS
* Android
* OS X https://github.com/ptmt/react-native-macos
* Windows https://github.com/ReactWindows/react-native-windows
* Ubuntu https://developer.ubuntu.com/en/blog/2016/08/05/introducing-...
Is this correct?
However there's a bit of a UI rendering overhead, although I understand they made it faster with Qt 5.7. And OpenGL integration is more complicated than doing it natively since you have to understand Qt's UI scene graph system and the way Qt is threading things.
But overall it's been a good choice so far.
I used QT before. Please don't be presumptuous.
Electron - Build Cross-Platform Desktop Apps With HTML, JS, CSS
To be fair "just" might be over simplifying things a bit. I've been doing this for an application and thinking that it actually would be a benefit to have a different code bases for the desktop and mobile editions. It can be a bit challenging to design for both targets at once.
Also, now that React Native is extending into the Desktop space more directly (with Linux, Mac, and Windows UWP variants), for React you may not need Electron at all.
- https://crosswalk-project.org/
- https://www.nativescript.org/
- https://facebook.github.io/react-native/
#
Personally I implement the UI in as thin a layer as can be architected and reimplement for every platform. It's the best way, and probably cheaper for most apps than trying to force some lowest common denominator library to express what you want in high fidelity.
I didn't understand this. When you say you implement the UI as a thin layer do you mean you wrap only the few controls you need?
GLib is a utility library; it provides things like container types, filesystem access, networking utilities, threads, object-oriented programming with events and properties, and other similar functions in a platform-independent manner. GTK+ uses GLib. You can use GLib on its own as well. It won't solve the problem of GTK+ being clunky on Windows, though.
I thought that was GLib, and GTK+ was using GLib to implement controls.
Which library does one need to build their own controls?
It seems this could pair nicely with .NET Core and appeal to C# developers who may prefer to transition to a cross-platform UI library instead of UWP.
- The UI to look as good or better than the UI on Mac OS X. I'm not willing to compromise on looks.
- The library to be cross-platform. I want to deploy the software on Mac OS X, Windows, and Linux. I don't care about mobile right now.
- I want it to be possible and easy to (a) develop new features on my own and (b) change existing features. I'd rather reimplement a textbox from scratch if it's the only way to change a control. If this means I need something more like GLib instead of GTK+, so be it.
- I won't use the web. No HTML, no CSS, no Javascript. Sorry.
The end goal is to build the best, easiest UI environment to write software with. If it's not possible to build this with existing UIs and I have to write one from scratch, so be it.
If you don't want to deal with Windows, you can cross-compile for Windows from Linux using the mingw-* packages (eg https://fedoraproject.org/wiki/MinGW or the Debian or SUSE equivalents).
[1] http://mxe.cc/
For example, we (sqlitebrowser.org) compile our window nightly releases from Linux, using MXE. But, SQLCipher (an encryption library) doesn't build with MXE. So the nightlies don't support encryption.
Meanwhile, we've figured out how to do full Windows dev setup and builds. eg:
https://github.com/sqlitebrowser/sqlitebrowser/wiki/Setting-up-a-Win64-development-environment-for-DB4S
Guess we just outgrew MXE?
Just remember that the UI kit is only part of having a good UI. Apple's historical success with good UI is based on their long standing guidelines for designing good UIs.
I doubt I need to tell you this (although Google seems to recently have forgotten it), you app needs to use the patterns of the platform it is on. Users respond well when the app looks like it is "native" and not a port.
Not that I agree with it, but I am fairly certain Google has not forgotten - they have just remapped the definition of "platform" from "the operating system" to "Google's app constellation & sites". The pattern commonality is no longer with other apps on the OS you are currently on, but with other Google property.
- Do you need adjustable styling? Like today it is a flat UI and tomorrow they will return back to skeumorphism. Material design for example is step in that direction. What about UI branding, when the same UI is used for different brands with their own color schemes, etc? What is expectation for the lifetime of your application? Just for the note: http://sciter.com/from-skeuomorph-to-flat-ui-evolution-of-on...
- What about UI accessibility? "Section 508" and the like.
- So called "richtext" WYSIWYG editing - yes/no?
- Printing and print preview?
- Dynamic UI composition? When UI is composed from actual data structure. In some cases simple flat property lists may work but not always.
- UI animations and transitions ?
- What about UI internationalization?
As of "No HTML, no CSS"...
HTML is just a serialization form of tree of UI elements. Not more not less. Any library has this (serialization) in one form or another.
CSS is simply the way to define things like: "this element in that state has to be rendered te following way". Any good library has that in one form or another.
You do not need full scale browser for HTML/CSS, and actually should not use solutions based on browsers for the UI. Primary goal of a browser is to provide safe browsing experience, UI rendering is only next function after the first...
QT is what I've used when a client is determined to go down this path, but if a web app doesn't make sense the best option is almost always to spend extra time making sure that most of your code is portable and then write a native UI that uses it for each platform that you care about.
I'm not disputing this but I've yet to see a clear explanation why it's harder to get right than it seems.
I want to understand, precisely, what makes this hard.
low level differences:
There are differences between GDI and xlib. For instance GDI has a concept of a "combo box" at the API level and in X11 you need to either roll your own or use a higher level GUI toolkit. IIRC, Handling of the non-client area and window scrolling are different between platforms and handling of audio/video is completely different between platforms.
There are a LOT of features:
Power modes (e.g. suspend, hibernate, low battery), tooltips, the clipboard, drag and drop, maximize, and a bunch of subtly different "must have" features need to work between platforms and you need to know what all those features are. Accessibility should work and touch/gesture support is likely to become important over the next few years. At the point where you start cutting features to make it more manageable you have started down the road of making another crappy "lowest common denominator" GUI toolkit and you are better off just using QT.
User expectations are different between platforms:
This is mostly a lot of little details, like where the "close" button goes, what a "right click" does, menu layouts, standard icons, and which direction the window scrolls when you move the mouse wheel "up" but it adds up to an application not feeling right. You can see this taken to an extreme with any number of bad ports from console to PC.
One of the reasons is different UI paradigms and choices.
What is a Lazarus? From their website:
"...a cross-platform IDE for Rapid Application Development. It has variety of components ready for use and a graphical form designer to easily create complex graphical user interfaces."
Why use Lazarus and Free Pascal? You can create native, cross-platform UI's all combined into a single, fast, low-memory executable that can easily be deployed and distributed on different platforms.
We have a cross-platform library for business logic, and native Windows and Mac UIs.
The problem is that cross-platform UI libraries don't really let you fine-tune the UI. They're great for very rapid development with a basic, functional, UI.
If you get an "artiste" in product management, or you need to plug into Windows-specific and Mac-specific functionalities, you will need to use platform-specific UI libraries and keep your business logic platform-neutral.
I want to be able to fine-tune the UI.
http://cranksoftware.com/storyboard-suite
Also someone else mentioned Phonegap and using HTML/JS. I think is a good option but it depends on what your app does and if you're doing mobile app design.
I have not used QT yet, but after doing some research, it's kind of a pick your poison type of choice, IMO.
IUP is wrapper for gtk+, motif and win32.
Pros:
* really simple api
* native toolkit
* c api, so other languages can easily write binding for it
Cons:
* controlls(widgets) are limited
* cocoa(mac) is not supported {they suggest to use gtk instead}
* documentation is spotty
* nobody is using? (I believe no linux distros have it in repository)
somebody here menthioned libui[1], it is exactlly the same philosophy
[0]http://webserver2.tecgraf.puc-rio.br/iup/ [1]https://github.com/andlabs/libui
If you want a native one, probably Qt is the winner here.
[1]: https://fman.io
One complaint people have about Qt is that it doesn't "look native" enough. That's not something I personally care about, and it's not a problem at all for the applications I write, but it's an issue for some people. IME, that's just a trade off of using a cross-platform GUI library. If the layout is good and it's easy to use, most people won't care if it doesn't look native. Photoshop doesn't "look native" either, yet it has a huge following and brings in a ton of money.
Not sure how it compares as a "library" or "framework" etc. I'm still figuring out where the lines are drawn.
http://docs.nativescript.org Emulator Here: https://docs.genymotion.com
It's python based, and really easy to get going. It does have it's quirks, but overall I found it a joy to use.
Electron or QT for cross-desktop apps, Angular & Ion framework for cross-mobile apps, React & React-native for cross-mobile apps
Next... what is the application? Do you need to target native APIs? Do you have memory limitations?
If you don't mind taking up a lot of memory try one of the "cross platform" systems like Xamarin or some Java-based solution. If you need to be more constrained try writing to the native APIs and porting your project to each target platform you need to target. Lastly if you're highly constrained maybe you need to try an immediate-mode style library like Nuklear[0].
It really depends on your needs. There's no one-size-fits-all.
Why?
If a language run-time or virtual machine promises, "you can write code once and run it anywhere," then they're not telling you the whole story. There's no such thing as, "cross platform." It's just a vague term that is commonly interpreted as, "major OS platforms," or, "most popular mobile platforms," etc.
Requirements are both technical and non-technical. If we just focus on the technical requirements you have to look at the data you're working with, your user, and how the program interacts in this system between the human and the rest of the world. If you're writing safety-critical mobile applications for remote workers that spend a week or more in the field you're probably not going to waste your resources on a memory-hungry VM just so that life is more convenient for you. That's starkly different to prototyping an application in a lab where convenience is paramount compared to cheap resources. I have yet to see any kind of language or run-time that lets you have it both ways.
One may say, "Yes agentultra, but what about generating the code for the highly-constrained environment from the higher-level language?" I love this approach. It's possible to generate efficient code this way. This approach still requires you to understand your target platform well enough to spot bugs in the generated code. So while it may be an approach to gain some leverage as a single developer or small team; you're still quite constrained but this DSL... the same code written for the DSL is not likely going to run well or even be considered for use by your other target platforms.
I haven't yet found a way to "escape" the reality that different combinations of hardware and OSs require different solutions for different applications. It may seem like "all you need is Java" or X, Y, or Z -- but the reality is more nuanced than that.
If there were such a language I wouldn't be asking this question on HN. I have yet to see a clear answer why there is no such kind of language or run-time.
> the same code written for the DSL is not likely going to run well or even be considered for use by your other target platforms.
Why? Can be you more specific with an example?
... I'm having trouble not being glib in my response. I want to say, because computers. But let's be a little hand-wavey for a moment.
As programmers we sometimes put too much faith in our poorly-thought-out abstractions. We think, "why is there not a library/runtime/VM that abstracts away all of these painful, tedious details? Surely someone must've invented a GUI library that runs on all platforms, perfectly." We look for ways to avoid the difficulty of thinking too hard about it. We just want to write an application and not think about operating systems, hardware architectures, memory allocation, etc, etc.
Well there are systems that do remove some of the effort in writing such applications. They will manage memory for you, abstract away the differences in various operating systems, and they might even provide a common library for writing a GUI that works across all of the platforms that the VM/runtime supports... this is a great tool to have.
However it has a cost. It has it's own memory model. It makes assumptions about what GUI interfaces are. It targets the common denominator between operating systems. It is, by necessity, quite complex on the inside... so as long as you can sit comfortably in the box and write programs that the system expects you to write you can safely ignore the hairy details of allocating memory, making system calls, managing resources, etc.
But if your application requirements pull you out of that comfort zone be prepared to have to deal with garbage collection algorithms and mapping your application's data to the runtime's model. That has a cost.
For some applications that cost isn't worth it or even feasible. How much battery power are you willing to consume? How many updates to the simulation can you make per second? How fast do you have to stream that data of the disk to this other component?
These languages and runtimes that claim to be "cross platform" are really just selling you a subset of functionality on a subset of platforms that you may or may not care about. It's never what you intuitively assume it to mean, "write once, run everywhere."
> Why? Can be you more specific with an example?
I wrote a 6502 assembler in Common Lisp many moons ago. With it I was able to write applications for that processor in a high-level language with all of the Common Lisp tools I was used to. However that DSL was restricted to that platform backend.
Had I a requirement to target another platform, say x86_64, I would have to write another backend for my high-level DSL and introduce plumbing to my build tools to produce the executable code for either platform. Great! Cross platform code!
Well... not really. I still had to write two different backends. And I can't really exploit the unique features of either. I can only really make use of the common denominator between both or else emulate features of one in the other at the expense of making one platform less performant/useful than another.
There's no such thing as "cross platform." It's just a marketing buzz-word. There are hardware platforms. There are operating systems. These are the things we program.
Abstractions are great but they're not free and they don't free you from thinking. It's an easy mistake to make because it comes so naturally to us humans -- we hate doing things that are difficult. But there's nothing natural about programming. It's hard.
But if you want something to run everywhere including web browsers, JavaScript is the only realistic option. So we make do. My current approach is to rely on HTML/CSS and React/React Native for the easy stuff and everything else is rendered in the Canvas tag with lots of JavaScript to bend the platforms into doing what you want.
In the past I have taken similar approaches by using things like Ejecta but the android support for this is lacking and now that WKWebView has addressed many of its issues, using standard WebViews within native containers is fast enough on mobile.
On desktop, Electron, NW or the other things like this can fulfill the same setup.
People will complain about performance which was a really big issues a few years ago but today the difference isn't large enough that it can't be worked around and most of the fear is in people heads. Most environments have web workers, and webgl, and JavaScript that has a JIT, and many new things like Web Assembly and SIMD should be available in the coming years making these platforms even more viable.
I think the question needs to be a lot more specific about the type of app and the platforms it needs to run on. Web-based applications give you the broadest reach for the lowest cost if you can assume internet connectivity and if the GUI that's possible from within the browser sandbox is sufficient for your needs. (Capabilities are growing all the time, but it's still not the same as native.) If your app needs to be offline, it's still possible with web tech but it's harder to justify, unless you're doing a hybrid of online and offline and the online part isn't just service calls.
Saying that from wrongly choosing it over Qt for a cross platform screenrecording/annotation project a few years ago.
There's literally no way in hell to recommend GTK for any new desktop project that likely has a Windows audience. GTK is a mess. :(
It sounds like GTK is eliminated too.
What's left now, QT and wxWidgets?
If you have skill in C++ already, then Qt is a natural fit there. Also, Qt's docs are very good. None of the "oh, I was advised to use this class. Where are the docs? What do you mean... go read the source code?".
Gah... sorry... still haven't gotten my extremely bad experiences with Gtk out of my system (years later). ;)
If I were doing a desktop GUI type app again, I'd choose Qt for sure. Good docs, very large user base, actively helpful Community on IRC. (I'm not really a forums guy). Plus, bunches of Qt code (of various quality) on GitHub for getting ideas from.
Hope that's useful. :)
I want to know the difference between the thin layer and the existing libraries. Not in vague terms but specifically with a code example.
But then again, it's not something I've personally tried (nor needed), so that might be an inaccurate assessment.
If you don't need a full/complete GUI stack (and other related bits) implementation for your application, then yeah, it might be the way to go.
Xojo used to be called REALbasic, and it's a cross-platform 'Visual Basic' with support for Windows, Mac, Linux, iOS and Raspberry Pi. I tend to use it for internal tools that need to run on both Windows & Mac, and find it's great for getting to a prototype stage very quickly.
What I want is closer to writing my own Xojo.
Used it for the TrueCraft launcher: https://github.com/SirCmpwn/TrueCraft/tree/master/TrueCraft....
In the past we used GTK and wxwidgets with OpenGL but we did not like it.
We started using Qt, much better(proper object oriented by design, and cleaner design than wxwidgets) and web apps. Now we use native libs with our own multiplattform lib with bindings for each plattform:
-javascript for the web.
-native cocoa and windows libs, with openGL, metal and directX.
-Qt for linux with OpenGL.
- Native mac(iOS and cocoa) and windows.
The https://github.com/go-gl github org has repos with comprehensive pre-generated OpenGL linking. When building off these, you need almost zero interaction with any host libraries. Cross compiling is a breeze. I made a demo application on Linux one afternoon to try it out: I was able to hand the code to a friend with a Mac, and he compiled and ran it first try. It's hard to understate the level of "wow" there.
Golang+GL also ships to mobile devices. There's a little squeeze dealing with the app stores, but fundamentally, build on GLES2 and you can go anywhere.
https://github.com/google/gxui/ is one library on top of these foundations that went all the way to providing (beautiful!) cross-platform widgets that can be used to quickly build a desktop application.
Unfortunately, gxui, though a very attractive proof of concept, is now unmaintained. (At the same time, it's worth mentioning that it still works; there's no insane deprecation schedule or fast-moving/fast-breaking libraries to wreck your day here.) If anyone Out There is interested in renewing this project or starting more frameworks like this, I'd love to collaborate.
Overall, there's work to do here, but if you have some appetite for cutting edge, the foundation is in place to nail portability properly.
Finally, this is unrelated, but I feel compelled to give an anti-pitch to pretty much everything in C/C++ ecosystem of GUI tools: it's a landscape of last decade's promises, and today's despair. I've had comrades complain bitterly over time they've spent in codebases where the wxwidget string objects got out of hand. I have a half dozen applications suffering from various C++ linker hells on my various computers and can't recommend QT with a straight face. I still haven't gotten all my gtk3 and gtk2 configs to line up on my last debian reinstall and all the font sizes are fragged on the computer for no known reason (I literally the gtk configs in my dotfiles in git; I can't imagine how different machines drift)... And I haven't even said a word about build and shipping infrastructure required to really tackle cross-platform. I'll say it again: the entire C/C++ ecosystem of GUI tools is a landscape of despair.
Embeddable HTML/CSS UI engine designed specifically for desktop UIs.
The "Embeddable" here means that: - it is a compact (3...4mb) monolithic DLL/dylib/so without external dependencies. - can be linked statically if needed. - has simple plain C API of 20-30 functions - C++,C#,Rust,Go,Delphi,Python wrappers.
Same UI resources are used on all platforms: http://sciter.com/images/sciter-clock.png
Check technology introduction article:
http://www.codeproject.com/Articles/859098/Sciter-multiplatf...
If your app will do a lot with the hardware (sound, video, networking,...), then you should look at native libraries for cross-platform hardware access and UI (though HTML/JS/CSS based UIs with native core are also possible).
In my experience, making a good "cross-platform" UI can be tricky, especially if your platforms include both desktop and mobile.
The reason is that each platform has it's own set of features, limitations and design requirements, which you either have to emulate, ignore or implement as platform-specific modules.
Most UI libraries implement their own windowing systems which makes it possible to have an app that behaves similarly on all platforms.
The drawback is that the app looks and feels 'cooked' - things aren't quite standard, animations are a bit off, fonts are rendered differently, etc.
One such example is Qt, which has been mentioned many times here. It is probably the best choice if pixel perfection and native look/feel isn't your primary requirement. With a bit of work you could probably achieve native 'perfection' with it too.
If you work with sound, then you should take a good look at JUCE - it has a very pleasant API, has a low overhead and a very friendly community.
That being said, the best choice IMHO is to develop native UIs for each platform or at least for the mobile versions of your app.
The trick is to separate your design into "core" and "ui" parts. The core is a cross platform C++ library, which implements all the business logic and low level hardware access, exposing an API to the UI layer.
The UI is then implemented in Qt/JUCE for the desktop apps, Objective-C++ and Swift for iOS (and OSX if you want) and Java+JNI on Android.
The advantage of this method is that it forces you to have clear separation of concerns between the core business and UI layers and you can have different people working on the core and the specific platform UIs.
The ultimate advantage is of course your user's experience - native apps are more gratifying.
It might sound like a lot more work, but it's usually not as bad as it sounds - if you have a well designed core API, the UI is just a visual representation of your application state, which is not that difficult to implement on each platform.
In the end, personal preference and tastes also matter - use whatever makes you (and your team) feel more comfortable. Good luck !
By itself you can already have tons and tons of great UI components that work cross platform.
But if you want a web based library specifically designed to present a common interface tailored to each device (desktop, tablet and mobile) and taking advantage of its unique characteristics, use our open source one:
You can use javafx or swing, although javafx needs certain combination of warbler and jruby to work.
So it ends up being custom logic for interaction on each platform, but the design/assets can be shared cross-platform.
I started off with an Angular 1 app using Dropwizard for the backend. But I was frustrated with (1) the incidental complexity needed to use a decent tree view widget with sorting, filtering, pagination, etc. and (2) the slow response time of having to go from the web page, to the backend server, to the database and then back again.
Around that time, I ran across a Java Swing app written by another group and was surprised about how fast it was to start up and to access and display info from a database. Since it used Swing though, the fonts under Red Hat 6 were terrible. Since I already had most of the "business logic" in Java, it was straightforward to quickly prototype a viewer using the SWT/JFace tree viewer. It was fast to start up, and the fonts looked decent since it was using native GTK2. I dropped the Angular stuff and coded the program in SWT and it has been well received by my coworkers.
I'm a big believer in using native widgets to the extent possible, which SWT does. For the tree view widget, for example, it uses GTKTreeView for Linux and NSOutlineView for macOS. For Win32, there is not a native tree view widget with columns; SWT uses the native Tree widget and draws the columns itself. Qt on the other hand emulates a treeview widget on macOS for example and does not use NSOutlineView.
There is occasionally a least-common-denominator issue when using SWT. For example, I wanted to use tab widgets that have close buttons on the tab like web browsers do. The native Win32 and Cocoa tab controls do not provide for close buttons, so I had to use an SWT provided tab widget that is not native at all. Doesn't look great, especially on the Mac, but it's fine.
The SWT API is dated, as it comes from the early 2000's, but it seems straightforward and I rarely find myself surprised. Getting the GridLayout to do what I wanted was probably the trickiest part. There are examples to follow on the web. It does not have the kitchen sink aspect that Qt and WxWidgets have, since Java is there to provide the networking and database access, etc. Java 8 cleans up a lot of the issues with having to use anonymous inner classes everywhere in favor of lambdas, and if Java is not your cup of coffee then SWT is usable from other JVM languages.
Deploying the program works ok. For macOS and Windows, I package it up with its own JRE. I do face the issue of the best way for end users to update the program easily. I haven't found an easy to use update package like Sparkle on macOS that works for cross desktop platform Java apps. I'm contemplating turning my program in to a full Eclipse RCP program to take advantage of that framework's built in update facility, but the learning curve seems daunting. And I'm a big fan of Intellij IDEA for Java development, and don't want to use Eclipse. :-)
In a way, Java is a victim of its own success.
I want it to look great, especially on the Mac.
No SWT.
Its one downside is if you need really low level hardware interaction with OS you have to use an ANE library which are sometimes great, and sometimes sketchy.
QT refers to Apple's Quick Time.
Qt refers to the Qt project, pronounced 'cute'.
Atom for example is built with Electron.
> - I won't use the web. No HTML, no CSS, no Javascript. Sorry.
If you're using HTML, you're already limited in known ways. Conflaguration of logic with presentation and callback hells and limitations of CSS extensions by platform. Then the there's the need to split HTML views due to technical limitations and practicality of maintenance adding a whole new layer of complexity in view and view fragment management!
In many cases I'd say that's not an issue, and JUCE is underrated/underused as a general-purpose UI toolkit.
Please explain!
It also encourages you to adopt a coding style that's consistent with the rest of JUCE, particularly in terms of memory management. This is one of the things that makes it a lot more "framework" than "library", and again might not be for everyone. Take a look at the "Object lifetime and ownership" section in this page:
And even in an absolute sense, you can't confidently say that dual-licensing limits popularity in the long term. If JUCE and Qt were free for everyone, perhaps they wouldn't be able to have the full-time developers they both currently have. So maybe they wouldn't be as good, thereby decreasing popularity against competing dual-licensed libraries. This is all wild speculation, of course, but it's an example to show how their model works.
(well last beta release of gtk3 binding was released 2014-06-04, but lot of APIs are missing and buggy)
(Xamarin said that they would not going to port xamarin studio to gtk3)
since gtk2 doesn't support hi-dpi scaling, I would not recommend it.
Only option for commercial software currently is LGPLv3 and it's doesn't allow tivoization.
[1] https://subsurface-divelog.org/2016/02/subsurface-mobile-for...