I've read through the tutorials of Qt, I've searched the net, but I can't find the exact way on how to build custom witgets with Qt 5.8.x. In example with this tutorial one is able to build widgets for Qt 4.x as I already succeeded. For Qt 5.8.x I'am lacking in such straightforward tutorials.
Even if you use the build in wizard of Qt for setting up such custom widgets projects, one will end up with none recognized widget libraries.
So first of all, there is a confusion with the installing path, that the makefile should mention while installing the plugin.
In the project file one can find the section
target.path = $$[QT_INSTALL_PLUGINS]/designer
INSTALLS += target
After a straightforward installation of the open source mingw version of Qt 5.8.0 on a windows 7 machine in the path C:\Qt\Qt5.8.0, the variable "QT_INSTALL_PLUGINS" will extend to
C:\Qt\Qt5.8.0\5.8\mingw53_32\plugins
thus the "target.path" for the
make install
will be read as
C:\Qt\Qt5.8.0\5.8\mingw53_32\plugins\designer
But on the plain installation of Qt 5.8.0 with mingw the designer searches its plugins in
C:\Qt\Qt5.8.0\Tools\QtCreator\bin\plugins\designer\
As someone already suggested to me, one has to set the environment variable "QT_PLUGIN_PATH", where Qt Creator as well as Qt Designer ( in the subdirector "designer") searches its plugins in. So in order that Qt Creator still works properly one has to set the environment variable "QT_PLUGIN_PATH" to
the original path as well as to
the install path reffered to by $$[QT_INSTALL_PLUGINS]
So on my Windows 7 environment I set the variable "QT_PLUGIN_PATH" to
C:\Qt\Qt5.8.0\Tools\QtCreator\bin\plugins;C:\Qt\Qt5.8.0\5.8\mingw53_32\plugins
Afterwards Qt Designer is able to find the custom build widget library. But Qt Designer it not able to load the library. One interesting thing is that the designer also refuses the libraries provided by the installation of Qt itself.
on loading the custom widget lib it says:
"... .dll can't be loaded: the given procedure was not found"
on loading the libs supplied by the Qt distribution itselfs in the path C:\Qt\Qt5.8.0\5.8\mingw53_32\plugins\designer it says:
"... .dll cant be loaded: the mentioned modul was not found"
What I've done to build the library is, that I just ran through the project wizard to generate a custom widget for Qt Designer. With the so generated project I get the result of a non loadable lib, as mentioned above.
What do I have to change in the source/project files in order that the Qt Designer ist able to load the lib properly?
Thanks for any hints or suggestions!
You seem to use the MinGW compiler.
You cannot make plugins with that compiler with the default supplied Creator as it's compiled with Visual Studio 2013/2015 (depending on the Qt version).
Due to how DLLs works on Windows, you must use the same compiler that Creator is compiled with to build the plugin (otherwise it can't load it).
Go to "About Qt Creator" in the Help menu to check.
Also make sure to build the plugin in Release mode.
Related
I tried to create a C++ project with Qt I stumbled across different kinds of guides which all refer to a special '.pro' file inside the project where I have to adjust a setting so the SQL part takes effect.
My problem: whenever I create a new project - doesn't matter whether its with qbs, qmake, or cmake - the project structure/ folder is lacking the '.pro' file.
Currently I'm using Qt 5.15.2 (via QT Creator) with MinGW Kit and cmake/ qbs.
As I'd like to play around with SQL-based apps.
Maybe I'm just skipping/ overlook something?
TL;DR: Use cmake. Forget about qbs and qmake.
Whenever I create a new project - doesn't matter whether its with qbs, qmake, or cmake - the project structure/ folder is lacking the '.pro' file.
A qmake project will have the .pro file, since that's the project file for qmake. Maybe you're looking in a wrong place? A qbs project will have a .qbs file, since that's what qbs uses. A cmake project will have CMakeLists.txt, since that's what cmake uses. It all works for me.
I'm just confused by all these guides stating that I have to add QT += widgets sql in the .pro file.
Those guides only apply when you use qmake, since .pro are qmake project files.
I suggest that you use cmake, as qbs is abandoned now, and there's no benefit to using Qt-specific qmake over the widely supported and continuously developed cmake.
Qt documentation covers the basics of how to use cmake to build Qt projects.
Qt support is provided natively by cmake, and it thus provides a comprehensive reference page.
I have a Qt 5.5 dynamically linked installed with MingW 4.9.2 32-bit and Qt Creator 3.4.2. In my build tree I created a helper console non-Qt app that has literally 20 lines of code and does not rely on Qt (only uses qmake so I do not have to install cmake). I would like that app to be built statically but no option I set in the build make arguments seems to be accepted (static, static-libgcc etc.). Is it even possible or do I have to build it separately outside of Qt(Creator) and possibly get cmake instead of qmake?
If you wish to link the executable statically to the C++ runtime, then the static_runtime feature does it. You'll also want not to link with Qt:
# .pro file
CONFIG -= qt
CONFIG += static_runtime
The static_runtime.prf file is only available in Qt 5/6. It's not present in Qt 4. For Qt 4, you have to do it manually:
QMAKE_LFAGS += -static
How am I supposed to use my static build of Qt in my project directory? There seems to be a missing step in the official documentation between building a static version of Qt and then building a statically-linked version of your app with that static version of Qt.
There's no explicit step, since all you need to do is use that statically-compiled Qt to build your project. That's all. From the command line, simply invoke the statically-compiled Qt's qmake and your project will statically link to Qt. From Qt Creator, add the statically-compiled Qt's kit to your project's configurations and build for it.
Of course you must first add that Qt version to Qt Creator, and add it to a new kit. Note that as far as both Qt and Qt Creator is concerned, a "Qt version" is a synonym for a build of Qt. So if you have 4 different builds of Qt 5.3.1 (say dynamic multithreaded, dynamic single threaded, static multithreaded, and static), they are considered different Qt versions. Because a "Qt version", as used throughout, has nothing whatsoever to do with the sources of Qt, just with a build of Qt. If all you do is download a source package of Qt, you have no Qt versions yet :)
Does it make sense to add relevant Qt Libs and headers (opensource version) to a projects repository or should I just reference them from the sdk directory ?
I (alone) am developing a cross-platform (windows/linux) c++ application which, will be using a number of thirdparty opensource libraries including Qt, OpenCV, log4cpp to name a few.
I started off development in Qt Creator for convenience (speedy GUI creation). Currently I have the Qt Sdk installed on both Linux and Windows outside the project directory.
I'm planning to move to CMAKE to for better configurability, e.g out-of-source builds and independance from Qt Creator and I would like to have all dependencies included in the project directory structure -so that I or anyone else can checkout the project and build without needing to install any other dependancies.
I have added all libs but Qt's to the directory as I am a little unsure weather its worth it -it seems like CMAKE depends on the Qt Sdk for compiling Qt specific files i.e moc, ui etc... (see here) is this the case ? or is there a better suited build tool ? (Originally I was I going to use Scons but I decided not to as the there seemed to be limited support.. and there hasn't been developement on Qt4 Tools since 2010, which doesnt inspire confidence either.)
Qt is too big to be put in a project directory, even if you include only one of its modules. Also you have some convenient functions in CMake to use Qt (add moc, rcc, ui). You can even write these functions by yourself (in fast, they just add a pre-build command).
For the build operations: you will need to use the moc (and maybe ui, rcc, ...), which is not provided by CMake. So, a person wanting to build your application must have the Qt SDK installed. Luckily, this installation is very easy.
I have a Qt4 application with SVG icons, compiled with mingw (in windows), linked to Qt shared libraries.
When application is run, SVG icons show up in debug and release builds in linux, however in windows SVG icons show up only in debug build but not in release build.
All SVG icons are listed in project.qrc, and project.pro has RESOURCES = project.qrc. Application uses QtSvg4.dll (version 4.7.0).
Qt 4.7.0, Qt Creator 2.0.1, mingw/g++ 4.4.0.
Solution update: In application directory, create /imageformats/ directory and put qsvg4.dll there instead of application directory itself, or create a qt.conf file with appropriate path. More information in deploying plugins.
Most likely you will have to include the plugins from your qt dir. This involves making a qt.conf file that is local to your app (see here: http://doc.qt.io/qt-4.8/qt-conf.html , more specifically the [Paths] section), and copy c:\Qt\4.x.x\plugins\imageformats*.dll to your distributable's directory.
for Qt 5.14
add a line to the .pro file
QT += svg
For Qt5
Since Qt5 the framework has been heavily modularized (List of Modules).
Most likely you are missing the svg module. The application will still compile without complaining. Make sure the SVG module is installed on your system and linked (with qmake (Howto), cmake (Howto) or plain make). If it was linked successfully QImageReader::supportedImageFormats() will list SVG.
For my (Qt 4.6.3) application, I solved this by putting the plug-in dll (qsvgicon4.dll) in a directory called iconengines within the application directory.
Tried other solutions - such as deploying plugin to directory (within app directory) named imageformats with and without an appropriate qt.conf, but no joy.
Note: I previously ran the application with Qt 4.7.0 dlls and had no problems on the same Win7 target machine.
You guessed it: here's yet another way to avoid reading the docs, but instead to rely on cheap advice from the internet.
Just add this line to your app.pro!
QTPLUGINS += qsvg
In my case, Qt is static linked from MSYS2, so plugin DLLs don't even exist. But the app still has to link in that imageformats/qsvg plugin code. The qmake line above is about the easiest way to do it; it translates to the g++ link line segment like this:
g++ [...] -LC:/msys64/mingw64/qt5-static/share/qt5/plugins/imageformats \
C:/msys64/mingw64/qt5-static/share/qt5/plugins/imageformats/libqsvg.a [...]
Based on what you've said, you're doing all that's needed for it to work, so a proper answer is likely to require some more information. See if these links are of any use to you:
http://lists.trolltech.com/qt-interest/2008-10/msg00655.html
http://www.qtcentre.org/archive/index.php/t-9036.html
In particular, make sure that the SVG plugin is getting loaded with:
QImageReader::supportedImageFromats()
It still seem to be a problem with Qt5.1 in Windows, here how I solved it for cmake users:
Find_File(qtsvg NAMES "Qt5Svg.dll" PATHS ${QTBinBase}/.. PATH_SUFFIXES "bin" )
Find_File(qtxml NAMES Qt5Xml.dll PATHS ${QTBinBase}/.. PATH_SUFFIXES "bin" )
Find_File(qsvg NAMES "qsvg.dll" PATHS ${QTBinBase}/.. PATH_SUFFIXES "plugins/imageformats" )
Find_File(qsvgicon NAMES "qsvgicon.dll" PATHS ${QTBinBase}/.. PATH_SUFFIXES "plugins/iconengines" )
install(FILES ${qtsvg} ${qtxml} DESTINATION bin)
install(FILES ${qsvg} DESTINATION bin/plugins/imageformats)
install(FILES ${qsvgicon} DESTINATION bin/plugins/iconengines)
Its the manual way, not beautiful but works. QTBinBase I got with another dirty trick:
get_target_property(QtCore_location Qt5::Core LOCATION)
get_filename_component(QtBinBase ${QtCore_location} PATH)
If adding the Qt4Svg.dll and the imageformats/qsvg4.dll doesn't work, make sure the Qt4Xml.dll is also included along the standard core, gui and svg DLLs.
This is how I solved this for me.
Short: to render svg images you need to include the xml DLL aswell