Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I'm still a newbie programmer and I am looking at some garbage collected languages that are suited for writing desktop GUI applications. The language must be available on Windows, OSX and Linux. I say "garbage collected" instead of high level since a language like D isn't quite high level (imo) but is garbage collected, compiles to native code and gives near C++ performance. However the most developed GUI toolkit for D is DWT, wich is a port of SWT. The few SWT apps I have used look ugly on every platform. If D had a Qt binding that would be great, but the only thing I could find was QtD which seems to be a dead project.
Languages I am aware of:
Java
Python
D
I'd rather not use C# with Mono and syntax-wise I prefer languages similar to C/C++.
Are there any others, and what would you suggest?
EDIT: The language doesn't have to compile to native code, compiling to bytecode and running in a VM is just fine.
Every programming language that I know, that has a compiler to the native code, uses some C or C++ GUI toolkit for GUI. SWT/DWT uses GTK on Linux/Unix for an example. If SWT applications look ugly to you, then either you did not configure the GTK theme or you did something with the look&feel initialisation. SWT applications look exactly the same as any "native" GUI application.
Even though I am a former C++ programmer, and no matter how I dislike it now, I would still recommend C++ to you because you asked for programming language with compiler that compiles to native binary. Additional requirement you specified is the garbage collector. Use the libgc in your C++ applications, and that is all you need. More about it here: http://developers.sun.com/solaris/articles/libgc.html .
In the field of programming languages with native compilers I am more/less settled with D, but unfortunately, D has no actively-developed GUI ToolKit as we speak. That will be solved soon, but until then, use C++.
What about vala?
Vala is an object-oriented programming language with a self-hosting
compiler that generates C code and uses the GObject system. Vala is
syntactically similar to C# and includes useful language features like
anonymous functions, signals, properties, generics, assisted memory
management, exception handling, type inference, and foreach
statements.2 It is being developed by Jürg Billeter and Raffaele
Sandrini. It aims to bring modern language features to C[clarification
needed][peacock term], with no added runtime needs and with little
overhead, by targeting the GObject object system. Rather than being
compiled directly to assembly or to another intermediate language,
Vala is source-to-source compiled to C which is then compiled with a
platform's standard C compiler, such as gcc.
Go there is as well some bindings for GTK, FLTK and WALK. Check out this thread.
On Java you can still modify the Look and Feel of your UI. Java gets also a port of Qt called Qt Jambi.
And then there are very stable languages like Free Pascal/Lazarus and PureBasic that work well (same source code compiles on all platforms) on Win, OS X and Linux
Real Studio uses reference counting for automated memory management. It's not garbage collection, but better in many ways.
And of course Real Studio runs on Windows, OS X and Linux and can create apps for Windows, OS X, Linux and the web.
You could use Qt Quick. It has a declarative UI language called QML and it's scriptable with javascript.
Related
I would want to compile existing software into presentation that can later be run on different architectures (and OS).
For that I need a (byte)code that can be easily run/emulated on another arch/OS (LLVM IR? Some RISC assemby?)
Some random ideas:
Compiling into JVM bytecode and running with java. Too restricting? C-compilers available?
MS CIL. C-Compilers available?
LLVM? Can Intermediate representation be run later?
Compiling into RISC arch such as MMIX. What about system calls?
Then there is the system call mapping thing, but e.g. BSD have system call translation layers.
Are there any already working systems that compile C/C++ into something that can later be run with an interpreter on another architecture?
Edit
Could I compile existing unix software into not-so-lowlevel binary, which could be "emulated" more easily than running full x86 emulator? Something more like JVM than XEN HVM.
There are several C to JVM compilers listed on Wikipedia's JVM page. I've never tried any of them, but they sound like an interesting exercise to build.
Because of its close association with the Java language, the JVM performs the strict runtime checks mandated by the Java specification. That requires C to bytecode compilers to provide their own "lax machine abstraction", for instance producing compiled code that uses a Java array to represent main memory (so pointers can be compiled to integers), and linking the C library to a centralized Java class that emulates system calls. Most or all of the compilers listed below use a similar approach.
C compiled to LLVM bit code is not platform independent. Have a look at Google portable native client, they are trying to address that.
Adobe has alchemy which will let you compile C to flash.
There are C to Java or even JavaScript compilers. However, due to differences in memory management, they aren't very usable.
Web Assembly is trying to address that now by creating a standard bytecode format for the web, but unlike the JVM bytecode, Web Assembly is more low level, working at the abstraction level of C/C++, and not Java, so it's more like what's typically called an "assembly language", which is what C/C++ code is normally compiled to.
LLVM is not a good solution for this problem. As beautiful as LLVM IR is, it is by no means machine independent, nor was it intended to be. It is very easy, and indeed necessary in some languages, to generate target dependent LLVM IR: sizeof(void*), for example, will be 4 or 8 or whatever when compiled into IR.
LLVM also does nothing to provide OS independence.
One interesting possibility might be QEMU. You could compile a program for a particular architecture and then use QEMU user space emulation to run it on different architectures. Unfortunately, this might solve the target machine problem, but doesn't solve the OS problem: QEMU Linux user mode emulation only works on Linux systems.
JVM is probably your best bet for both target and OS independence if you want to distribute binaries.
As Ankur mentions, C++/CLI may be a solution. You can use Mono to run it on Linux, as long as it has no native bits. But unless you already have a code base you are trying to port at minimal cost, maybe using it would be counter productive. If it makes sense in your situation, you should go with Java or C#.
Most people who go with C++ do it for performance reasons, but unless you play with very low level stuff, you'll be done coding earlier in a higher level language. This in turn gives you the time to optimize so that by the time you would have been done in C++, you'll have an even faster version in whatever higher level language you choose to use.
The real problem is that C and C++ are not architecture independent languages. You can write things that are reasonably portable in them, but the compiler also hardcodes aspects of the machine via your code. Think about, for example, sizeof(long). Also, as Richard mentions, there's no OS independence. So unless the libraries you use happen to have the same conventions and exist on multiple platforms then it you wouldn't be able to run the application.
Your best bet would be to write your code in a more portable language, or provide binaries for the platforms you care about.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
Can someone suggest what's the best uses for those libraries today? Is it just GUI, or do they have database, XML, networking, threading, etc support too?
I was reading about them, and considered starting to learning/using one of them.
What is the most common one? What's the difference between them? Why would you choose one over the other?
As you seem to primarily target Linux, then the choice mostly depends on the programming language you want to use.
If you code in C, then obviously go for GTK+
If you code in C++, go for Qt, otherwise you will need Gtkmm (a C++ wrapper over GTK+)
If you code in Python, both GTK+ and Qt have bindings for the language: see PyGtk, PyQt and PySide (the one launched by Nokia themselves).
If you code in Java, Qt is no more a viable option imho as Nokia discontinued Qt Jambi (the Java bindings for Qt).
Also, Qt is more top-notch regarding its scenegraph QGraphicsScene API, its scripting engine built over Javascript Core (the engine powering WebKit), its state machine and animations framework, and the declarative UI.
GTK+ doesn't offer that much although you can use Clutter alongside with it.
If you're specifically looking into DB, XML (GTK+ has a parser for a subset of XML) and threading (GTK+ has GLib) features then Qt will offer all that in QtSql, QtXml and QtConcurrent.
All in all, I would say Qt is a sure choice. But GTK+ is very capable as well.
I'm not sure you will get a crystal clear answer for your question, which explains why some people keep preferring Gnome over KDE or vice-versa. Choose what works best for you.
PS: I you plan to also target Symbian, then go for Qt.
EDIT: Something that is also great with Qt is QtWebView: it brings Chromium into your Qt application to display web content. Others are embedding web content into their application using for instance Awesomium or Berkelium.
I've used GTK+, QT and wxWidgets before. Here's a brief summary:
For my first cross platform UI project I decided to go for wxWidgets mainly because at the time the license wasn't as restrictive as QT's (QT was GPL and only for Linux) and it had platform specific UI (unlike GTK). The project worked out well but there were quite a few glitches getting it to compile and run properly in other platforms - sometimes some events were fired up differently and such. Also GDI in wxWidgets was pretty slow.
Next I used GTK for a different project in python. For this I used the python bindings and everything worked out more or less smoothly. I didn't quite like the fact that the UI didn't look native on Windows and Mac and also when you launch a GTK+ app it always debug outputs loads of CRITICAL warnings which seem fine to ignore. :S
Finally, I did a very simple QT project now that Nokia has acquired it and was brilliant. The best of the three. First off, if you're not an old schooler who prefers VI or Emacs, QtCreator is brilliant. I really love VI and used it for years but I much prefer QtCreator for C++ QT projects. Regarding the library I also liked a lot the documentation and the APIs provided. QT has a concept of slots and signals which introduce new C++ keywords and a preprocessor. Basically, after reading a tutorial you'll get it easily and will start to love it. I'm now doing iPhone dev and it does feel a bit like Cocoa's/Interface Builder's UI paradigm.
Summary: I'd go for QT hands down. The license is pretty good and the SDK and documentation really nice.
I have never used GTK, but from my personal experience using Qt:
It is much more than a simple GUI. It's a whole application framework. I used to think of it as the Java libraries for C++. It provides all you mention -- database, XML, networking and threading, and more. It also provides things such as containers and iterators, and counterparts to a number of boost libraries.
The thing that impressed me most when starting to use Qt was the extremely extensive documentation. You get a program called Qt Assistant, which provides fully indexed and searchable API documentation on your desktop, as well as numerous code examples and tutorials. I found it made a big difference in searching the web each time for API info. Very quick access when you need to remember a method signature.
I am not sure which is most common; that's probably hard to measure accurately. They're certainly both popular. As Gnome is the default desktop of Ubuntu, and Gnome sits on top of GTK, it obviously has widespread usage. Of course, KDE is very popular as well. Nokia is heavily pushing Qt in the mobile space -- their Maemo OS, used on the new N900 for example, is soon to switch to Qt as the default toolkit (currently it is GTK.) I believe Qt will also soon become the default toolkit for Symbian OS.
I have not used Qt Creator, but I have heard many good things about it. It is a C++ IDE with obvious heavy integration with Qt. It also has fake vim emulation which is always nice if you like that kind of thing!
Qt uses qmake for build configuration. I found this much nicer than having to write your own makefiles. I do not know what GTK uses for building.
A couple of things I found a bit offputting with Qt at first was its big uses of preprocessor macros. The signal/slots system provides a nice mechanism for event/message passing in your application, but it does feel a bit like magic that may not be easily portable to another toolkit if you ever want to. Also, the moc (meta-object compiler), while I'm not entirely sure what it does, also feels a bit too much like magic going on behind the scenes.
All in all, though, I would recommend Qt, particularly if you are learning. It has really amazing documentation and a nice IDE, and busy forums. You'll be able to build C++ apps very rapidly with it, particularly with the QML coming in 4.7.
It probably depends on what you want to do. I would recommend Qt, because it's more than GUI, it has nice Python bindings (so does Gtk), and GUI libraries themselves are (subjectively speaking) more pleasant then Gtk.
Gtk is on the other hand more common in linux world, so you can probably get more help on the web. Reason for widespread of Gtk probably has more to do with Gnome and Ubuntu, rather then technical merits, but if you want you software to blend nicely with those two, you'll achieve that more easily with Gtk.
Qt for one sure has solid DB, network, threading support etc... It does a lot more then just cross-platform GUI (and it does most of it quite well).
I'd recommend it over GTK+.
Qt. It's not only object oriented, is "good" object oriented.
It's based on a "subset" of C++ that doesn't rely on the obscurity of C++ (but you are allowed to stick with them, if you fancy masochism ;) ).
It has a strong momentum now that Nokia bought it (actually Nokia did ~2/3 years ago). It's going to be in all Nokia AND Intel mobile devices (smartphones, netbooks, tablets).
It's the backbone of KDE, so it's very mature, but it's designed in a very flexible way, that makes it possible to support TODAY all the latest "cool stuff" that a more-then-just-GUI framework should have.
Go for it.
Just adding QT advantages to other answers.. QT has great documentation, its own IDE & GUI creator and enhances C++ with some new concepts like slots/signals (basically events).
I am not a GTK developer, so I can't compare those to the GTK world :(
It also looks like Nokia is about to use Qt everywhere, like on Maemo
If you want your app to run on iOS, Android, Blackberry, other mobile platforms, Windows, Mac OSX, and Linux, use Qt.
qt-project.org
I will make a desktop application. I searched on web which one is better. Can someone say positive and negative sides of these components.
I can add some information about QT:
QT is a well designed, portable library that covers nearly everything you'll need for a desktop application. QT covers GUI, networking, SQL, Graphics and more.
Pros:
very extensive library
high performance
portable
Cons:
It's C++
special preprocessor / make tool needed.
Setting up a QT compile environment is a little bit more difficult than setting up a C++ compile environment. C++ is - especially if you are not used to it - very difficult and the learning curve is steep. QT helps alot with appropriate helper classes (QPointer, ...) and library magic (QObjects freeing children, ...) in the background. There are bindings to other languages as well. Just to mention a few - Jambi is a binding for Java and there's a binding for python as well.
For your decision consider the following things
which programming language do you know best
which libray reduces your amout of work for this application the most
how much performance do you REALLY need. C++ code can be very fast, but there's no reason to work with manual memory management and pointers if you don't need the performance.
which library offers you the look and feel you want to have for your desktop application
If you need portability: Do you want to "compile once run everywhere" (Java) or do you want to "run your app everywhere once you compiled it for this plattform" (QT)
Here's the link to QT-Jambi Wiki: http://qt.gitorious.org/qt-jambi/pages/Home. According to Nokia: "Qt Jambi is the Qt GUI toolkit for Java developers"
Qt is the best cross platform GUI framework at the moment. It renders the widgets with a native look on each platform and it has a very easy to use API.
Using Qt doesn't mean that you have to use C++. You can program Qt in Java (Qt Jambi) or Python (PyQt) for instance.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
I was wondering which one should I consider if I need the software to be used on both platforms, WIN and Linux and why?
Packaging GTK and its dependencies on Windows is a full-time project in itself. Qt is much more easily distributed since it has no dependencies that do not come with Windows.
Qt has been cross platform from the start. GTK has not always been cross platform. Such fundamental decisions shape the overall design, and should be made before any code is written in my opinion.
I would comment more, but I'd be drifting into speculation, the above two things I know for certain.
Both are good toolkits that have their advantages and disadvantages.
One difference is the implementation language. Qt is in C++, and GTK+ is in C. However GTK+ has bindings for many, many other languages (perl, python, C++, .NET, etc) so it's not a huge issue.
An Advantage of Qt is that it offers a bit broader range of functionality built in (xml, database access, network programming, openGL, etc). GTK+ has basically all of these things within its orbit (e.g. libxml2, librsvg, libsoup, libgda, etc), but they're not as much of a single coherent package as Qt is.
My personal recommendation is to use gtkmm, the C++ bindings for GTK+. It offers a more comfortable object-oriented language to program in, and it provides nearly the same native performance as using GTK+ from C. (Disclaimer: I contribute to gtkmm).
GTK+ you can use almost in all programming languages, in C++ (using gtkmm) in C (gtk+) in C# (with Gtk#) in Python (PyGtk). Behind GTK you have Mono Framework which is great implementation of .NET Framework for cross platform purposes. If you want to use Gtk# you have great IDE (MonoDevelop) with a very powerful gui designer. You can take a look at www.mono-project.org. But still depends what do you want to build, you are looking just gui toolkit, or the entire framework? And the logic behind signals/slots are the same in Gtk+ and Qt, but if you are using Gtk# they are transformed in the delegates/events paradigm.
my $0.02:
I've used Qt off and on for the last 4 years, and it's hands-down my favorite toolkit of anything I've tried (Win32, MFC, Borland, Java, GTK). I used GTK for a few weeks to try it out, and didn't like it. Mostly that was because I think it's awkward to use C instead of C++ for GUI apps on a PC... I do embedded work too, and I'd never use C++ on an 8051, but for a big GUI app I much prefer it. If you're going to try GTK, I'd suggest looking in to GTKmm, although I've never used it myself.
You might also consider wxWidgets. I have never used any of them but when I was looking over the cross-platform toolkits it was the one I had decided to try.
They are both fine toolkits. I'd base my decision on the licensing. Qt requires that you pay for a license if you are using it in a commercial product wheras GTK does not.
Three additional points in favor of Qt:
Your project does not have to be GPL; there are many other open-source licenses available in the Qt GPL Exception, including BSD and LGPL.
Qt's default theme on Windows does a much better job of blending in than GTK's Wimp theme.
If you want to support Macs later, you'll have a much easier time with Qt.
I would prefer Qt. As today, Qt is Open-source and free under more permissive, LGPL license.
Qt is better ported for Windows and looks more native than GTK. Gimp on windows, for example, looks very strange, because most of its dialogs are not Windows dialogs. Qt can use native Window dialogs like Open/Save which makes it feel better as a framework. And yes, Qt is a framework, not only a GUI Widget. No, I am not advertising Qt here, as Qt have some strangeness for a windows user from development point of view, for example, Qt is Layout based while MFC / .NET are anchor based and Qt's Layout managers are sometimes strange. But if I have to choose between both GTK and Qt, I will select Qt. Also, now, Qt comes with very good IDE, Qt Creator, which is my default C/C++ IDE for all types of projects now (as Qt Creator can be used as such).
Qt 5.0 has won the war.
I'm not a huge fan of C++ (I prefer plain old C), but I must admit that the Qt framework is amazing.
Try to write a GUI program with GTK that runs on OSX, Linux, Windows (and soon iOS and Android) with native look-and-feel... Good luck !
I recommend to use Qt because:
It's cross-platform and and covers wide range of operating systems (including mobile)
It is opensource and has a fast speed in getting better
It has the a nice GUI designer and a very capable IDE (Qt Creator)
The API design is excellent and easy to use
It has a great documentation which is easy to read
It has the Qt translation system which enables you to have a multilingual app
The GUI layout system where the widgets resize themselves according to a layout makes everything much easier
The QML gives you the power to create fantastic GUI with great graphics and animations
It has great support for networking and connectivity(socket, SSL, www, IPC, ...)
It has QTestLib for testing the code
It has many language binding if you don't want to use C++
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
Joel Spolsky praised native-code versions of programs that have no dependencies on runtimes.
What native-code compilers are available for functional languages?
This post is really quite unclear. The question appears to be "Are there compilers for functional languages which can produce native executables without the need to install additional software?"
The answer, generally, is yes. For example, Haskell has a compiler that produces native binaries. Many other functional languages have similar compilers.
Yeah, also:
ocamlc is the bytecode compiler, and ocamlopt is the native code compiler.
GCL compiles Common Lisp to native binaries.
There isn't anything for F# since, for what I am aware of, .NET doesn't have a native compiler, like Joel mentions. Actually, CSML can be used to call C# from ocaml, uhh, not sure if you can compile this down to native code --it doesn't seem likely-- although the documentation alludes to it, yet it is very incomplete.
A lot of functional languages are compiled just like any other language.
For example in Clojure:
The reader translates the source code text into a data structure that represents the program (an s-expression)
If required, macros are then applied to transform the code
The Clojure compiler then translates the code into Java bytecode - this is the same machine-portable format used by Java, Scala and other JVM languages
Finally, the JIT compiler in the JVM converts the bytecode to native machine code, possibly performing various optimisations on the fly. This is the code that then gets directly executed on whatever platform it is running.
One interesting point is that all this happens dynamically, i.e. at any point during program execution you can write new source code, pass it through the reader and various compilation steps and run the new compiled native code without having to restart the program. This is important as it enables interactive development at the REPL while still providing the benefits of fully compiled code.
PLT Scheme has got a JIT compiler.
Stalin is a Scheme compiler which does ridiculously aggressive optimisation.
All Common Lisp implementations that I know of except CLISP compile to native code. (Whether one ought to consider CL a functional language depends on what is meant by the term “functional”, however.)
MLton is a highly optimising compiler for Standard ML.
Functional languages can be and have for some time been compiled very effectively. There is no difference to imperative languages in this regard.