15 ms·

Ask HN: What's the best library for making cross-platform UIs?

223 points by rer 10y ago

evolighting 10y ago
QT！
- muminoff 10y ago
  Not QT, it is Qt.
  - emilsedgh 10y ago
    No idea why you're being downvoted. QT refers to Apple's Quick Time. Qt refers to the Qt project, pronounced 'cute'.
tariqrauf 10y ago
Depends on what you're after :) Electron or QT for cross-desktop apps, Angular & Ion framework for cross-mobile apps, React & React-native for cross-mobile apps
- api 10y ago
  There are efforts to bring React Native to desktop but I don't think they are production ready yet.
  - tariqrauf 10y ago
    you can get react on desktop with electron
shireboy 10y ago
Not a library per se, but HTML+CSS+JS. Bootstrap or some other mobile responsive framework. Works on just about every device&OS. Phone gap or similar if you really need native.
- DougWebb 10y ago
  +1, because I had the urge to say the same thing. 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.
tyfon 10y ago
I have tried many but always turn back to qt. It has bindings for whatever language, compiles for any platform and the documentation is superb.
scrollaway 10y ago
Qt has a truly pleasant API and bindings in many languages. If you haven't used it before - and I know you haven't, otherwise you wouldn't be asking :) - give it a try. There's very little that's more cross-platform.
- rsp1984 10y ago
  We have chosen Qt for our new cross-platform app (Android, Windows, MacOS) which we've developed for the past 1.5 years and have overall not regretted it. Doing UIs with QML and Qt Quick is so much faster than Android's XML based system and gives you a lot of flexibility. 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.
  - steaminghacker 10y ago
    Same here. I ran into a few problems with Android. Controls 2 is not quite ready yet, I had to write some Java, but it worked. Hopefully more AndroidExtras will be added in time.
- ryandrake 10y ago
  Qt's nice, but the thing I've always disliked about it is that it re-implements all these basic types, like QString, QVector, QList, QMap, etc. and you need to use them to interact with all their APIs. So, you either have to decide you're all-in on Qt and have these QThis and QThat types littered all over your code (making it more difficult to interact with other third party libraries like boost that know nothing about Qt, or you need to agree on a boundary between your non-Qt-specific code and your UI, and maintain a layer that converts to and from standard types.
  - JBReefer 10y ago
    Shouldn't you always have a layer between your business logic and display logic? Seems like this shouldn't be an issue with proper MVVM.
