I just wondered if there was a way to forward-declare a class in a Qt UI file. The issue that I have is that I use (the same version of) a same widget in two different projects : a project that uses the widget and an independant project that allows me to do testing with this widget while I'm working on its features.
Now, what happens is that when uic generates the ui_widget.h file, it adds this in it:
#include "widgets/custom_line_edit.h"
That's the include path for one of my promoted widgets. The thing is that the path to this file is not the same on the "real" project, as it should be
#include "modules/this_module/widgets/custom_line_edit.h"
I don't really know what to do not to have to edit my UI file each time to match my "current" project's file organization.
I've found this which was quite satisfying:
It is sometimes necessary to forward declare classes, particularly if code is being written in .ui.h files within Qt Designer. Each forward declaration is listed as it should appear in the generated C++ code.
<forwards>
<forward>class QStringList;</forward>
</forwards>```
But unfortunately this documentation is quite old (Qt 3.3) and the syntax seems not to work anymore - I get an Error 1.
What are my options here?
The issue isn't one of forward declarations. I've never seen that "forward" mechanism in a UI file, but even it still works somehow, all that it does is put "class QStringList;" (or whatever) in the include file that uic generates. If you look at those include files, they will have "new SomeWidget ()" statements, and you can't create an object without its full declaration, so a forward declaration for something the UI file creates isn't helpful.
The UI definition needs the include file where the widget is defined for exactly that reason. It has to include the class definition in the file generated from uic, and the relationship between where the files reside is going to have to be consistent.
What I would do to solve this is put the widget(s) in a library, and then reference the library from my main application and my test application. Then the uic generation happens within the library, not the applications, and within the library, the relative locations of the files will remain constant. The applications don't need access to the .ui file nor the generated include file, so how the application source files are laid out in folders won't matter.
I don't see any other way to do this.
Related
I have the following Issue:
In main.qml I get these errors. Although I can use these types perfectly in the code. It looks like it is just an intellisense issue.
These types are registered in main.cpp:
Thse classes are defined in the include folder:
My folder structure looks like this:
Do I have to modify QML_IMPORT_PATH in the pro file? I added src and include folder but it does not work:
QML_IMPORT_PATH += src
QML_IMPORT_PATH += include
The code itself runs fine. It is just an Intellisense issue.
I assume this is simply a Qt Creator bug. Take a look at this one. qmlRegisterSingletonInstance was added to the Qt library in version Qt 5.14. Even though Qt Creator 4.13.3 was built with Qt 5.15.2, the QML code model it uses has apparently still not been updated.
You need to run this code. QtCreator is notorious for flagging errors that don't exist or won't exist. It flags header files for .ui files because you haven't run a build yet so they haven't been generated. Many developers paint their UI files then do a fake build just to generate those files so QtCreator shuts up.
The other thing you need to do is provide the full source code for one of those classes. (I will assume they all have the same issue.)
The example Qt gives here isn't a good one. You should never be able to "new" a Singleton. The constructor should be protected and the Instance() method should construct one and only one if the internal pointer is null.
Do you actually have a method named get() in each of those classes? Does it actually return a pointer? Many return a reference, that is why I'm asking. If we overlook the glaring error of being able to "new" a Singleton, there is one good thing in this example.
QScopedPointer<SingletonTypeExample> example(new SingletonTypeExample);
They used a QScopedPointer to the class.
qmlRegisterSingletonInstance("Qt.example.qobjectSingleton", 1, 0, "MyApi", example.get());
Once you actually build you will have all of the MOC information where it needs to be. This may well make QtCreator happy. Honestly, I've stopped looking at what QtCreator flags anymore because there are so many false alarms.
I am learning Qt for the first time and I prefer to learn how to things the hand-coded way. I prefer learning this route because I am using Eclipse (with no Qt Designer) and I learn better knowing what is going on under the hood. Thus, I would like to know how to hand-code the XML-based user interface definition (.ui) files.
Unfortunately, I cannot seem to find any information on how this XML tree should be structured, and which properties and attributes are allowed. Instead, I find "drag-and-drop" tutorials. Aside from generating the .ui files in Qt Designer and then studying the output XML tree, is there another way to learn how to handcode these .ui files, or any documentation which speaks to the semantics of this XML document?
Thank you!
The UI file's sole purpose is to save you from hand-coding things. They're files that are generated by designer:
You create user interface components with Qt Designer and use Qt's integrated build tools, qmake and uic, to generate code for them when the application is built. The generated code contains the form's user interface object. It is a C++ struct that contains:
If you want to improve your knowledge of Qt, learning to write UIs via C++ would be a better option. Still, if you're convinced, there is this XML schema:
http://qt-project.org/doc/qt-4.8/designer-ui-file-format.html
Note that it says:
Be aware that the format may change in future Qt releases.
You might also be interested in the documentation for uic, which operates on the .ui file to create a header file containing the various widgets that make up the UI.
i have this tree structure:
repository/modules/module1
repository/modules/module2
repository/modules/module..
repository/apps/application1
repository/apps/application2
repository/apps/application..
where the applications are using some modules.
now, I'd like to put some resources inside a module (like a very colorfull icons inside a widget used by several applications) but.. something gets wrong.
inside the module CMakeLists.txt if I use only:
set(${MODULE_NAME}_RCS
colors.qrc
)
...
qt4_add_resources (${MODULE_NAME}_RHEADERS ${${MODULE_NAME}_RCS})
no qrc_colors.cxx are created anywhere. so I've tried to add:
ADD_EXECUTABLE (${MODULE_NAME}
${${MODULE_NAME}_RHEADERS}
)
but.. I get this weird error:
CMake Error at repo/modules/ColorModule/CMakeLists.txt:51 (ADD_EXECUTABLE):
add_executable cannot create target "ColorModule" because another
target with the same name already exists. The existing target is a static
library created in source directory
"repo/modules/ColorModule". See documentation for
policy CMP0002 for more details.
(I've changed the path of the error of course)
so.. don't know what to think because i'm new both to cmake and qt..
what can i try?
EDIT:
if I add the ${MODULE_NAME}_RHEADERS and ${MODULE_NAME}_RCS in the add_library command the qrc_colors.cxx is created BUT it is in repository/modules/module1/built and not copied in the application built directory...
There is at least two errors in your code.
1) It is usually not necessary to use ${MODULE_NAME} everywhere like that, just "MODULE_NAME". You can see that the difference is the raw string vs. variable. It is usually recommended to avoid double variable value dereference if possible.
2) More importantly, you seem to be setting ${MODULE_NAME} in more than one executable place, which is "ColorModule" according to the error output. You should have individual executable names for different binaries.
Also, the resource file focus is a bit of red herring in here. There are several other issues with your project.
You can cmake files as CmakeLists.txt instead of CMakeLists.txt which inherently causes issues on case sensitive systes as my Linux box.
You use Findfoo.cmake, and find_package(foo) for that matter, rather than the usual FindFoo.cmake convention alongside find_package(Foo).
Your FindFoo.cmake is quite odd, and you should probably be rewritten.
Most importantly, you should use config files rather than find modules.
Documentation and examples can be found at these places:
http://www.cmake.org/Wiki/CMake/Tutorials#CMake_Packages
https://projects.kde.org/projects/kde/kdeexamples/repository/revisions/master/show/buildsystem
When you would like use a find module, you need to have that at hand already. That will tell you what to look for, where things are, or if they are not anywhere where necessary. It is not something that you should write. You should just reuse existing ones for those projects that are not using cmake, and hence the find modules are added separately.
It is a bit like putting the treasure map just next to the treasure. Do you understand the irony? :) Once you find the map, you would automatically have the treasure as well. i.e. you would not look for it anymore.
I'm seeing some of SF2 components have a folder named stubs placed inside the Resources/ folder. I wonder what is it for? And for my bundle I need to define some global functions, would the stubs folder be a good location to place the files containing these functions?
It seems there are a few meanings for stub. The most relevant I could find was one that described a stub as 'code that is used to stand in for some other programming functionality'.
I.e. acting as a substitute for code that is yet to be developed, or to simulate the behaviour of existing code that isn't usable (or viably usable) under certain circumstances, for example, in a development environment.
is there a simple way to generate a JAR file, that contains only the classes that depend transitive from a certain "main" class (reflection omitted of course).
I want to provide a little part of my application to someone else but do not want to export the whole application.
Thanks,
M.
Probably the easiest approach is using a tool like yGuard which "...provides elaborate code shrinking functionality through dependency analysis." This would also solve the same problem where you give it an entry point, and it performs dependency analysis to work out which classes can be excluded from the Jar.
However, I have throught about this problem myself a few times and fancied having a go at it myself for the challenge. All it would take would be to parse the import statements of Java source files and build a dependncy graph of how the classes interact with each other. Each reference from the main class should be recursively scanned until a complete graph is assembled. Then once the graph is assembled it would be a case of outputting this in a way that some packaging logic could process (or if you are feeling daring, the JDK has its own built in Jar creating/modifying code to do it yourself). Granted, this approach would require writing this custom utility and would also miss fully qualified class references in the code.