I want to use QValidator and its subclasses (QRegExpValidator, QIntValidator) in QCoreApplication, but get the following error: "QValidator: No such file or directory"
If I add in .pro file the following line: "QT += gui" - all works fine, but that is not a solution for me.
Is there any technique to use QValidator in QCoreApplications?
No, this is not possible. QValidator is part of the gui lib. I suppose the Qt devs thought that QValidator makes only sense with Qt's text input classes. I checked again, above statement is still true. However, I looked into the code, QValidator does not depend on any gui stuff. On first glance it seems to be rather stand-alone. So you might be able to copy qvalidator.cpp and qvalidator.h from the Qt sources into your sources, do a reasonable amount of adjusting, and integrate this into your code. It might be possible, I don't say it will be easy.
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.
After several weeks of on-and-off research, I still haven't found a thorough guide on how to perform translation/localization in QtQuick (as in, using the QML language, not C++ or Python).
In general, I'm asking what are the steps to properly localize a project as much in QtQuick as possible, with minimal or preferably no C++.
More specifically, there are a good number of holes I need to fill in my understanding of how QtQuick handles localization.
So far, I've:
Appended QT_TR_NOOP() to all of my translatable strings for translation at runtime
Added my file containing all strings to my .pro file using lupdate_only{SOURCES += LanguageStrings.qml}
Generated translation files using QtLinguist
However, I intend to implement an option for dynamically changing the language, and the only example I've seen regarding translation which wasn't entirely in C++ essentially created an instance of the project for each language, rather than changing the strings at runtime.
So, how do I change the language at runtime? Is there a variable I can set? Is it pulled from system locale? I haven't seen a solid answer on this.
Any ideas?
You can do this with minimal C++ (at least I think this is minimal). I've done this in the past using the locale of the system the app is installed on like this (directly in main()):
QGuiApplication app(argc, argv);
QTranslator translator;
if(translator.load(":/translations/myapp_" + QLocale::system().name())) {
app.installTranslator(&translator);
} else {
qDebug() << "Unable to load translation";
}
The translations need to be in the resource system for the above to work. You can of course trigger the above based on user input from QML (e.g. in the settings of your app) at run-time. Here is some example code to do this (https://wiki.qt.io/How_to_do_dynamic_translation_in_QML). I am not aware of a QML-only way to do this.
I tried something else which works, too. You can have your UI in a Loader Element and simply use the setSource functions of that element after the translator changed. I quickly put together a small example, which also includes an example of how to change UI elements outside the Loader, if that is needed (https://github.com/Conntac/qtExamples).
I have become addicted to emacs and have been using it for everything. Now, I have started Qt4 . I am forced to move to the Qt Creator because of its auto complete feature which is required when writing programs in Qt because of the heavy use of pr edefined functions in it.
But the problem is that I don't want to leave emacs. Is there any way to get a auto-complete feature close to that of Qt Creator in emacs.
I have installed the CEDET-1.1 where I discovered the text file for c++ which contains all the commonly used c++ keywords. One way could be to add Qt class and function names in that file which gives me a pretty basic auto complete for Qt. But can I get a better auto complete?
Do not use cedet anymore, it is big, and slow.
I recommand you use https://github.com/brianjcj/auto-complete-clang, which is lightweight, and much easy to use. All you need to do is to learn and configure of auto-complete and yasnippet.
I'm using an OpenGLScene as a wrapper of the openGL, and I've started with the most simple example of that I've found on the internet. I've just copied everything from the link where they have a zip.
I compiled and run the program, and apparently this warning is always coming up (in the drawbackground method):
if (painter->paintEngine()->type()
!= QPaintEngine::OpenGL) {
qWarning("OpenGLScene: drawBackground needs a "
"QGLWidget to be set as viewport on the "
"graphics view");
return;
Does anyone knows why (I'm on a Mac)? Does anyone has a more "stable" example? Is this warning relevant?
Basically, I would like to know why this warning is appearing, and how can I get rid of it...
I don't really know where to start. I've tried several simple things (making the QGLWidget current Context for instance), but I don't know enough Qt to understand the when and how is the drawbackground method called.
Qt OpenGLScene working example
"Boxes" demo in Qt 4. Launch qtdemo, select demonstration->boxes. Or read it all online. Either that or read documentation for overpainting, HelloGL or any other OpenGL example.
I'm trying to have a "wrapper" to OpenGL using Qt. Using Qt as GUI, and OpenGL as visualization
QGLWidget
Are you having OpenGL or OpenGL2?
Try this code
if (painter->paintEngine()->type() != QPaintEngine::OpenGL
|| painter->paintEngine()->type() != QPaintEngine::OpenGL2)
What are you trying to do ?
IIRC the qq26 example didn't work in 4.7 (haven't tested it in 4.8).
But overpainting QWidgets on top of an openGL scene was added to 4.8 ( http://qt-project.org/doc/qt-4.8/opengl-overpainting.html ) rather than the hack in that example
edit: Just using an opengl display in Qt is simple, just derive from a QWidget and implement initializeGL, resizeGL and paintGL. There are Qt functions to wrap textures, VBOs, PBOs and all the other opengl stuff. See the OpenGL examples in the distribution.
I've made a small minimal OpenGL+Qt which I think can answer the point:
I don't really know where to start. I've tried several simple things
(making the QGLWidget current Context for instance), but I don't know
enough Qt to understand the when and how is the drawbackground method
called.
I think it can help someone who was in the position I was when I asked this question.
My Qt project links to a library that is linux-only. When the project is run under linux, I wish to have a signal fired on an event using a type defined in that library. A complication that I have, though, is that the project must also build in Windows. Obviously, this signal and the slot catching it wouldn't exist in Windows, and that's fine. I am, however, finding issues with Qt's moc tool failing to recognize the existence of an #ifdef __linux__ around the code that emits the signal. My code looks like this:
[SomeFile.h]
#ifdef __linux__
signals:
void SomeSignal(SomeTypeDefinedInTheLinuxLibrary);
#endif
[SomeFile.cpp]
#ifdef __linux__
emit SomeSignal(someObject);
#endif
When I attempt to compile this with g++, I get the error:
SomeFile.cpp:(.text+0x858c): undefined reference to SomeFile::SomeSignal(SomeTypeDefinedInTheLinuxLibrary)
Any ideas how to get moc and #ifdefs to play well together?
A much better solution is to always provide the signal and just comment out the code that fires it on Windows. That way, the public API is the same on all platforms.
[EDIT] The moc tool is really dumb. It doesn't actually understand the code; instead it just reacts on certain patterns. That's why it ignores the #ifdef.
To solve the issue, wrap the type or use #ifndef __linux__ and define your own dummy type in there so it compiles on Windows. Since the signal won't be emitted on Windows, the slot will never be used so any type that makes the code compile should be fine.
With Qt 5.3 at least using Visual Studio, I am able to pass pre-processor macros to the moc tool. In order to make this work, I had to text edit my Visual Studio project file and manually add command line arguments for each file in order to hand the pre-processor arguments to the moc tool. You can use -D[Pre-Processor], i.e. -DSPECIAL_BUILD or -DSPECIAL_BUILD=1, and the moc compiler is smart enough to see the #if SPECIAL_BUILD checks in your code and not try to moc those parts.
Just search for "moc.exe" and add the appropriate parameters for each configuration.