zackify 10y ago
React (Native). You can build an iOS and android app with the same codebase. Even windows phone and ubuntu are starting to support it. Then when you want to use the web, your whole data layer can carry over to reactjs. It's a really nice way of doing things. There's even react native for Mac OS that someone has started.
- alexmuro 10y ago
  You can also wrap the reactjs web application in in Electron (http://electron.atom.io/ http://electron.atom.io/), which supports Mac, Windows and Linux.
tumdum_ 10y ago
There is also swing and javafx if you want to use jvm.
- Cyph0n 10y ago
  JavaFX is amazing, but I'm not sure how it holds up when an app gets complex.
  - WoodenChair 10y ago
    I think a bigger problem is that less and less end users have the JVM installed.
    - gschrader 10y ago
      JavaFX also has support to bundle a JRE with its native installer support, it can build a exe, msi, dmg etc. The bigger issue is Oracle not really giving it the proper attention.
    - mushiake 10y ago
      You can use javapackager.
      - invalidname 10y ago
        Did you try to using it in production? It's flaky at best...
    - StreamBright 10y ago
      Any source to this?
      - Cyph0n 10y ago
        Even if it were true, you can easily bundle a JRE with your app, which is what Oracle recommends actually. In the end, it still ends up being smaller in size than a Electron/NW.js app.
melle 10y ago
Depending on the type of UI, you could also give Kivy a try. https://kivy.org/ https://kivy.org/ 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.
- BucketSort 10y ago
  I've had some hard times porting Kivy to the Raspberry PI 3 on Raspbian. It is a decent toolkit, but I'm not so sure on the ease of cross-platform.
totocino 10y ago
Qt obviously, but beware of licencing
- _ZeD_ 10y ago
  Obsolete. Nowadays qt libs are distributed on choice between commercial and lgpl
  - totocino 10y ago
    Don't you have to release the source code of your application if you don't want to pay?
    - mlvljr 10y ago
      No. But different, if you are selling source -- then you pay.
    - majewsky 10y ago
      No. That's GPL, not LGPL.
    - iamcreasy 10y ago
      Not if you dynamically bind with qt libs. But yes you have to, if you statically bind with qt libs.
  - marcosdumay 10y ago
    Some language bidings still come in GPL only.
- hamidr 10y ago
  Can the licensing be an issue on Android or iOS?
  - doppioandante 10y ago
    I still haven't found a clear answer to that, but using the LGPL license could pose a problem, because you need to allow the user to recompile the application with his own version of Qt. On iOS shared libraries are not allowed on the store, so you should distribute the files for static linking... it becomes quite messy and sort of unclear from the legal point of view.
assente 10y ago
React-Native or the Web
elcct 10y ago
I see nobody mentioned Juce. It is pretty neat if you like C++
- walterbell 10y ago
  Is it competitive with Qt for non-audio apps?
  - FigBug 10y ago
    JUCE doesn't try and look native, it has it's own look and feel. Qt does on Windows and OSX. It really depends what you are trying to do.
    - rer 10y ago
      Thanks for this. It sounds like JUCE is eliminated.
- pierrec 10y ago
  JUCE is a great framework, has a very commendable coding style and is easy to get into. One thing to note is that the "JUCE way" of doing things is to have a UI that looks exactly the same on every platform - this is good for predictability, but if you want a UI that looks native, you're better off using Qt or wxWidgets (as C++ UI toolkits go). In many cases I'd say that's not an issue, and JUCE is underrated/underused as a general-purpose UI toolkit.
  - solipsism 10y ago
    commendable coding style Please explain!
    - pierrec 10y ago
      Well, commendable means "deserving praise", and when working with it, I generally appreciated the simplicity, consistency, and clarity I found throughout the JUCE codebase. 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: https://www.juce.com/learn/coding-standards https://www.juce.com/learn/coding-standards
knabacks 10y ago
There are plenty of options (all biased by personal opinion) for this task. Maybe one of these projects is a good fit for you (creating consistent uis should be easy with all of these). - https://crosswalk-project.org/ https://crosswalk-project.org/ - https://cordova.apache.org/ https://cordova.apache.org/ - https://kivy.org/ https://kivy.org/ - https://www.nativescript.org/ https://www.nativescript.org/ - https://www.xamarin.com/ https://www.xamarin.com/ - https://facebook.github.io/react-native/ https://facebook.github.io/react-native/ # - https://www.wxwidgets.org/ https://www.wxwidgets.org/ - http://nwjs.io/ http://nwjs.io/ - http://electron.atom.io/ http://electron.atom.io/
indubitably 10y ago
The internet.
dahart 10y ago
It would help a lot to have the question elaborate on what you really need. What do you mean by "best", and do you actually need the best? Do you need easy to learn, or code that is easy to deliver, or most powerful features, or most number of platforms covered? Do you include mobile in cross platform, and do you have a performance or language requirement? 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?
- mhuffman 10y ago
  I agree across the board with your assessment. 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.
  - rer 10y ago
anmorgan 10y ago
I've recently been using Crank Storyboard and I've been off to a good start. You can run it on embedded devices like ARM Cortex-M series processors, or Linux, iOS, Android, Windows, with openGL support. It does require a license though. http://cranksoftware.com/storyboard-suite 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.
fitzwatermellow 10y ago
Just getting started on Electron myself. Used by Atom, Slack, Visual Studio... It's worth a look ;) Electron - Build Cross-Platform Desktop Apps With HTML, JS, CSS http://electron.atom.io/ http://electron.atom.io/
- lossolo 10y ago
  A little correction: Visual Studio Code, not Visual Studio. They are totally different beasts.
- jbergens 10y ago
  Electron only works for desktop applications and probably needs a js-framework to work good. I think that React + Electron looks like a nice combo and then you can use React Native to create Android and iPhone apps also, probably sharing a lot of code between all versions.
  - jc4p 10y ago
    +1 on this, I'm having a very pleasant time working on a couple Electron+React apps right now. I've been starting my apps based off https://github.com/chentsulin/electron-react-boilerplate https://github.com/chentsulin/electron-react-boilerplate but diverging greatly after getting it running.
  - CuriousSkeptic 10y ago
    Instead of react native you can also just reuse the UI-code directly for the mobile deployment. Just add meta tags like apple-mobile-web-app-capable=true and style with @media-rules. 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.
  - WorldMaker 10y ago
    At the moment the pairing seems to be Electron + Cordova for non-React JS frameworks; with those two you can share 100% HTML at least if you have a responsive CSS design. 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.
fezz 10y ago
I like JUCE. http://www.juce.com/ http://www.juce.com/ It's used for a lot of audio apps and plugins but lots beyond that too.
- tomcam 10y ago
  JUCE is all that and a bag of chips. It is a perfectly capable competitor to QT, yet also has fantastic multimedia APIs. Docs are excellent. Source is ultra clear.
antonios 10y ago
If you don't want a _native_ GUI, you can go the Electron way. This way you'll have a fully cross-platform application with minimum hassle. If you want a native one, probably Qt is the winner here.
networked 10y ago
What is the best depends on your exact requirements but three good options to get a GUI off the ground quickly are Tk [1], wxWidgets (and wxPython [2] and wxLua [3] in particular) and Lazarus (LCL) [4]. 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]. [1] http://www.tkdocs.com/ http://www.tkdocs.com/ [2] https://wxpython.org/ https://wxpython.org/ [3] http://wxlua.sourceforge.net/ http://wxlua.sourceforge.net/ [4] http://www.lazarus-ide.org/ http://www.lazarus-ide.org/, http://wiki.lazarus.freepascal.org/LCL http://wiki.lazarus.freepascal.org/LCL [5] http://www.tkdocs.com/tutorial/idle.html http://www.tkdocs.com/tutorial/idle.html [6] https://tcl.wiki/Starpack https://tcl.wiki/Starpack
- witty_username 10y ago
  Tk is antiquated (no antialiasing [1]) and has a poor look on Linux. It lacks functionality in widgets such as embedding a progressbar in a tree/list (don't remember) widget, which Qt supports. Also, poor font rendering support. (doesn't render Devanagari and probably CJK scripts). It feels like a 10 year old tech which it is. (1) Maybe there is some option for it somewhere, but if so, having antialiasing disabled by default is weird.
  - jrapdx3 10y ago
    Suitability of Tcl/Tk depends on what the goal is. For some applications, like utilities, GUI access to CLI tools, form-based data entry, etc., Tk is fine. It isn't a good option for a sophisticated drawing program, and I would try to use it for a full-bore word processor. 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.
antoineMoPa 10y ago
GTK may have a difficult API, but it is portable and it gives a better feel than Qt for Linux+Gnome users like me (I will always choose a GTK app over a Qt app).
- geraldcombs 10y ago
  GTK+'s Windows support is mixed. It mostly works, but bugs reports don't seem to get much attention and you're on your own if you want Windows binaries. macOS support is effectively an afterthought. The only teir 1, actively supported platform appears to be Linux which makes me wonder why the project advertises itself as "cross-platform."
- justinclift 10y ago
  GTK's documentation is atrocious for anything in depth, and has been for years. 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. :(
  - rer 10y ago
    @geraldcombs and @justinclift I didn't know any of this, thanks so much! It sounds like GTK is eliminated too. What's left now, QT and wxWidgets?
    - justinclift 10y ago
      If you're looking to do a desktop GUI type of application, then those two are decent choices. 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. :)
babuskov 10y ago
Strange nobody mentioned wxWidgets so far which gives you true native apps, so I'll do it: http://wxwidgets.org http://wxwidgets.org 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 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: https://en.wikipedia.org/wiki/WxWidgets https://en.wikipedia.org/wiki/WxWidgets
- Svenstaro 10y ago
  In my experience with it, wxwidgets has a very antiquated feeling to the API (I know, subjective) and it didn't ship high DPI support when I used it. Its Python bindings at the time felt rather unpythonic. Generally I wouldn't want to use this again.
  - fsloth 10y ago
    "wxwidgets has a very antiquated feeling to the API" 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.
    - deleted 10y ago
      [deleted]
    - gwbas1c 10y ago
      At least on Windows, there's a new UI API every 7 years. MFC, Winforms, WPF... 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?
