I want to write a C++ application with Qt, but build a prototype first using Python and then gradually replace the Python code with C++.
Is this the right approach, and what tools (bindings, binding generators, IDE) should I use?
Ideally, everything should be available in the Ubuntu repositories so I wouldn't have to worry about incompatible or old versions and have everything set up with a simple aptitude install.
Is there any comprehensive documentation about this process or do I have to learn every single component, and if yes, which ones?
Right now I have multiple choices to make:
Qt Creator, because of the nice auto completion and Qt integration.
Eclipse, as it offers support for both C++ and Python.
Eric (haven't used it yet)
Vim
PySide as it's working with CMake and Boost.Python, so theoretically it will make replacing python code easier.
PyQt as it's more widely used (more support) and is available as a Debian package.
Edit: As I will have to deploy the program to various computers, the C++-solution would require 1-5 files (the program and some library files if I'm linking it statically), using Python I'd have to build PyQt/PySide/SIP/whatever on every platform and explain how to install Python and everything else.
I want to write a C++ application with Qt, but build a prototype first using Python and then gradually replace the Python code with C++. Is this the right approach?
That depends on your goals. Having done both, I'd recommend you stay with Python wherever possible and reasonable. Although it takes a bit of discipline, it's very possible to write extremely large applications in Python. But, as you find hotspots and things that can be better handled in C++, you can certainly port relevant parts to C++.
Is there any comprehensive documentation about this process or do I have to learn every single component, and if yes, which ones?
Here's what I'd recommend for the various pieces:
EDITOR/IDE: Use any editor/IDE you're comfortable with, but I'd highly recommend one that supports refactoring. If you're comfortable with Eclipse, use it. If you want to mainly go the C++ route and you're not too familiar with any editors, you might be better off with QtCreator. Eric is an extremely good Python IDE with support for refactoring, unless you're going to be doing lots of C++, take a look at it. Even better, its source code is an example of good PyQt usage and practices.
PROCESS:
The quick summary:
Write your application in Python using PyQt
When identified as hotspots, convert decoupled Python classes to C++
Create bindings for those classes using SIP
Import the newly defined libraries in Python in place of their Python counterparts
Enjoy the speed boost
General details:
Write the application in Python using PyQt. Be careful to keep a good separation of concerns so that when you need to port pieces to C++ they will be separate from their dependencies. When you finally need to port something to C++, write it in C++/Qt and then create bindings for it using SIP. SIP has a good reference manual on the process, and you have all of PyQt as an example.
DEPLOYMENT:
C++ - For many applications the dependencies are sufficiently simple that it's not too difficult to create an installer using a tool like NullSoft's Installer or InnoSetup.
Python/PyQt - PyQt applications are a bit more difficult to install because of the dependency on Python and its dependence on the presence of the Qt libraries. One person documented his efforts on this post at ARSTechnica. py2exe works pretty well on Windows and should work fine. IME, freeze.py, which comes with the Python source, sometimes has problems determining which shared libraries are truly necessary and will sometimes end up creating a binary whose dependencies aren't present. Py2app can be made to work on Mac OS X.
But worse, however, is the PyQt/Qt licensing. If you are developing a commercial application, you need to have a commercial PyQt (and Qt) license and make sure to prevent the users from easily modifying the source or otherwise writing code against the PyQt/Qt API because of licensing restrictions. Because of that, the PyQt author created a tool called VendorId (although it has a Python license). Within VendorId is a tool called SIB that can be used to create an executable which depends only on the Python interpreter. But, if you're going to go this far, you might want to install a custom Python along with your application.
DISCLAIMER: I haven't used PySide at all, so I'm not sure how it compares to PyQt. Also, note the following warning on their website:
PySide is a work in progress and is not yet suited for application development requiring production-level stability.
But, on a good note, they intend, at least for the initial release to "maintain API compatibility with PyQt." So, aside from the C++ bindings, you could easily switch between the two later.
If you are just learning Qt and want to leverage the speed of prototyping that Python gives you, then I would recommend you make a sample project using PyQt. As you said, there is a debian package, so you are just a simple apt-get away from making your first application.
I personally use gVim as my Python/Qt editor, but you can really use any Python-friendly editor without much trouble. I liked WingIDE and they have auto-complete for Qt but once you sip from the vim kool-aid it's hard to switch.
I would say that PySide is 95%+ compatible with PyQt and the LPGL license is nice, but if you are just trying to prototype your first Qt app, then I don't think there is a real reason to use PySide. Although, I do like the PySide docs better, you can also just use them and replace all the library references with PyQt.
Depending on the complexity of the application you are building, it might be better off to just start from scratch with a C++ version than to try to do a bunch SIP refactoring black magic. Once you have a solid grasp of the Qt framework, you should be able to switch between the C++ and Python bindings pretty effortlessly.
I would draw UI mockups before starting to code prototypes. Here are some benefits:
Quicker than coding prototypes as there is no programming involved
Quickly fill widgets, such as tables and trees, with data
Add descriptions and notes to your screens
Easily integrate mockups into specification documents without having to capture screens
Validate UI design concepts before implementing
There are a lot of tools that can help you do that, but if you are going to use Qt, MockupUI may be a good choice as it renders Qt widgets with native styles for Windows 7,8 or 10 which makes your mockup look more realistic.
Related
I am trying to make a decision for what to use to continue developing my application.
I have some experience with C++ in the MFC Document/View architecture and have found it very frustrating. I felt I was always fighting the framework and also felt that my application didn't fit the doc/view architecture. (I now know that it probably would have fit, if I had known how to structure it that way.)
So I decided to try Python and ended up using tkinter. That was easier to learn and didn't have as many frustrations. (Though it had a few different new ones.) I think I learned a bit more about object orientation and setting up classes along the way. But am now concerned about the fact that it is an interpreted language and much slower than C++ for my purpose.
So I have been wanting to go back to C++ but not MFC. I have read a little about wxWidgets and Qt.
So here are the things I want to know:
For wxWidgets and Qt, do they use a resource editor for setting up the layout of a GUI or directly expose the code the way Python and tkinter do.
Do either wxWidgets or Qt produce any interpreted code or is everything ultimately compiled into native machine code?
Thanks
1. Both
Qt and wxWidgets have GUI builders available. In the case of Qt, an XML file is produced that is parsed by the uic to produce C++ code. wxWidgets has several designers available, they will differ between them, but I'll be surprised if they don't all follow the same pattern.
However many people, myself included, choose to hand code - there is no requirement to use the UI designers. Be careful using the term 'resource editor', as Qt has a Resource Editor and it is not used for designing GUIs.
2. Both
Qt and wxWidgets are not just GUI frameworks - they're cross-platform toolkits. In view of this, Qt is pushing for a clear separation between GUI and backend by using QtQuick and the QML language for GUI development. Qt5 still has full support for C++ widget-based development of course. wxWidgets has no equivalent that I'm aware of.
Also, if you liked Python but not tkinter, both Qt and wxWidgets have Python bindings.
Is it a good idea to use gtkmm gui toolkit for some desktop client application ?
Is this toolkit stable and is there enough documentation online ?
I used gtkmm to write professional applications and yes you can use it for real world software development.
But I also used C/GTK+ and C++/Qt and my opinion is that using Gtkmm you have the feeling that the original toolkit was meant to be used in C and the porting to C++ is ok but in many cases you feel that C++ features could have been used better.
For Comparison:
If you have to choose between Gtk and Gtkmm go for Gtkmm even though you might find yourself stuck in some not well documented or supported function. Eventually you always manage to find a solution (you can check the source code) and c++ is way better then c.
If you have to choose between Gtkmm and Qt, go for Qt. There is a HUGE gap between the two. Not only in the toolkit itself but in the documentation and all the other classes that you need when writing an application.
I started two month ago with gtkmm. I actually port a tcl/tk application and it feels very hard for my to get the things run. The only useful documentation I found is the https://developer.gnome.org/gtkmm-tutorial/3.4/
But many things described in the manual are not working! I actually run into trouble while overriding signal handlers which should work but didn't. Maybe you will take a look in gtkmm-list#gnome.org to find out what kind of problems yo will maybe run in :-)
The docs derived from the doxygen input seems useless for me, because the functions are mostly not described and the parameter names or often not very clear to me.
In comparison to tcl/tk the interface looks inconsistent. Sometimes a parameter must be provided by a text, sometimes by a pointer and sometimes by the native value itself. Especially the menus are very "mysterious" with the string based configuration. The need of having parameters as text is very unhandy! You have to convert the parameter with ostrstream into a text and parse the parameters sometimes yourself from text to real values.
I decided to give gtk+ a chance is the existence of the c++ interface. I thought it would be helpful to get the errors in compile time and not while running the app like with tcl/tk. But this is not the always true with gtkmm. With gtkmm you are also able to run into run time errors because all string parameters will be parsed during run time! This makes the things error prone!
Maybe I will start again and give Qt a chance. But a first view on it shows, that this seems not really better :-)
Writing a gui application still is a really annoying job!
gtkmm is a official supported binding of GTK (gtk.org/language-bindings.php).
"inkscape" and "ardour" are notable applications written in gtkmm
The bindings that are official GNOME Bindings follow the GNOME release schedule which guarantees API stability and time-based releases.
If you want to write your Application in C, go with GTK+ (and the GLib).
You can find a link to the documentation at http://www.gtkmm.org/ (https://developer.gnome.org/gtkmm-tutorial/).
With Glade (and ie. PyGTK) you could rapid prototype your application.
Building a GUI with Glade is easy and the resulting UI is a xml file, that is not bound to a programming language.
For my school project, I would like to build a gui that someone else can use to create a gui. Upon some research I saw lot of gui builders but didn't see anything along the lines of what I am looking for.
But then I did find a tutorial using C# on here
I rather create this gui editor for linux environment.
Any suggestions to where I should start? what tools I can use? Any links to any tutorials?
Any help/direction would be greatly appreciated.
P.S. I would like to add that it only needs to be very simple. like few text input fields and some button type fields that user can arrange in the order desired.
I would recommend that you not try to build your own GUI builder. It is a daunting task that you will not be able to accomplish as a school project. C++ is fully-compiled, which means that it lacks almost every feature that enables people to build meta-tools (like GUI editors) for it. This mainly has to do with the fact that C++ does not have runtime reflection (natively, anyway). Beyond that, there is no "one GUI toolkit and/or paradigm to rule them all." This makes your problem incredibly difficult to deal with.
So: I would recommend Qt, because it works on a ton of platforms, is easy to use and is just plain awesome. You could also look at the billions of other GUI toolkits like Gtk+, Tk, FLTK, YAAF, GLUI, dlib, CLX...
I'm aware that this does not actually answer the question. However, I do not think that the author is aware of how incredibly difficult the task he has set in front of himself is.
I would recommend starting by implementing it like an interpreter. Start with a very simple command line tool that takes commands like window(300, 400, "window1") and button(50,100, "button1") etc and output the code (native or whatever other GUI code you want), to a file. The goal should be to output a file that can be run and show the GUI that was designed. Once you have that, build a GUI that uses the command line functions as a back-end.
I don't have any exact links to this, but here's an example of what you could do. Gtk has the option of loading a GUI by using a class called GtkBuilder. Glade (the usual Gtk gui editor) has support for outputting it's result as an XML file that the GtkBuilder class then reads.
It would be possible for your program to output an equivalently formed XML file that GtkBuilder could read.
I have no clue as to how difficult it would be to target that XML though.
You should use GTK+ or Qt if you are targeting the linux environment. I think the first step is to learn how to program gui, which takes some time considering you are writing c/c++ code wich is different from higher level languages. Don't you think learning to code gui programs and writing a gui builder at the same time is a little bit too much.? First you should master the basics about gui and then go on to harder projects.
Here's a link to an excellent book on gtk. (Foundations of gtk+ development - Andrew Krause)
http://books.google.com/books?id=L1BZZYRrqSgC&printsec=frontcover&dq=foundations+krause&hl=es&cd=1#v=onepage&q=&f=false
And here's a great tutorial/cookbook for gtk+.
http://zetcode.com/tutorials/gtktutorial/
The official documentation is on library.gnome.org
My final advice is learn one thing at a time.
Is Qt an interesting platform for business apps development, outside of Nokia phones ?
Why ? Strong points ?
Thanks
I like Qt because:
Very well-designed framework, e.g. signal-slot, model-view, graphics view/scene/item/proxy, painter/paint device/paint engine..., too many to be listed here!
Excellent documentation!
Cross platform language/API, as well as tools like UI designer, creator, and so on.
Rich features, e.g. graphics framework, network library, database engine, and so on.
Active community, and active development.
There should be more. If you have ever used it, you'll find it's easy to build your framework upon Qt.
I didn't have any complain to Qt. If I have to say at least one disadvantage here, "convention". You must adopt the convention of Qt, e.g. You have to use moc to make the meta object of your objects, and it's easier for developers to use Qt's vector, list, auto_ptr than STL, tr1. But I never found any issue caused by that. On the contrary, it works very well.
In my opinion, Qt is the state-of-the-art C++ framework in this modern world!
P.S. There are a lot of commercial applications built on Qt. You can find it under Qt's official website. But I'd like add one more here: Perforce, one of the top commercial source code management tools, built its client tool on Qt for Windows/Linux/Mac.
yes it is .. just look at kde apps :)
or see more applications made by qt
and it has alot of bindings in many languages
Documentation
cross-Platform IDE
further reading
may be this is not so related to the question ... but my first deal with qt was just great starting from their well organized Documentation to their great widgets
the GraphicsView is just ammazing ! :)
It's about the only current/modern C++ gui library on Windows.
MFC is so old you have to write comments in Latin
WTL would be nice if they had finished it before abandoning it.
Winforms/WPF + managed C++/CLR - all the fun of several incompatible new technologies at once.
Bad points:
To fit on lots of platforms they have invented their own solutions to things that are now in the STL/Boost
The signal/slot mechanism - tricky to debug and silently fails (with no error) with simple typos.
Although everything is possible it's sometimes a lot of effort to do simple things (they do love MVC) compared to Winforms.
Qt is simple
Qt is powerful
Qt is NATIVELY-CROSS-PLATFORM
Qt is REALLY-CROSS-PLATFORM
Qt is comprehensive (but the Media side of it still needs to grow)
Qt doesn't require Garbage Collection, but it embeds a GREAT model of memory management that makes you forget about memory deallocation
Qt is solid
Qt is modern
Qt proposes some new paradigm of programming that are really good (Signals-Slots)
Qt runs a lot of VERY successful software: (Skype, Google Earth...)
Are those points strong enough?
Maybe you have heard about Google Earth which happens to be programmed in Qt too.
That aside, I like Qt for my in-house development because it
is very well supported and documented,
allows me to write simple and decent-looking apps that are
works cross-platform for Windows and Linux with little effort, and
contains nice to have components for database access, regexps, guis, xml, ...
I also use the Qwt widgets for easy real-time plotting on top of Qt.
I really dont understand whats the point in underestimating tools/frameworks which makes things easy for programmers. Qt is too good for GUI development, I would say its much better than any current existing crossplatform app development suite.
So many advantages, I have been using it for more than three years now for a product to be deployed in Linux/Win environments. The app is thread intensive and initially we had a tough time using pthreads and its conterpart for windows. Then we switched to Qt(and QThreads eventually) and things were a breeze...
Backed by active development, a highly helpful and supportive community along with excellent documentation, training, certification programs, videos, forums... its easy, fast and effective to develop in Qt. You should see the video which they create a web browser in just five mins!
Its really 'cross platform', and it doesnt have a software wrapper(like Java does) to enable this which makes it faster. Cmon, we all know java apps have buttons which takes a second to respond to even a simple 'click'.
I hope Qt will someday do a take on Java. :D
after all, 350000 developers cant be wrong when they chose Qt.
Pixar uses Qt (or at least, used, as of 2005) internally for certain parts of their tool suite (called "Marionette" in the marketing) collectively called Menv, ("men-vee" for Modelling ENVironment)---at least for their lighting sub-tool Lumos.
I have a significant codebase written in MFC and am tasked with creating a port for Mac OS X. I know that I'm going to have to roll up my sleeves at some point and do alot of grunt work to get everything working correctly, but are there any tools out there that might get me partway?
I'm working on one.
From the GUI point of view, the new version of AppMaker is based around an import/generate model. Most of commercial work I've done with AppMaker has been the other way, porting Macintosh applications to Windows. However, there's no reason why the same principles can't be applied in reverse.
AppMaker v2 had a very good importer for PowerPlant UI resources and traditional Mac dialogs. As it is only able to run on Classic, that code base has been discarded (you really don't want to know) and the final generator languge I wrote for AppMaker v2 is an XML exporter which dumps the entire object model to an extended XAML.
I already have a XAML UI generator and am currently working on a Cocoa xib generator - one of the reasons for going to WWDC in June. The focus at this time is on import/generator suites before returning my attention to a GUI editor.
I wrote PP2MFC to allow PowerPlant applications to be compiled for Windows - a cross-platform solution needed because no other framework or cross-platform tool at the time (1997) would perform well enough for the hardware requirements. I've since discussed an opposite program with someone I could chase up and I'm sure an MFC portability layer could be created to map to Cocoa objects. Whilst many developers have a poor opinion of MFC's message-map architecture, the heavily macro-based API sits on top of a reasonably clean OO framework.
This is the kind of project where you need to think about long-term maintainability - do you want something which ends up as large chunks of MFC code working with Cocoa or do you want to migrate to an idiomatic Cocoa program.
Any further discussion should probably be taken off SO - contact me at dent at oofile.com.au but I'm happy to debate technicalities and feasibility on here. The combination of code generation and skinny framework adaptor layers works better than most people expect.
Honestly, the models are so different that I suspect you're going to need to do a nearly complete re-code at least of most of the UI parts.
No, Such a tool would be pretty much impossible to write.
MFC and Cocoa are such fundamentally different platforms there is no easy way to convert between the two.
Depending on how you've written your applications, you will either need to write the GUI portion of your code or even the whole codebase.