Some of the requirements (restrictions) for such a ui framework/toolkit are:
No single vendor lock down
Ability for real time data visualization
Good initial widgets
Good dash boarding capabilities
cross platform
Good development/debug environment
No flash
It's a pity you can't/won't use Flash. Else I could really recommend Adobe AIR. It has a good editor (Flex Builder built on Eclipse), a good component framework with many out of the box components, charting components set, ability to communicate with many different protocols (and you could write your own protocol implementation), cross platform, runs in the AIR runtime and not in the browser, file IO, ...
I wouldn't pass over Flex/Air (Flash) without a closer consideration but here are a few others I have come across:
wxWidgets
GTK+
Qt
There is also a slashdot post with links to some tookits I haven't heard of. I'll add their recommendations here:
GLUI, an OpenGL-based GUI
Whisper, a Mac/Windows application framework
WxWindows, a framework which supports Windows 3.1/95/98/NT, and Unix with GTK/Motif/Lesstif, and MacOS
YAAF, Yet Another Application Framework, offering suport for Macintosh OS, Windows 95 and Windows NT, and X Windows
CPLAT, a framework for developing MacOS and Windows (Linux soon) applications
Ardi's Carbonless Copies technology, which is a portable rewrite of much of the MacOS API
For general information:
GUI Toolkit/Framework Page
PIGUI FAQ Page
C++ User's Journal PIGUI Page
I might suggest Mozilla XUL, but it has some drawbacks:
No really good development / debug environment (although there are tools and debuggers; they are variable)
You are locked into a vendor, but it is Mozilla.
It is very easy to use though and allows you to reuse your web Javascript skills for a rich-client app.
There's also Java of course. It satifies all your requirements AFAICS.
Plenty of custom charting controls, which are things you will struggle to find for GTK/WxWindows/$other_small_userbase_framework.
If you dont like Swing(its come a long way - Metal is dead, long live SystemDefault L&F!), there are options like SWT or even QT bindings for java(QTJambi).
For C or C++ go QT, its APIs are really nice.
For RCAs check out Eclipse RCP. For RIAs, you might be interested in OpenLaszlo. It's a rich internet platform that can compile both to Flash and DHTML.
http://www.gnustep.org/
"GNUstep is a cross-platform, object-oriented framework for desktop application development. Based on the OpenStep specification originally created by NeXT (now Apple), GNUstep enables developers to rapidly build sophisticated software by employing a large library of reusable software components."
Portable to: Windows, BSD-based systems, Linux-based systems, HP/UX, , Solaris, Sparc, GNUstep Solaris 10 U2 vmware appliance, OpenSolaris, others.
I recently made a pretty complete list here: http://commadot.com/ria-frameworks/
ExtJS is probably my favorite and we use that at work. I think it satisfies your list. Otherwise, there are a bunch of other possibilities on that page.
Related
I'm looking for a desktop publishing platform for Mac, Windows, and Linux that is closely tied to PhoneGap in terms of the concept. I know that there's Titanium for Desktop (TideSDK?) but as far as I've used it before, it requires the end-users to download a big 70mb-ish runtime file once. What I liked about PhoneGap is that it doesn't require any of that (it works out of the box). I'm looking for something similar, only, instead of being meant for the mobile development, it 's targeted at desktop application development.
Perhaps I failed to mention it but if you are not aware of what I'm specifically talking about, I'm talking about an environment of sort that will let me code via an HTML base and output a native for said platforms. Both TideSDK and PhoneGap does this.
I would highly recommend giving TideSDK another chance, I have developed large, data driven applications on it in the past, and deployed to OSX and Windows and have personally been very satisfied with it. Also, it is now an open source project managed and maintained by a very good team with some oversight and help from Appcelerator (the original creators).
Theyre are two benefits to TideSDk as I see it:
License - TideSDK is open source licensed under a liberal Apache 2.0 license. As opposed to QT which is under the restrictive GNU Lesser Public, and commercial license.
Power - TideSDK allows you to leverage native API's (like phonegap) but access them in your favorite programming language (well, choose between Ruby, PHP, and Python). Your only options with QT are C++.
As for what you said about the 70MB runtime, this is not true, I built the runtime in with my last project, and the binary I gave to my clients (OSX) was only 15.3MB.
Hope this helps you come to a decision.
There is a way to run a PhoneGap HTML5 App on the Desktop with the help of Adobe AIR like described here: http://www.tricedesigns.com/2012/02/17/repurposing-phonegap-apps-as-desktop-apps/
But I am also looking for a less bloaty approach. Maybe based on Xulrunner/Prism/WebRT thing (or Chrome).
Tidesdk is the easiest, xml file is almost identical to the phonegap, provides powerful api and the best part you can package your app with runtime. I think you should stick to tidesdk.
I was looking for the same and found this implementation for windows ony: https://github.com/davejohnson/phonegap-windows
I did not tried it though.
I am attempting to write a cross-platform GUI application that would be deployed to Windows, Mac OS X, and Linux. My requirements are:
Single code base for all three deployment platforms, without a large amount of conditional logic for handling differences between platforms.
Looks as close to "native" as possible on all three platforms.
Easily distributable to all three platforms, in the sense that it could be easily installed by end users and does not suffer from extreme bloat (as discussed in this ArsTechnica article.)
Based on these requirements, I've narrowed down the selection of toolkits to Qt and wxWidgets, since none of the other toolkits that I know about (including Java's Swing and SWT, Flex, AIR, etc.) satisfy the "native-looking" requirement. Among these two final contenders, Qt appears to offer better support for applications that look and feel native on all three of my deployment platforms, but I'm willing to consider opinions to the contrary.
I would prefer not to use C++ as the implementation language, but I'm not sure if there are any practical alternatives. My biggest concern about using an implementation language other than C++ is the deployment problem. As discussed in the Ars Technica article, PyQt does not meet the "easy deployment' requirement in any practical sense, and I suspect that most other language bindings for Qt would suffer from the same deployment problems (at least on Mac OS X). Java (or Scala) with QtJambi? QtRuby? wxPython?
Does anyone know of any combination of language and toolkit that satisfies all three of the above requirements?
It depends on your needs. But in general Qt Framework (with any language) and Java SE (with any language) is much more better because it has not only cross-OS GUI libraries but also cross-OS networking, threads, ... wxWidgets is GUI only.
Both Qt and wxWidgets are nice. In my experience Qt is better. Swing is... Well, not so nice.
Both Qt and wxWidgets applications written in C++ and Java Swing applications are not so hard to deploy on Windows, Mac and Linux. The rule is that the deployment is simple when you are programming in "native" language. By "native" language I mean the language a framework itself is written in.
PyQt does not meet the "easy deployment' requirement in any practical sense...
Python (and any other language with the default implementation as interpreter) apps is hard to deploy in the usual sense (I mean in form of standalone executables).
So probably you have 2 choices:
C++/Qt or C++/wxWidgets.
Java/Swing if native look & feel is not very strict requirement.
wxWidgets is quite good, and does contain some non-GUI code (contrary to what kemiisto said): threads, sockets etc.
The nice thing about wxWidgets is that wxPython actually should be pretty easy to deploy on OS X. There are some other language bindings for wx, but wxPython is probably one of the oldest ones.
At my day job I've been developing cross-platform (Windows / MacOS / Linux) using perl and wxWidgets. The combination is pleasant to use for development (I'm a perl hacker) and I rarely have to include specialized code per platform. There are some perl modules that help out with this (e.g. File::HomeDir that knows about the canonical locations for document directories etc on the various platforms).
For release, I don't rely at all on the system perl installation and instead build a perl installation that is included in the release. This way I can completely control the runtime environment of the app. I ship a windows installer package via innosetup, an mac os .dmg file with a .app included that the user can just drag to their /Applications, and for linux I build debian and redhat packages.
Have you looked at Xojo? It definitely meets all three of your requirements and it is much simpler to learn and use than C++.
About a decade ago or so, it was fashionable to model a GUI in a cross-platform flavor of XML (like XUL) and then have a platform-specific rendering engine process that XML-file to display a layout. It is no longer fashionable to do this, however. Today, in 2017, the trend is to build your apps on platforms that allow you to write everything in HTML, CSS and/or JavaScript, no matter what environment your code is supposed to run in.
The "first generation" of this type of tools produced what are basically "hybrid" applications, where web applications run on top of browser-like & platform-specific WebViews. This technique is rather inefficient, however. Your apps don't feel very "native", are rather bloated and they tend to be rather lacking in performance. However, it's relatively easy to have a consistent look-and-feel in different environments. Phonegap / Cordova is the most popular platform for mobile environments and NW.js for desktop environments.
The "second generation" is different : they compile everything to fully "native", platform-specific binaries. Instead of relying on WebViews, "native" widgets are used when possible. This gives your app a more "native" look-and-feel, typically has less bloat and is much better for performance. However, you'll have more differences between the different platforms. Examples are NativeScript, React Native & Tabris.js (all for mobile environments).
Unfortunately, there are no "second generation" tools for desktop just yet. So, right now, if you want to build a cross-platform desktop app, you're stuck with "first generation" tools. NW.js has a longer track record than Electron and has support for various features not present in Electron, but it also comes with its drawbacks. AppJS is still older, but it's not as mature - and not nearly as popular - as the other two.
Anyway, their reliance on WebViews means that your application will feel more like a web app than a desktop app. And bloat and performance drawbacks are inevitable with this kind of solution. This means you'll never get the same performance as code you write directly in Java or C++ nor the same performance you'd get in "second generation" platforms, and it will never feel equally "native". However, it can still be the best solution eg. when a consistent look-and-feel across different platforms is more important or when you have a background as a web developer.
If performance, lack of bloat and your application getting that "native" feel are important criteria, you might want to wait a little longer until the first "second generation" platforms appear for desktop. It's really but a matter of time before platforms for desktop apps follow the same evolutionary path as platforms for mobile apps, although it might actually come in the form of "desktop extensions" to existing mobile platforms.
The way it's currently looking, it looks like you'll soon be able to write "native" apps for desktop & mobile alike with the exact same codebase. With React Native already having plugins that add support for Windows 10 and support for MacOS, I would personally go with React Native and give their dev team some time until they support all desktop environments I need to support and those extensions for desktop are mature enough for production environments.
If you can't wait that long, you don't want to bet on what's to come in the future or if these criteria aren't that important for whatever application you want to build today, you might want to try some of the "first generation" platforms currently available and see which is most suitable for you. Just be aware of the drawbacks!
As always, choose wisely...
Popular platforms
First generation platforms for mobile environments (iOS & Android)
Meteor (built on top of Cordova)
Ionic (built on top of Cordova)
Second generation platforms for mobile environments (iOS & Android)
NativeScript (AngularJS eco-system).
React Native (React eco-system)
Tabris.js
Platforms for desktop environments (Windows, Linux or MacOS)
Electron
NW.js
AppJS
Platforms for smart home and IoT devices
iViewer
Iridium mobile
.Net (C# or VB.Net) is what I would use for this (in fact, it is what I use for my own application). Thanks to the Mono project, .Net applications can run on Mac and Linux as well as Windows without any modifications to the code (unless you're calling Windows API functions). You don't even have to compile different versions of your program: the same EXE will run on all platforms.
Java/SWT is one of the good choices. You can find a lot of information about it here.
Java does support "native-looking" applications by using the SystemLookAndFeel. The quickest way to try is to invoke the following at application start up.
UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
Take a look at this for more information on the available Look and Feels in Java.
http://java.sun.com/docs/books/tutorial/uiswing/lookandfeel/plaf.html
What GUI toolkit does Valve use for Steam? Is it Qt? I am interested in using the same toolkit for a project.
According to Valve itself:
"VGUI is Valve's proprietary Graphical User Interface. All Source and Steam applications use VGUI to draw windows, dialogs and menus. It also handles localization: the displaying of text in the user's preferred language. "
That's interesting, maybe if you guys do some research you can have it working in your programming language. I'll download the SDK to see if I can make it work with Java :)
http://developer.valvesoftware.com/wiki/VGUI_Documentation
Having had experience with the Source engine I know that Valve have an library called VGUI which they use for all their games and many of their tools (when in game the library sits on top of the Source renderer, when in tools it sits on top of the Windows API I believe). Although I can’t answer the question with 100% certainty I suspect that this is what they use for Steam as well (I seem to recall some Steam updates that mentioned VGUI) – I would be surprised if the new beta uses a different library.
Even if it is not using VGUI, given what I know of Valve I would think they will have written something else entirely in-house.
So, it is (almost certainly) proprietary and highly unlikely to ever be available for third party use (unless you have the funds to buy a Source engine license).
Steam only runs on Windows and predates QT for Windows, so I'd have to guess something else.
Since Steam has had the same GUI since 2003, chances are it uses some variant of MFC. It also uses an embedded Internet Explorer web browser for its Store and Community sections.
However, I can't give any guarantees about what the version currently in Beta uses. It looks quite a bit different and includs the Webkit rendering engine instead of using IE. It may use Webkit for everything rather than drawing their own GUIs.
Does this answer the question?
http://games.slashdot.org/story/10/02/25/0640233/Steam-UI-Update-Beta-Drops-IE-Rendering-For-WebKit
I am working on a new small utility desktop application but I am not really able to choose the GUI framework to use. I have worked on both JAVA,C# and C++, so language is not really a constraint. My criteria are:-
A very well designed architecture, something like QT. It's better if it follows typical C++ design methodologies.
Layout management should be easy, intuitive and not really cumbersome. I hate adjusting pixels on screen.
Its license should be open.
It should look good :)
Mentioned QT seems to comply to all your requirements. QT has "deploy everywhere" attribute, whilst Java needs no deploying at all (it depends on what is use of your utility).
Ad. 2 QT has really convenient GUI designer.
Ad. 3 LGPL. Usually it is enough.
Ad. 4 It is always matter of taste. IMO QT4 looks awesome under linux, but it's windows look'n'feel is correct at best. It's strong point is, that without additional tweaks it almost everywhere looks native.
I've been using Swing, and it works fine. NetBeans (a decent IDE by itself) even supports graphical GUI building.
It's well designed (basically
everything is done with listeners,
functions that are registered for a
certain event). It has bindings, so
you don't have to write code to set
up a value in a text field or read
it out
Layout is not perfect, but
acceptable within NetBeans. It's
WYSIWYG (almost). Look-and-feel can
be changed on the fly.
License is free. Source-code is not
available, I think.
Looks fine on Windows and Linux,
less so on OSX.
You could always try SWT. The advantages of Java with the standard L&F of supported operating systems.
Well designed. Lots of
documentation, and very easy to
develop with. (If you know Swing,
you can pick up SWT in no time.)
I believe layout managers do exist
that support SWT. I'm not positive
about this though, as I typically
don't use layout managers too much.
Uses the Eclipse Public
License. Should meet most of
your requirements.
From Wikipedia on SWT:
SWT is written in Java. To display GUI elements, the SWT implementation accesses the native GUI libraries of the operating system using JNI (Java Native Interface) in a manner that is similar to those programs written using operating system-specific APIs. Programs that call SWT are portable, but the implementation of the toolkit, despite the fact that it is written in Java, is unique for each platform.
Hope that helps you.
I'd suggest wxWidgets if you want to program in C++ or wxPython (the python language binding of wxWidgets if you know or don't mind learning Python.
Architecture is similar to QT I think.
Layout using sizers. Quite easy once you get the hang of it.
Liberal open source license.
Widgets are native on all platforms (Windows, Mac OS X, Linux).
We are planning to develop an application for monitoring and configuring our service (which is running on remote server). After long time of discussion, we decided for python as platform for our app, because we love and know python. But we don't know, what GUI toolkit preferred for our aims. We need fast (for development and running) app, whose users will be Admins, Maintainers and Account managers.
There are two GUI toolkit for python, which we know: wxPython and pyQT.
Anybody have arguments regarding pro and cons? And maybe someone knows any commercial applications, using these products (only python version of toolkits)? Links are desirable.
Thanks.
I choose wxPython after much research. The reasons were:
"wxPython in Action" book by Rappin & Dunn
The voluminous examples that come as part of the wxPython download
The number of projects that have used wxWidgets
The fact that wxPython code runs equally well on Linux, Mac OS/X and Win32
I did consider pyQT and other researchers are successfully using it. After writing many examples in all API's that I considered, I found wxPython ticked the most boxes for me.
As for Tkinter (TIX), I think it looks rather dated.
Unless you are using IronPython or Jython I would not consider using the associated native windowing APIs. For another project which is to be delivered exclusively on .Net, I plan to use WinForms after lots of great feedback from StackOverflow members.
Well, I am a fan of QT: it has a more modern look and feel. However - your choice should be based on your actual requirements. Simple trade studies are helpful for this. Make a list of what features your toolkit must have and what features would be nice to have and then weight each item appropriately. Then look at all your options (TKinter also) and then score them according to your feature list (using the weights you assigned to each feature requirement). At the end it should be evident which one is right for your project.
I've always liked Qt's "signals and slots" conceptual model, though I guess it may take a bit of learning for developers who are more used to other models of event propagation and handling. Personally, given a choice, I'd pick PyQt because of this programming aspect.
You wrote "There is two GUI toolkit for python, which we know: wxPython and pyQT." You are forgetting about the most obvious toolkit: tkinter. That's actually part of a core python distribution, no extra downloads required.
Some people don't like Tk but that's often due to ignorance. Tk is a fine choice for a cross platform toolkit. It uses native widgets on windows (and has for many years) and the latest versions of tk use themed widgets on all platforms.
i've been using wxpython for 3 years .. and now we had to switch into pyqt since qt is integrated in maya 2011 .. however , wxpython is more straight forward and you can easily start working on it and learn it from zero fast .it provides and awesome resources and decumentation . but QT provides more powerful features that you cant find in wxpython , for example ( the multi touch detection) , QT also provides good support for drawing devices like pc tablets and so on .
qt also provides a good designer that makes u create interfaces faster.
one of qt disadvantages is it's license since it's not free like wxpython
A Windows (and Mono) option for a GUI toolkit is provided by IronPython. It provides access to the Winforms and WPF libraries. For examples, see Developing with IronPython & Windows Forms, and many others.
If you want to expand the list of options, consider building a Web App instead of a (local) GUI app. You say your service runs on a remote server, so networking is part of your requirements.
Once you start down that road, Python provides a bewildering amount of options.
I want to point out two strengths that wxPython has compared to pyQt:
It uses native widgets on every supported platform. So the apps have a native look and feel. I'm aware that PyQt uses native styles, but the behavior ("the feel") is reported to be somewhat non-native especially on the Mac.
It provides a wider choice of widgets out of the box.
You should also check out PyGTK. It is similar to pyQT in programming model but does not have any licensing cost since it is LGPL. I always found it nice to work with as a developer. The main drawback over pyQT is that in some cases they take away functionality in things like file chooser dialogs in favour of simplicity for the user.