jasonjei 10y ago
You can have your cake and eat it too. If you have to build a native desktop app, you can use Chromium Embedded Framework. Spotify is one of its biggest users. You can still build your UI in HTML but drive it with native code (C++, Objective-C, C#, etc). We used CEF when we realized how painful Win32 C++ WTL desktop UI was.
open-source-ux 10y ago
Take a look at Free Pascal and the Lazarus IDE. 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. http://www.lazarus-ide.org/ http://www.lazarus-ide.org/
agentultra 10y ago
It depends on what you mean by, "cross-platform." In my world there is no such thing. You pick your target platforms and program to them. However it is common to imply "major platforms" (ie: iOS, Android, Windows 10, OSX). Different platforms have different requirements and will shape your solution. 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. [0] https://github.com/vurtun/nuklear https://github.com/vurtun/nuklear
- rer 10y ago
  > there is no such thing Why?
  - agentultra 10y ago
    Different platform, different requirements. 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.
kev6168 10y ago
There is Livecode (livecode.org). Does anyone have experience using it in production? It's cross-platform and has both commercial and open source (community) versions.
- tluyben2 10y ago
  I like it for prototyping. I have done some real client projects with it and it does work well and fast. Especially for apps that either require a custom UI or not too polished at all.
EddieSpeaks 10y ago
Why isn't anyone here mentioning Xamarin + GTK#?
- fsloth 10y ago
  You just mentioned them. You could elaborate what makes them worthwhile your endorsement...
- mushiake 10y ago
  Gtk# only suppports gtk2. (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.
justsaysmthng 10y ago
The choice of the UI library depends a lot on the type of app you're developing. For many types of apps, a single page HTML/JS/CSS app bundled as an executable is the best choice. 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 !
max_ 10y ago
I have used Electron previously, but now Ionic is my favorite http://ionicframework.com/ http://ionicframework.com/
- saurik 10y ago
  Electron is desktop only and Ionic is mobile only; you can't really compare them as there is never a choice between them.
  - dangoor 10y ago
    Ionic 2 supports (or intends to support) Electron, desktop web and progressive web apps: http://blog.ionic.io/announcing-ionic-2-beta-7/ http://blog.ionic.io/announcing-ionic-2-beta-7/
- rer 10y ago
  No CSS or Javascript. Sorry.
SimianLogic2 10y ago
I've been going the other direction recently. We have a photoshop plugin that exports layers with metadata (where an image is located, fonts, font sizes, text, etc). For any platform that has a basic scene graph and some sort of label functionality (Unity, iOS, android, theoretically even web) we write a runtime that converts the metadata into runtime UIs. So it ends up being custom logic for interaction on each platform, but the design/assets can be shared cross-platform.
SeaDude 10y ago
I'm barely a geek, let alone a hacker, but have been trying to learn NativeScript for the past month or so. You might want to check it out. 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 http://docs.nativescript.org Emulator Here: https://docs.genymotion.com https://docs.genymotion.com
- rer 10y ago
  No Javascript, sorry.
mherrmann 10y ago
For a file manager I'm developing [1], this question recently boiled down to Electron vs (Py)Qt. I chose (Py)Qt because Electron's startup speed is too slow. [1]: https://fman.io https://fman.io
- infinite8s 10y ago
  How are you handling licensing? Are you using the commercial version of PyQt? I've been thinking of distributing some apps I've built but I don't want to make them GPL (I don't mind using MIT or BSD though).
  - ptman 10y ago
    There's PySize https://wiki.qt.io/PySide https://wiki.qt.io/PySide but it probably needs work
    - infinite8s 10y ago
      PySide doesn't work with Qt5 yet.
  - mherrmann 10y ago
    I'm using the commercial license. It's really not that expensive.
sergiotapia 10y ago
Electron I would say. You make your UI's using HTML and CSS, it looks the same everywhere. Not bad, I guess although it does have it performance issues. Atom for example is built with Electron.
jbergens 10y ago
You might have to define which platforms you want or need to target. There is a difference between just writing a desktop application that should work on Windows and Mac, an app that should work on iPhone and Android and a solution that needs to work on all of the above plus Linux desktops and Windows Phones and web browsers. [edit: spelling]
edko 10y ago
"The best" is subjective. I have played around with libui (https://github.com/andlabs/libui https://github.com/andlabs/libui), which runs on Windows, Linux, and macOS. A nice thing about it is that it is written in C, and therefore has bindings with several programming languages. I have experimented using it from Java (via JNA) and it works quite nicely.
- rer 10y ago
  libui is kind of neat. It wraps around GTK+. Why did libui have to do that? In other words, is GTK+ bad enough that the easiest way to use it is to wrap around it?
  - barrkel 10y ago
    GTK+ is dreadful on Windows. I'd stay away. 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.
    - rer 10y ago
      Ok, no GTK+! (Could this be fixed with GLib?) 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?
      - andlabs 10y ago
        libui only wraps around GTK+ on Unix systems. On Windows, it uses the native Windows API directly. 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.
EGreg 10y ago
I'm just going to come out and say The Web. Stick WebViews in your app and if you need some native API use a bridge (like PhoneGap). 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: http://qbix.com/platform http://qbix.com/platform
- EGreg 10y ago
  Just out of curiosity, why did you downvote this? You don't think the Web is a good platform for UI or you don't like that I linked to our library built on top of it that we open sourced for UI?
  - exDM69 10y ago
    Didn't downvote but... At the very least, a suggestion for a cross platform library for "sticking webviews to your app" would be needed to answer OP's question.
Sir_Cmpwn 10y ago
I like Xwt: https://github.com/mono/xwt https://github.com/mono/xwt Used it for the TrueCraft launcher: https://github.com/SirCmpwn/TrueCraft/tree/master/TrueCraft.Launcher https://github.com/SirCmpwn/TrueCraft/tree/master/TrueCraft....
BatFastard 10y ago
Adobe AIR - much as people like to hate on flash, Adobe AIR kicks ass as a cross platform UI. It has years of use and abuse. 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.
skoocda 10y ago
I'm surprised nobody has mentioned Angular 2 yet. It's new, so don't expect tons of support. Nonetheless, it's there as an option!
- jack9 10y ago
  Probably because you didn't read the OP's explanation of minimum standards that included. > - 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!
edtechdev 10y ago
React Native supports * iOS * Android * OS X https://github.com/ptmt/react-native-macos https://github.com/ptmt/react-native-macos * Windows https://github.com/ReactWindows/react-native-windows https://github.com/ReactWindows/react-native-windows * Ubuntu https://developer.ubuntu.com/en/blog/2016/08/05/introducing-react-native-ubuntu/ https://developer.ubuntu.com/en/blog/2016/08/05/introducing-... * the web https://github.com/necolas/react-native-web https://github.com/necolas/react-native-web
- babuskov 10y ago
  AFAICT, it isn't "Windows", but "Windows 10 only". Is this correct?
  - jc4p 10y ago
    Yes the windows link above is for Universal Windows Platform apps which isn't what most people think of when they think "windows app". For React Native on desktop I've been bundling my React app into a Electron shell, works pretty well.
cel1ne 10y ago
I'd probably use Electron and/or SWT along with javascript and kotlin.
codesmythe 10y ago
SWT rarely gets any love in desktop UI threads around here, but I recently wrote a small desktop program using SWT and Java and found it to be a reasonably pleasant experience. The main purpose of the program was to allow the user to view a couple of database tables, and using a tree view widget with columns was a key requirement. SWT is the widget toolkit used by Eclipse and is mostly native, using GTK on Linux, Cocoa on macOS and the Win32 API on Windows. It is still in active development, and support for HiDpi was recently added. 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. :-)
robot 10y ago
The best one I know is html 5
gwbas1c 10y ago
I work on a cross-platform application that runs on both Windows and Mac. 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.
- rer 10y ago
  > cross-platform UI libraries don't really let you fine-tune the UI I want to be able to fine-tune the UI.
  - infinite8s 10y ago
    You can't have both - cross-platform with native looks yet fine tunability, since those desires are at odds with each other (unless you want to implement that tunability for each platform you support).
