Is it possible to step into Qt sources, e.g. qmainwindow.cpp, in Qt Creator? At the moment I'm seeing the disassembly, but it would be nice to see the sources instead.
Of course! But you might have to first:
go to $QT_HOME/qt
run ./configure with the -debug or -debug-and-release flag (many other flags here)
run "make"
wait a couple of hours while things build
Download the Source code itself.
Create your application with including all the required files (for e.g qmainwindow.h,qmainwindow.cpp,...) directly. Run your application. Step into the desired files while debugging.. I haven't tried this way but this should work.
Also you have to include all the desired files. For e.g QMainWindow is derived from QWidget. QWidget is derived from QObject. So you need to include the qwidget.cpp, qwidget.h for QWidget and qobject.cpp, qobject.h for QObject. Similarly you have to include all the necessary files that might be required.
What you are actually doing is, instead of linking the Qt libraries (*.dll and *.lib), you are including the required files directly. That's all.
Remember with the Qt libraries linked, you will not able to step into the files that are all built into the libraries.. So, inclusion of the desired files will help you.
Hope it helps.
You don't say what paltform, but on windows you also have to tell Visual Studio where the sources are. See options->vs projects and directoriers->source code
Related
So when I create a new Qt project inside Qt Creator I'm only asked for some simple details like location of the project, build targets, the main window class name (along with header, source and form file) and at the enda choice to add it to version control.
After I create the project I'm only given the qt core and gui modules. My question is how do I add other modules (such as network or opengl). I've looked and looked, yet I cannot find anything on how to add other Qt modules easily. I know I can edit the .pro file, but unfortunately I don't know all the modules in Qt, nevermind the name I'm supposed to put there. Adding external libraries is easy, but how come there's no (obvious) option to add Qt libraries?
Help would be much appreciated ^_^ Thanks!
Oh yeah... I'm running Arch Linux if that's any help.
Edit your .pro file. It should has one line like this:
QT += core gui
Append the desired modules in this line. To get the module's names, just remove the "Qt" part in this list. (e.g. QtSql turns "sql")
I can't find that either.
It seems that in older versions of the "New project" wizard you used to be able to specify which modules you wanted to use, but even then you were not able to alter your choice later. And this seems gone now, so your only choice is to manually edit the .pro file.
As others have pointed out, you simply #include the module you want in the source and add the name of the module in the .pro file to the QT variable.
However the actual documentation you need which no one else has mentioned is the qmake Project Files page. qmake is very powerful and it's well worth getting familiar with how it works and I think that's why they don't provide a complete GUI for it, as it can handle some very complex scenarios.
You have to read the documentation to add the modules.
Frankly speaking, I never really felt like that there needs to be a GUI for that.
I am looking for a way to create a minimal static build of Qt 5.1. By minimal, I mean a build with only the basic set of widget classes available (including 2D graphics acceleration through an OpenGL canvas/widget). I am aiming for a static build on Windows 7 32-bit using MinGW-builds GCC 4.8.1 as well as their bundle of MSYS and tools.
I have downloaded the entire source tree, and have met some problems with compiling due to the dependency of packages such as OpenSSL and ICU (the latest OpenSSL did not compile). I wanted to see, if I could avoid dependencies of these packages and, at the same time, achieve a minimal static build of Qt 5.1 so my final executable is not gigantic in size.
I took a look at this list:
http://download.qt-project.org/official_releases/qt/5.1/5.1.0/submodules/.
Q1: Which of these modules, do I need to select to have a basic Qt build without all the fancy stuff?
Q2: Are these modules interdependent on each other in some way (I assume they are all dependent on "qtbase")?
Q3: Do I use the names from that list, (for example: "qtxmlpatterns", "qtx11extras", "qtwebkit", etc.), to deselect them in the configuration of my Qt build?
It would also be nice, with an explanation of the various submodules of Qt 5? If someone could point to any links or docs with illuminating words on this subject, that would also be great.
I shared this same goal. I wanted to "minify" Qt, building only a small subset of the libraries/DLL(s) and omitting the rest.
I did succeed, at least on Mac OS X. I assume that this approach will work on other platforms, too.
I thought that the trick would be to find some kind of exclusion flags for the "configure" script, but that turned out not to be the case.
Here is what I did:
Download the source distribution (in my case, qt-everywhere-opensource-src-5.1.1). of course, extract it all.
Edit the following three "pro" files. these files are in a qt-specific format (but plain text). They are platform-independent project files that Qt (via qmake) uses to generate makefiles.
qtbase/src/src.pro
qtbase/src/plugins/plugins.pro
qtbase/examples/examples.pro
All the changes that I made to the "pro" files were deletions. I deleted references to: dbus, ipc, network, qtconcurrent, sql, xml, sqldrivers, qdbusxml2cpp, qdbuscpp2xml, src_dbus, src_concurrent, src_sql, src_network.
That last part may sound scary. It really wasn't.
The pro files contain a list of module names, plugin names, and directory names. It seemed fairly straightforward how to delete (for example) all SQL-related lines.
Step 3.
The usual configure/make/install. However, note the "module-qtbase" argument passed to make:
./configure -prefix ~/my_test_dir/
make -j2 module-qtbase
make -j2 module-qtbase-install_subtargets
Success. This built and installed only the essentials (QtCore, QtGui, QtOpenGL, QtWidgets) and skipped all the supporting dylibs like QtConcurrent, QtMultimedia, QtSql, and QtWebKit.
ICU can link statically, and you can customize it (see docs) to reduce size. By default the data is also large, I don't know how much data you need. You could include only enough data to run in one language.
Only part of an answer.
There's no need to disable Qt modules. Each application that uses Qt decides what modules it uses and links with. A basic console-only application may use the core module only. That's what you'd use when creating, say, a web service in Qt.
I wonder, how do people maintain CMake projects on Qt creator? When you open the project you run CMake generator and after that you can't change much. In order to add another class to the project you have to create class files by hand, add them to CMakeLists.txt and rerun CMake again. Moreover, changing the class name is a nightmare.
I do actually like CMake (except its syntax), since it has some nice features. However, maintaining a project is a nightmare. Am I missing or doing something wrong?
No, you did not, that is how cmake works: You maintain the build system by hand and generate files for your preferred build system.
That approach makes it pretty easy to support several IDEs/buildsystems using cmake. Unfortunately it also makes it impossible to have an Integrated Development Environment for cmake projects. The rather complex syntax which makes it basically impossible for a machine to modify cmake projects does not help there either.
I'm trying to deploy an application using macdeployqt. All Qt frameworks get copied correctly into the application bundle. The problem I encounter is that macdeployqt does not have write permissions on the copied frameworks which originally reside in /usr/local/lib. This is because I have installed qt using homebrew which seems to make install everything read only. My question is whether there is a better way to fix this issue then manually changing all permissions of the qt libraries inside /usr/local/lib so that I can use macdeployqt from within a qt .pro project. (I don't want to use macdeployqt manually with sudo or such)
The reason why I'm asking is because I am using many third party libraries in the project (they get copied ok etc.) which I need to update often through homebrew and thus have to redo the permission changing on them.
Thanks in advance!
Just in case someone finds this old post looking for info about macdeployqt:
Use a script to do macdeployqt in preference to scripting the macdeployqt commands in your .pro file. That will allow you to change the permissions on the files on the fly.
Here is [a snippet of] the script I use for one of my apps:
https://bugreports.qt-project.org/browse/QTBUG-23268
If you're on Windows and don't have bash, you can use perl or python. The script referenced above modifies the files on the fly to work around a bug - you can put anything you want here, including changing the permissions on the files.
Using a script also means that you have the flexibility to add commands later to do code-signing, packaging or whatever else you need.
The Qt .pro "scripting language" actually generates Makefile commands under the hood and can be quite obscure if you want to accomplish deployment tasks that relate to paths and sets of files.
Also you'll need to create an extra target or include it into your build target - either way the build process becomes more complex and more error prone.
Disclaimer: I worked on Qt for 8 years as a Senior Engineer for Nokia/Trolltech, and also have published a commercial cross-platform app using Qt.
I have a large software project which uses aspects of OpenGL for visualisation. I want to add a GUI and was thinking of using QT. Now from what I understand, building QT stuff can get ugly unless one sticks to using the qmake command...
However, my project relies on the GNU tools for building (g++, autoconf, automake, etc., etc.). Must I therefore restructure my whole build process to use qmake just so that I can use a few small aspects of QT? I am very reluctant to do so given the size of the project.
As a thought, could I possibly (somehow) use qmake for the graphical components (i.e. qt-dependent stuff) only and continue to use my standard GNU build process (make, g++ etc.) for everything else?
Thanks,
Ben.
A quick Google search turned up AutoTroll and a howto.
Personally, I have used Qt without qmake before, but it was for a personal project, so I just used a (non-portable) Makefile. I set a variable (QT4DIR, since QTDIR was used by Qt3) to point to where I installed Qt, then added -L$(QT4DIR)/lib -lQtCore -lQtGui, etc. to LDFLAGS and -I$(QT4DIR)/include/QtCore, -I$(QT4DIR)/include/QtGui, etc. to CXXFLAGS. It looks like those links explain how to do something similar for autotools.
Edit:
To handle the MOC, I've added implicit rules like:
moc_%.cc: %.h
$(MOC) $< -o $#
And then make sure that all required moc_*.cc files are included in my SOURCES. It's a bit of a pain to specify QObject-derived classes twice, but everything will get built.
After much head-scratching, I decided to compile the original code into a library using my original build process (but slightly modified to compile a library rather than a binary) and then compile the gui separately using qmake. This would then also link the gui in with the original library code. Not 100% ideal but works fine. Probably the biggest hurdle was converting some glut code into a QGLWidget...