I've started learning QML with Qt6 lately and am trying to apply "best practices" right from the start. When it comes to integrating C++ it seems that a family of macros (QML_ELEMENT and friends) is going to replace the old style *register functions. A best practices talk on the Qt youtube channel calls this "declarative registration". I've tried that in a small example using CMake and it practically worked out of the box.
Now to my knowledge C++ classes exported and instantiated within a QML module have "QML engine" ownership. Lets suppose I'd rather have C++ take ownership of my class and QML merely use it, how would I inform the QML engine about my instance? Do I need to use setContextProperty for that?
I've also wondered what benefits and drawbacks I'd get from letting either C++ or QML handle ownership? There seems to be hardly any information on those topics. I've even browsed a couple of Qt books and not a single one would elaborate on that...
Related
I created table widget with check box and push button.
Now ,how to go on next page with all checked data, after click on push button.
the initial question was:
How to go on next page using push button in qt c++ without use of Qt signals and slots?
This is practically impossible, and certainly inadvisable, since Qt signals and slots is the basic foundational mechanism of Qt, used everywhere inside it.
Be sure to take more time to understand Qt signals and slots and study several Qt tutorials and examples. Consider also studying the source code of Qt5 itself (since it is free software). And you can also find many Qt open source applications (e.g. on github, gitlab, inside a Linux distribution, etc...) which should be inspirational (if you don't have time, you could pay some Qt consulting corporation to do your work).
My recommendation is to create some Qt QPushButton (perhaps subclassing that) and connect its clicked signal to your appropriate slot somewhere. The calculator example should be inspirational. You probably should subclass QTableWidget to add a new slot, and use that for your m_pTableWidget or at least declare your MainWindow::on_pushButton_clicked as a public slot (and of course connect it appropriately).
If you don't want to use Qt signals and slots, you should give up using Qt and choose some other widget toolkit. They all have some notification machinery (at least based on callbacks), and IMHO the design of Qt signals and slots is quite good (and sometimes better than what other toolkits provide).
Read also How to debug small programs
It seems that you don't understand the design principles of Qt (i.e. the fact that Qt signals and slots are central to Qt, so you should use them extensively). So I recommend taking a few days to study carefully the documentation of Qt (it is well written, but extensive; start with Getting Started Programming with Qt Widgets) and the source code of existing examples (including Qt itself); throw your current code to the trash bin; then rewrite it with an iterative and incremental development approach : code a few dozen lines at once, compile them (with all warnings and debug info, so g++ -Wall -Wextra -g with GCC), improve them to get no warnings, test your incomplete program - using the GDB debugger -, make sure it works as you want it to, and add one more small feature (perhaps just a single new widget) and repeat. Of course, use a version control system (I recommend git) and commit your code frequently (at least, at every loop of your iterative and incremental development approach).
NB. you have changed your question entirely (at first, you refused to use Qt signals and slots; now you accept to use them). Of course, you need to read carefully the documentation of every used widget (including the superclasses), notably of QTableWidget and of QTableView. And you need to define what a "page" is (and what going to the next page means), since QTableWidget don't know about them.
take time (several days or a few weeks) to read the documentation of Qt.
I want to use Qt 5.4 to create a window and render with normal OpenGL functions some stuff in that window. In the last few days, I read a lot about the Qt classes and how to initialize OpenGL and so on. I think, the main classes I have to deal with are QOpenGLWindow or QOpenGLWidget, but there are the QSurface and some other classes too. Now I am very unsure about what doing next and which class I should use to use the plain OpenGL functions, later. Can someone explain more clearly to me what I have to do to set up a Qt GUI in which I can use plain OpenGL?
Some other questions from me are:
At which point does Qt create a plain OpenGL context? Do I have to use the QOpenGLContext?
What is exactly the difference between a QSurface and a QOpenGLWindow? In the QOpenGLWindow example both classes are used.
Is it possible to use glew besides this qt stuff? Here are some question on, which deal with setting up glew with qt, but I think that I did not get the real point of why glew is needed.
Edit: I discussed this question with a colleague and our only conclusion was to use Offscreen-Rendering. Does anyone know another solution?
At which point does Qt create a plain OpenGL context? Do I have to use the QOpenGLContext?
Either where it's documented (for instance, creating a QOpenGLWidget or a QOpenGLWindow will automatically create a context), or you can create a context manually at any time by creating a QOpenGLContext object.
What is exactly the difference between a QSurface and a QOpenGLWindow? In the QOpenGLWindow example both classes are used.
A QSurface is a base class representing a "drawable surface" (onscreen or offscreen). QWindow is its onscreen implementation (representing a top level window), so it inherits from QSurface. You can draw over a QWindow by using OpenGL or by using a CPU-based rasterizer.
Finally, QOpenGLWindow is a QWindow subclass which offers some extra functionality and convenience, by automatically creating and managing an OpenGL context (via QOpenGLContext), having an optional partial-update strategy (through the usage of a FBO), etc.
Is it possible to use glew besides this qt stuff? Here are some question on, which deal with setting up glew with qt, but I think that I did not get the real point of why glew is needed.
Qt is not in your way. And it doesn't change your usage of OpenGL in any way. Just use Qt to create a window and a context (in a totally cross platform way), then you're free to use GLEW (to resolve OpenGL function pointers, extensions, etc.) or any 3rd party OpenGL abstraction.
I wonder what is the bounds of Qt's perimeter. I know for exemple that it can specify types (such as qint or QString), and I know it cannot get system informations such as CPU Usage or Memory Usage.
My question is about the limits of Qt.
Is it correct that Qt can only interact with what is inside the project but not with what is outside (I mean system-related) ?
You can get information about operating system with QSysInfo class, if you are looking for this. This is one example, I am sure there are other helper classes. I think you should use other libraries for information like CPU usage etc, see here and also this question.
QT is nothing more/nothing less then a GUI C++ cross-platform framework. It's doesn't really have a perimeter, it has certain cross-platform functions implemented (like widgets/frames/controls a lot of other things). And within it's own functionality it provides (As being mentioned above) QSysInfo class, but you are free to add any OS dependent (if you target your application for particular platform) or cross-platform solutions for whatever tasks you need - hardware info/OS monitoring/etc..
I have to port a project from Borland C++ Builder 5.0 under Windows XP to Qt 4.7.1 using g++ under Windows 7/mingw. The libraries and command-line utilities are done, and now I have to tackle the GUI applications, which use Borland VCL.
Can anybody recommend any tools or libraries to make this task easier?
Does anybody have any experience of this?
Edited to add: Well, I took the bull by the horns, and implemented the GUI from scratch. And I have to say, the commentators were right: I can't see any way of using the existing Borland GUI to ease the process.
There are several big differences between VCL and Qt that will make an automatic conversion process quite difficult.
Qt uses signals and slots and inheritance where VCL uses events.
VCL components use absolute coordinates and Qt uses layouts. Of course, you could use absolute coordinates also with Qt, but the GUIs would be quite awful then.
VCL's TListBox and TTreeView classes are quite different from Qt's View and Model classes (although you could use QListWidget and QTreeWidget instead).
I guess it is much faster to design totally new GUIs with Qt than to create even a mediocre VCL-to-Qt converter. And the code will be much easier to maintain. I suggest that you take one VCL form of medium complexity and recreate that with Qt. After that you can make an estimation of the total recreation work. Also you will have a better understanding about the feasibility of a conversion tool, which you most probably would need to make by yourself.
Someone has written a tool to convert dfm's to qt ui files:
http://sourceforge.net/projects/dfm2qt4ui/
Its has a few small bugs but it can save several hours of time porting form designs. In some cases redesigning specific forms is preferable - but in many cases, having labels and roughly equivalent controls positioned for you saves a lot of point-and-click action.
I agree with the current consensus that automatic conversion from VCL to QT is not a good idea because the concept behind both is very different, and you are much better off learning "the QT way" and using that from the start.
However there is one major step that nobody has yet mentioned: refactoring! Before starting, make sure you refactor the original forms to remove as much business logic as possible and leave only what is really GUI code. It depends on how good your architecture already is of course, but the VCL designer tends to encourage putting as much as possible in forms (even going as far as having invisible "data forms" with non-visual components!), so you often find a lot of stuff in the form that shouldn't be there.
Please point the docs for understanding the internals of Qt such as the design of the QObject class, The patterns choosen for the Qt classes. The reason for using QVariant class, e.t.c. Although Qt comes with very good documentation and examples, they mostly explain how to use them not why it is being done that way.
Here is a blog entry that at least explains the use of private classes and d-pointers in Qt.
Qt-Howto
I can't begin to answer this authoritatively, but some good resources are the description of the Qt Object Model and the QObject class reference, and the first half of this document for demystifying some of the Qt internals like signals and slots. Some of the design justifications are discussed here - why they use syntactic sugar, code generators etc.
If you want to use the documentation offline, e.g. with QtAssistant or with the help menu integrated in QtCreator, you must download it. Either you install QtCreator with the installer from (qt-project)[http://www.qt-project.org) or you install from a repository of your distribution (if you use linux).
The second option has a little problem. Ubuntu doesn't come with a complete Qt5 documentation. So you can download the necessary .qch (Qt-help-files) from my Mega account
"Introduction to Design Patterns in C++ with Qt"
book very useful