levbrie 10y ago
My vote is for electron, although I'm following how React Native develops really closely. From what I've seen, the best new "Desktop" apps tend to be built with electron. We've been using it in production and, despite having to make pull requests for framework-level bugs fairly regularly, we've haad a pretty good experience overall, and far better than anything else we've tried - although, as I said, we have yet to seriously look into React Native. Also, by cross-platform I'm assuming you mean OS X, Windows, and Linux. If you also want to include mobile, then there are so few options there's no longer any real reason to debate.
c-smile 10y ago
http://sciter.com http://sciter.com 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 http://sciter.com/images/sciter-clock.png Check technology introduction article: http://www.codeproject.com/Articles/859098/Sciter-multiplatform-embeddable-HTML-CSS-scripting http://www.codeproject.com/Articles/859098/Sciter-multiplatf...
jlarocco 10y ago
It depends on what language you're using and your requirements, but my preference is Qt. It has bindings to several languages; it supports most common platforms; the API is consistent, stable, and well documented; and it's easy to get up and running on all of the platforms it supports. 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.
heavenlyhash 10y ago
There's a lot of great web-tech based solutions. Other commentors are covering those, so I'll suggest something different: For a take outside of the web, Golang with OpenGL bindings has a lot of promise for shipping $everywhere. The https://github.com/go-gl 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/ 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.
SyneRyder 10y ago
I'll throw in a mention for Xojo: http://www.xojo.com http://www.xojo.com 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.
- rer 10y ago
  Is it open-source? What I want is closer to writing my own Xojo.
  - SyneRyder 10y ago
    Xojo isn't open source, but I think Lazarus is. It's an open source cross-platform version of Delphi, which could be described as "Visual Pascal". I've not used Lazarus myself but I used to use Delphi. http://www.lazarus-ide.org http://www.lazarus-ide.org
doozy 10y ago
None, abstract the functionality of your app into a cross-platform library and build a native GUI for each platform you support using that platform's native SDK.
- bluedino 10y ago
  To expand on that, BackBlaze did a blog post on cross-platform tips: https://www.backblaze.com/blog/10-rules-for-how-to-write-cross-platform-code/ https://www.backblaze.com/blog/10-rules-for-how-to-write-cro...
- rer 10y ago
  Shouldn't this be a solved problem?
  - barrkel 10y ago
    If UI controls were a solved problem, there would be no innovation in UI design. Your perspective here is childish, imo.
  - paulddraper 10y ago
    There's a reason there are multiple OS's, right? One of the reasons is different UI paradigms and choices.
pipio21 10y ago
It depends on what you need. 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.
undoware 10y ago
Motif. >:]
rer 10y ago
Here's what I want. - 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.
- rwmj 10y ago
  Pretty sure that C++ and Qt is what you want. Maybe not perfect in every sense, but widely used and battle-tested. 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 https://fedoraproject.org/wiki/MinGW or the Debian or SUSE equivalents).
  - SXX 10y ago
    Or you can use preconfigured cross-compilation toolchain like MXE[1]. If you have clean codebase and use CMake it's usually enough to just pass one extra argument to get working binary out. And it's also work on OS X. [1] http://mxe.cc/ http://mxe.cc/
    - justinclift 10y ago
      MXE has an ok reputation. Not everything seems to play well with it though. :( 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 We're building our releases natively now, and the nightlies will be built natively too in (hopefully near) future. Guess we just outgrew MXE?
deleted 10y ago
[deleted]
TheGrassyKnoll 10y ago
Which one has the best tutorial so a wanna-be can get started ? Usually, to me, the 'best' tutorials have the most examples. (Yes, an example is worth a thousand words) (I'd want to be starting on Ubuntu, with Python 3)
irascible 10y ago
Chrome.
mushiake 10y ago
IUP[0] has not been menthioned. 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/ http://webserver2.tecgraf.puc-rio.br/iup/ [1]https://github.com/andlabs/libui https://github.com/andlabs/libui
- corysama 10y ago
  There is a project to add cocoa support that would appreciate some help. https://github.com/ewmailing/IupCocoa/tree/Cocoa https://github.com/ewmailing/IupCocoa/tree/Cocoa
maramono 10y ago
Here's what I use to develop Mutator's [0] and TestLess' [1] GUIs: - implement in Ruby - compile to Java using Warbler/JRuby - Run as Java on any platform that supports Java. You can use javafx or swing, although javafx needs certain combination of warbler and jruby to work. [0] http://ortask.com/mutator/ http://ortask.com/mutator/ [1] http://ortask.com/testless/ http://ortask.com/testless/
matthewhall 10y ago
Electron shell without a doubt. HTMl is so fluid and extensionable that it is hard to beat. It doesn't work on mobile however. Also it isn't as fast as c native but you use node js which is greater than pure js for obvious reasons.
Toover 10y ago
Qt with no hésitation. Works everywhere.
Toover 10y ago
Qt with no hesitation. It works everywhere.
tylerlarson 10y ago
A few other people have mentioned JavaScript and HTML but in my experience HTML and CSS support varies wildly between platforms and as applications become larger it is difficult to tune the performance of your running application. Also the implementation of the base code for HTML tags and what CSS properties can do are inaccessible to JavaScript making many task much harder than they would be in other environments where you can simply extend or introspect the internals. 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.

223 points by rer 10y ago

evolighting 10y ago

QT！

muminoff 10y ago
Not QT, it is Qt.
- emilsedgh 10y ago
  No idea why you're being downvoted. QT refers to Apple's Quick Time. Qt refers to the Qt project, pronounced 'cute'.

tariqrauf 10y ago

Depends on what you're after :) Electron or QT for cross-desktop apps, Angular & Ion framework for cross-mobile apps, React & React-native for cross-mobile apps

api 10y ago
There are efforts to bring React Native to desktop but I don't think they are production ready yet.
- tariqrauf 10y ago
  you can get react on desktop with electron

shireboy 10y ago

Not a library per se, but HTML+CSS+JS. Bootstrap or some other mobile responsive framework. Works on just about every device&OS. Phone gap or similar if you really need native.

DougWebb 10y ago
+1, because I had the urge to say the same thing. 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.

tyfon 10y ago

I have tried many but always turn back to qt. It has bindings for whatever language, compiles for any platform and the documentation is superb.

scrollaway 10y ago

Qt has a truly pleasant API and bindings in many languages. If you haven't used it before - and I know you haven't, otherwise you wouldn't be asking :) - give it a try. There's very little that's more cross-platform.

rsp1984 10y ago
We have chosen Qt for our new cross-platform app (Android, Windows, MacOS) which we've developed for the past 1.5 years and have overall not regretted it. Doing UIs with QML and Qt Quick is so much faster than Android's XML based system and gives you a lot of flexibility. 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.
- steaminghacker 10y ago
  Same here. I ran into a few problems with Android. Controls 2 is not quite ready yet, I had to write some Java, but it worked. Hopefully more AndroidExtras will be added in time.
ryandrake 10y ago
Qt's nice, but the thing I've always disliked about it is that it re-implements all these basic types, like QString, QVector, QList, QMap, etc. and you need to use them to interact with all their APIs. So, you either have to decide you're all-in on Qt and have these QThis and QThat types littered all over your code (making it more difficult to interact with other third party libraries like boost that know nothing about Qt, or you need to agree on a boundary between your non-Qt-specific code and your UI, and maintain a layer that converts to and from standard types.
- JBReefer 10y ago
  Shouldn't you always have a layer between your business logic and display logic? Seems like this shouldn't be an issue with proper MVVM.

zackify 10y ago

React (Native). You can build an iOS and android app with the same codebase. Even windows phone and ubuntu are starting to support it. Then when you want to use the web, your whole data layer can carry over to reactjs. It's a really nice way of doing things. There's even react native for Mac OS that someone has started.

alexmuro 10y ago
You can also wrap the reactjs web application in in Electron (http://electron.atom.io/ http://electron.atom.io/), which supports Mac, Windows and Linux.

tumdum_ 10y ago

There is also swing and javafx if you want to use jvm.

Cyph0n 10y ago
JavaFX is amazing, but I'm not sure how it holds up when an app gets complex.
- WoodenChair 10y ago
  I think a bigger problem is that less and less end users have the JVM installed.
  - gschrader 10y ago
    JavaFX also has support to bundle a JRE with its native installer support, it can build a exe, msi, dmg etc. The bigger issue is Oracle not really giving it the proper attention.
  - mushiake 10y ago
    You can use javapackager.
    - invalidname 10y ago
      Did you try to using it in production? It's flaky at best...
  - StreamBright 10y ago
    Any source to this?
    - Cyph0n 10y ago
      Even if it were true, you can easily bundle a JRE with your app, which is what Oracle recommends actually. In the end, it still ends up being smaller in size than a Electron/NW.js app.

melle 10y ago

Depending on the type of UI, you could also give Kivy a try. https://kivy.org/ https://kivy.org/ 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.

BucketSort 10y ago
I've had some hard times porting Kivy to the Raspberry PI 3 on Raspbian. It is a decent toolkit, but I'm not so sure on the ease of cross-platform.

totocino 10y ago

Qt obviously, but beware of licencing

_ZeD_ 10y ago
Obsolete. Nowadays qt libs are distributed on choice between commercial and lgpl
- totocino 10y ago
  Don't you have to release the source code of your application if you don't want to pay?
  - mlvljr 10y ago
    No. But different, if you are selling source -- then you pay.
  - majewsky 10y ago
    No. That's GPL, not LGPL.
  - iamcreasy 10y ago
    Not if you dynamically bind with qt libs. But yes you have to, if you statically bind with qt libs.
- marcosdumay 10y ago
  Some language bidings still come in GPL only.
hamidr 10y ago
Can the licensing be an issue on Android or iOS?
- doppioandante 10y ago
  I still haven't found a clear answer to that, but using the LGPL license could pose a problem, because you need to allow the user to recompile the application with his own version of Qt. On iOS shared libraries are not allowed on the store, so you should distribute the files for static linking... it becomes quite messy and sort of unclear from the legal point of view.

assente 10y ago

React-Native or the Web

elcct 10y ago

I see nobody mentioned Juce. It is pretty neat if you like C++

walterbell 10y ago
Is it competitive with Qt for non-audio apps?
- FigBug 10y ago
  JUCE doesn't try and look native, it has it's own look and feel. Qt does on Windows and OSX. It really depends what you are trying to do.
  - rer 10y ago
    Thanks for this. It sounds like JUCE is eliminated.
pierrec 10y ago
JUCE is a great framework, has a very commendable coding style and is easy to get into. One thing to note is that the "JUCE way" of doing things is to have a UI that looks exactly the same on every platform - this is good for predictability, but if you want a UI that looks native, you're better off using Qt or wxWidgets (as C++ UI toolkits go). In many cases I'd say that's not an issue, and JUCE is underrated/underused as a general-purpose UI toolkit.
- solipsism 10y ago
  commendable coding style Please explain!
  - pierrec 10y ago
    Well, commendable means "deserving praise", and when working with it, I generally appreciated the simplicity, consistency, and clarity I found throughout the JUCE codebase. 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: https://www.juce.com/learn/coding-standards https://www.juce.com/learn/coding-standards

knabacks 10y ago

There are plenty of options (all biased by personal opinion) for this task. Maybe one of these projects is a good fit for you (creating consistent uis should be easy with all of these). - https://crosswalk-project.org/ https://crosswalk-project.org/ - https://cordova.apache.org/ https://cordova.apache.org/ - https://kivy.org/ https://kivy.org/ - https://www.nativescript.org/ https://www.nativescript.org/ - https://www.xamarin.com/ https://www.xamarin.com/ - https://facebook.github.io/react-native/ https://facebook.github.io/react-native/ # - https://www.wxwidgets.org/ https://www.wxwidgets.org/ - http://nwjs.io/ http://nwjs.io/ - http://electron.atom.io/ http://electron.atom.io/

indubitably 10y ago

The internet.

dahart 10y ago

It would help a lot to have the question elaborate on what you really need. What do you mean by "best", and do you actually need the best? Do you need easy to learn, or code that is easy to deliver, or most powerful features, or most number of platforms covered? Do you include mobile in cross platform, and do you have a performance or language requirement? 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?

mhuffman 10y ago
I agree across the board with your assessment. 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.
- rer 10y ago

anmorgan 10y ago

I've recently been using Crank Storyboard and I've been off to a good start. You can run it on embedded devices like ARM Cortex-M series processors, or Linux, iOS, Android, Windows, with openGL support. It does require a license though. http://cranksoftware.com/storyboard-suite 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.

fitzwatermellow 10y ago

Just getting started on Electron myself. Used by Atom, Slack, Visual Studio... It's worth a look ;) Electron - Build Cross-Platform Desktop Apps With HTML, JS, CSS http://electron.atom.io/ http://electron.atom.io/

lossolo 10y ago
A little correction: Visual Studio Code, not Visual Studio. They are totally different beasts.
jbergens 10y ago
Electron only works for desktop applications and probably needs a js-framework to work good. I think that React + Electron looks like a nice combo and then you can use React Native to create Android and iPhone apps also, probably sharing a lot of code between all versions.
- jc4p 10y ago
  +1 on this, I'm having a very pleasant time working on a couple Electron+React apps right now. I've been starting my apps based off https://github.com/chentsulin/electron-react-boilerplate https://github.com/chentsulin/electron-react-boilerplate but diverging greatly after getting it running.
- CuriousSkeptic 10y ago
  Instead of react native you can also just reuse the UI-code directly for the mobile deployment. Just add meta tags like apple-mobile-web-app-capable=true and style with @media-rules. 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.
- WorldMaker 10y ago
  At the moment the pairing seems to be Electron + Cordova for non-React JS frameworks; with those two you can share 100% HTML at least if you have a responsive CSS design. 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.

fezz 10y ago

I like JUCE. http://www.juce.com/ http://www.juce.com/ It's used for a lot of audio apps and plugins but lots beyond that too.

tomcam 10y ago
JUCE is all that and a bag of chips. It is a perfectly capable competitor to QT, yet also has fantastic multimedia APIs. Docs are excellent. Source is ultra clear.

antonios 10y ago

If you don't want a _native_ GUI, you can go the Electron way. This way you'll have a fully cross-platform application with minimum hassle. If you want a native one, probably Qt is the winner here.

networked 10y ago

What is the best depends on your exact requirements but three good options to get a GUI off the ground quickly are Tk [1], wxWidgets (and wxPython [2] and wxLua [3] in particular) and Lazarus (LCL) [4]. 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]. [1] http://www.tkdocs.com/ http://www.tkdocs.com/ [2] https://wxpython.org/ https://wxpython.org/ [3] http://wxlua.sourceforge.net/ http://wxlua.sourceforge.net/ [4] http://www.lazarus-ide.org/ http://www.lazarus-ide.org/, http://wiki.lazarus.freepascal.org/LCL http://wiki.lazarus.freepascal.org/LCL [5] http://www.tkdocs.com/tutorial/idle.html http://www.tkdocs.com/tutorial/idle.html [6] https://tcl.wiki/Starpack https://tcl.wiki/Starpack

witty_username 10y ago
Tk is antiquated (no antialiasing [1]) and has a poor look on Linux. It lacks functionality in widgets such as embedding a progressbar in a tree/list (don't remember) widget, which Qt supports. Also, poor font rendering support. (doesn't render Devanagari and probably CJK scripts). It feels like a 10 year old tech which it is. (1) Maybe there is some option for it somewhere, but if so, having antialiasing disabled by default is weird.
- jrapdx3 10y ago
  Suitability of Tcl/Tk depends on what the goal is. For some applications, like utilities, GUI access to CLI tools, form-based data entry, etc., Tk is fine. It isn't a good option for a sophisticated drawing program, and I would try to use it for a full-bore word processor. 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.

antoineMoPa 10y ago

GTK may have a difficult API, but it is portable and it gives a better feel than Qt for Linux+Gnome users like me (I will always choose a GTK app over a Qt app).

geraldcombs 10y ago
GTK+'s Windows support is mixed. It mostly works, but bugs reports don't seem to get much attention and you're on your own if you want Windows binaries. macOS support is effectively an afterthought. The only teir 1, actively supported platform appears to be Linux which makes me wonder why the project advertises itself as "cross-platform."
justinclift 10y ago
GTK's documentation is atrocious for anything in depth, and has been for years. 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. :(
- rer 10y ago
  @geraldcombs and @justinclift I didn't know any of this, thanks so much! It sounds like GTK is eliminated too. What's left now, QT and wxWidgets?
  - justinclift 10y ago
    If you're looking to do a desktop GUI type of application, then those two are decent choices. 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. :)

babuskov 10y ago

Strange nobody mentioned wxWidgets so far which gives you true native apps, so I'll do it: http://wxwidgets.org http://wxwidgets.org 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 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: https://en.wikipedia.org/wiki/WxWidgets https://en.wikipedia.org/wiki/WxWidgets

Svenstaro 10y ago
In my experience with it, wxwidgets has a very antiquated feeling to the API (I know, subjective) and it didn't ship high DPI support when I used it. Its Python bindings at the time felt rather unpythonic. Generally I wouldn't want to use this again.
- fsloth 10y ago
  "wxwidgets has a very antiquated feeling to the API" 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.
  - deleted 10y ago
    [deleted]
  - gwbas1c 10y ago
    At least on Windows, there's a new UI API every 7 years. MFC, Winforms, WPF... 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?

jasonjei 10y ago

You can have your cake and eat it too. If you have to build a native desktop app, you can use Chromium Embedded Framework. Spotify is one of its biggest users. You can still build your UI in HTML but drive it with native code (C++, Objective-C, C#, etc). We used CEF when we realized how painful Win32 C++ WTL desktop UI was.

open-source-ux 10y ago

Take a look at Free Pascal and the Lazarus IDE. 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. http://www.lazarus-ide.org/ http://www.lazarus-ide.org/

agentultra 10y ago

It depends on what you mean by, "cross-platform." In my world there is no such thing. You pick your target platforms and program to them. However it is common to imply "major platforms" (ie: iOS, Android, Windows 10, OSX). Different platforms have different requirements and will shape your solution. 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. [0] https://github.com/vurtun/nuklear https://github.com/vurtun/nuklear

rer 10y ago
> there is no such thing Why?
- agentultra 10y ago
  Different platform, different requirements. 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.

kev6168 10y ago

There is Livecode (livecode.org). Does anyone have experience using it in production? It's cross-platform and has both commercial and open source (community) versions.

tluyben2 10y ago
I like it for prototyping. I have done some real client projects with it and it does work well and fast. Especially for apps that either require a custom UI or not too polished at all.

EddieSpeaks 10y ago

Why isn't anyone here mentioning Xamarin + GTK#?

fsloth 10y ago
You just mentioned them. You could elaborate what makes them worthwhile your endorsement...
mushiake 10y ago
Gtk# only suppports gtk2. (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.

justsaysmthng 10y ago

The choice of the UI library depends a lot on the type of app you're developing. For many types of apps, a single page HTML/JS/CSS app bundled as an executable is the best choice. 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 !

max_ 10y ago

I have used Electron previously, but now Ionic is my favorite http://ionicframework.com/ http://ionicframework.com/

saurik 10y ago
Electron is desktop only and Ionic is mobile only; you can't really compare them as there is never a choice between them.
- dangoor 10y ago
  Ionic 2 supports (or intends to support) Electron, desktop web and progressive web apps: http://blog.ionic.io/announcing-ionic-2-beta-7/ http://blog.ionic.io/announcing-ionic-2-beta-7/
rer 10y ago
No CSS or Javascript. Sorry.

SimianLogic2 10y ago

I've been going the other direction recently. We have a photoshop plugin that exports layers with metadata (where an image is located, fonts, font sizes, text, etc). For any platform that has a basic scene graph and some sort of label functionality (Unity, iOS, android, theoretically even web) we write a runtime that converts the metadata into runtime UIs. So it ends up being custom logic for interaction on each platform, but the design/assets can be shared cross-platform.

SeaDude 10y ago

I'm barely a geek, let alone a hacker, but have been trying to learn NativeScript for the past month or so. You might want to check it out. 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 http://docs.nativescript.org Emulator Here: https://docs.genymotion.com https://docs.genymotion.com

rer 10y ago
No Javascript, sorry.

mherrmann 10y ago

For a file manager I'm developing [1], this question recently boiled down to Electron vs (Py)Qt. I chose (Py)Qt because Electron's startup speed is too slow. [1]: https://fman.io https://fman.io

infinite8s 10y ago
How are you handling licensing? Are you using the commercial version of PyQt? I've been thinking of distributing some apps I've built but I don't want to make them GPL (I don't mind using MIT or BSD though).
- ptman 10y ago
  There's PySize https://wiki.qt.io/PySide https://wiki.qt.io/PySide but it probably needs work
  - infinite8s 10y ago
    PySide doesn't work with Qt5 yet.
- mherrmann 10y ago
  I'm using the commercial license. It's really not that expensive.

sergiotapia 10y ago

Electron I would say. You make your UI's using HTML and CSS, it looks the same everywhere. Not bad, I guess although it does have it performance issues. Atom for example is built with Electron.

jbergens 10y ago

You might have to define which platforms you want or need to target. There is a difference between just writing a desktop application that should work on Windows and Mac, an app that should work on iPhone and Android and a solution that needs to work on all of the above plus Linux desktops and Windows Phones and web browsers. [edit: spelling]

edko 10y ago

"The best" is subjective. I have played around with libui (https://github.com/andlabs/libui https://github.com/andlabs/libui), which runs on Windows, Linux, and macOS. A nice thing about it is that it is written in C, and therefore has bindings with several programming languages. I have experimented using it from Java (via JNA) and it works quite nicely.

rer 10y ago
libui is kind of neat. It wraps around GTK+. Why did libui have to do that? In other words, is GTK+ bad enough that the easiest way to use it is to wrap around it?
- barrkel 10y ago
  GTK+ is dreadful on Windows. I'd stay away. 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.
  - rer 10y ago
    Ok, no GTK+! (Could this be fixed with GLib?) 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?
    - andlabs 10y ago
      libui only wraps around GTK+ on Unix systems. On Windows, it uses the native Windows API directly. 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.

EGreg 10y ago

I'm just going to come out and say The Web. Stick WebViews in your app and if you need some native API use a bridge (like PhoneGap). 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: http://qbix.com/platform http://qbix.com/platform

EGreg 10y ago
Just out of curiosity, why did you downvote this? You don't think the Web is a good platform for UI or you don't like that I linked to our library built on top of it that we open sourced for UI?
- exDM69 10y ago
  Didn't downvote but... At the very least, a suggestion for a cross platform library for "sticking webviews to your app" would be needed to answer OP's question.

Sir_Cmpwn 10y ago

I like Xwt: https://github.com/mono/xwt https://github.com/mono/xwt Used it for the TrueCraft launcher: https://github.com/SirCmpwn/TrueCraft/tree/master/TrueCraft.Launcher https://github.com/SirCmpwn/TrueCraft/tree/master/TrueCraft....

BatFastard 10y ago

Adobe AIR - much as people like to hate on flash, Adobe AIR kicks ass as a cross platform UI. It has years of use and abuse. 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.

skoocda 10y ago

I'm surprised nobody has mentioned Angular 2 yet. It's new, so don't expect tons of support. Nonetheless, it's there as an option!

jack9 10y ago
Probably because you didn't read the OP's explanation of minimum standards that included. > - 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!

edtechdev 10y ago

React Native supports * iOS * Android * OS X https://github.com/ptmt/react-native-macos https://github.com/ptmt/react-native-macos * Windows https://github.com/ReactWindows/react-native-windows https://github.com/ReactWindows/react-native-windows * Ubuntu https://developer.ubuntu.com/en/blog/2016/08/05/introducing-react-native-ubuntu/ https://developer.ubuntu.com/en/blog/2016/08/05/introducing-... * the web https://github.com/necolas/react-native-web https://github.com/necolas/react-native-web

babuskov 10y ago
AFAICT, it isn't "Windows", but "Windows 10 only". Is this correct?
- jc4p 10y ago
  Yes the windows link above is for Universal Windows Platform apps which isn't what most people think of when they think "windows app". For React Native on desktop I've been bundling my React app into a Electron shell, works pretty well.

cel1ne 10y ago

I'd probably use Electron and/or SWT along with javascript and kotlin.

codesmythe 10y ago

SWT rarely gets any love in desktop UI threads around here, but I recently wrote a small desktop program using SWT and Java and found it to be a reasonably pleasant experience. The main purpose of the program was to allow the user to view a couple of database tables, and using a tree view widget with columns was a key requirement. SWT is the widget toolkit used by Eclipse and is mostly native, using GTK on Linux, Cocoa on macOS and the Win32 API on Windows. It is still in active development, and support for HiDpi was recently added. 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. :-)

robot 10y ago

The best one I know is html 5

gwbas1c 10y ago

I work on a cross-platform application that runs on both Windows and Mac. 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.

rer 10y ago
> cross-platform UI libraries don't really let you fine-tune the UI I want to be able to fine-tune the UI.
- infinite8s 10y ago
  You can't have both - cross-platform with native looks yet fine tunability, since those desires are at odds with each other (unless you want to implement that tunability for each platform you support).

levbrie 10y ago

My vote is for electron, although I'm following how React Native develops really closely. From what I've seen, the best new "Desktop" apps tend to be built with electron. We've been using it in production and, despite having to make pull requests for framework-level bugs fairly regularly, we've haad a pretty good experience overall, and far better than anything else we've tried - although, as I said, we have yet to seriously look into React Native. Also, by cross-platform I'm assuming you mean OS X, Windows, and Linux. If you also want to include mobile, then there are so few options there's no longer any real reason to debate.

c-smile 10y ago

http://sciter.com http://sciter.com 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 http://sciter.com/images/sciter-clock.png Check technology introduction article: http://www.codeproject.com/Articles/859098/Sciter-multiplatform-embeddable-HTML-CSS-scripting http://www.codeproject.com/Articles/859098/Sciter-multiplatf...

jlarocco 10y ago

It depends on what language you're using and your requirements, but my preference is Qt. It has bindings to several languages; it supports most common platforms; the API is consistent, stable, and well documented; and it's easy to get up and running on all of the platforms it supports. 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.

heavenlyhash 10y ago

There's a lot of great web-tech based solutions. Other commentors are covering those, so I'll suggest something different: For a take outside of the web, Golang with OpenGL bindings has a lot of promise for shipping $everywhere. The https://github.com/go-gl 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/ 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.

SyneRyder 10y ago

I'll throw in a mention for Xojo: http://www.xojo.com http://www.xojo.com 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.

rer 10y ago
Is it open-source? What I want is closer to writing my own Xojo.
- SyneRyder 10y ago
  Xojo isn't open source, but I think Lazarus is. It's an open source cross-platform version of Delphi, which could be described as "Visual Pascal". I've not used Lazarus myself but I used to use Delphi. http://www.lazarus-ide.org http://www.lazarus-ide.org

doozy 10y ago

None, abstract the functionality of your app into a cross-platform library and build a native GUI for each platform you support using that platform's native SDK.

bluedino 10y ago
To expand on that, BackBlaze did a blog post on cross-platform tips: https://www.backblaze.com/blog/10-rules-for-how-to-write-cross-platform-code/ https://www.backblaze.com/blog/10-rules-for-how-to-write-cro...
rer 10y ago
Shouldn't this be a solved problem?
- barrkel 10y ago
  If UI controls were a solved problem, there would be no innovation in UI design. Your perspective here is childish, imo.
- paulddraper 10y ago
  There's a reason there are multiple OS's, right? One of the reasons is different UI paradigms and choices.

pipio21 10y ago

It depends on what you need. 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.

undoware 10y ago

Motif. >:]

rer 10y ago

Here's what I want. - 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.

rwmj 10y ago
Pretty sure that C++ and Qt is what you want. Maybe not perfect in every sense, but widely used and battle-tested. 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 https://fedoraproject.org/wiki/MinGW or the Debian or SUSE equivalents).
- SXX 10y ago
  Or you can use preconfigured cross-compilation toolchain like MXE[1]. If you have clean codebase and use CMake it's usually enough to just pass one extra argument to get working binary out. And it's also work on OS X. [1] http://mxe.cc/ http://mxe.cc/
  - justinclift 10y ago
    MXE has an ok reputation. Not everything seems to play well with it though. :( 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 We're building our releases natively now, and the nightlies will be built natively too in (hopefully near) future. Guess we just outgrew MXE?

deleted 10y ago

[deleted]

TheGrassyKnoll 10y ago

Which one has the best tutorial so a wanna-be can get started ? Usually, to me, the 'best' tutorials have the most examples. (Yes, an example is worth a thousand words) (I'd want to be starting on Ubuntu, with Python 3)

irascible 10y ago

Chrome.

mushiake 10y ago

IUP[0] has not been menthioned. 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/ http://webserver2.tecgraf.puc-rio.br/iup/ [1]https://github.com/andlabs/libui https://github.com/andlabs/libui

corysama 10y ago
There is a project to add cocoa support that would appreciate some help. https://github.com/ewmailing/IupCocoa/tree/Cocoa https://github.com/ewmailing/IupCocoa/tree/Cocoa

maramono 10y ago

Here's what I use to develop Mutator's [0] and TestLess' [1] GUIs: - implement in Ruby - compile to Java using Warbler/JRuby - Run as Java on any platform that supports Java. You can use javafx or swing, although javafx needs certain combination of warbler and jruby to work. [0] http://ortask.com/mutator/ http://ortask.com/mutator/ [1] http://ortask.com/testless/ http://ortask.com/testless/

matthewhall 10y ago

Electron shell without a doubt. HTMl is so fluid and extensionable that it is hard to beat. It doesn't work on mobile however. Also it isn't as fast as c native but you use node js which is greater than pure js for obvious reasons.

Toover 10y ago

Qt with no hésitation. Works everywhere.

Toover 10y ago

Qt with no hesitation. It works everywhere.

tylerlarson 10y ago

A few other people have mentioned JavaScript and HTML but in my experience HTML and CSS support varies wildly between platforms and as applications become larger it is difficult to tune the performance of your running application. Also the implementation of the base code for HTML tags and what CSS properties can do are inaccessible to JavaScript making many task much harder than they would be in other environments where you can simply extend or introspect the internals. 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.