Qt library includes advanced meta-programming capabilities using they own preprocessing moc compiler. Does anyone knows, is it possible to create some kind of mix-ins via it? For example, i have a QString and want to add a method to it without sub-classing and changing existing code. Does Qt have such solutions for that?
I'm pretty sure that what the moc compiler isn't considered meta-programming according to the most common definition.
Furthermore, you can't add methods to a class using it.
Infact, in C++, you can never add methods to a class outside its declaration and moc (or any other QT utility) never actually touches the definition of the class. it only adds some meta-information to it and additional code which takes care of the signals and slots mechanism. This has very little to do with actual meta-programming.
Related
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...
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 have learned the basics of Qt and now interested in the depths of that pretty library. Please help me to understand:
Are the all classes derived from QObject?
Why is it possible to paint on a QWidget (and derived classes)?
What does the line return app.exec(); mean? What does exec() method do?
Are there virtual slots? And virtual signals?
Thanks.
All classes that need Qt's object model (e.g. by using signals and slots) must derive from QObject.
So that you can implement your own widgets, with a customised look. Any sensible GUI library would let you do that.
As documented, it enters the Qt event loop.
Slots can be virtual. Since signals do not have implementation (or rather, moc generates their implementation), they cannot be made virtual.
Qt has really good and extensive documentation, if you have more questions then they are probably already answered there. Start with Programming with Qt section.
As a followup to this question about Scala's #BeanProperty generating change events: What would it take to fully implement the behavior that annotating a var field with some custom annotation (#Property, for instance) would generate the code needed to fire property change events? The only way to do it is to write a compiler plugin, right?
More generally: is there a standard way (like in Java) to process annotations in the compiler in Scala?
It may be possible to do this with a proxy, just as you would in Java, possibly involving cglib or similar. A compiler plugin could also do this (as you rightly state), but might be a bit overkill if you're writing anything less than a general-purpose library!
A far better solution would be to manually write the getter and setter methods by hand so that they emit these events, if you're concerned about keeping code clean then these could always be moved into a trait.
For a slightly different approach to the problem, Naftoli Gugenhem has a "reactive" library on GitHub to help with Functional Reactive Programming, arguably a better paradigm than the event-driven model of observable properties.
The ObservableBuffer class is a good place to start looking.
I always try to apply the S.O.L.I.D principles and I really like the Qt toolkit but I find myself stuggeling all the time with the single inheritance rule.
If you are using multiple inheritance,
moc assumes that the first inherited
class is a subclass of QObject.
Also, be sure that only the first inherited class is a QObject.
How do you combine the single inheritance from a QObject rule and the Interface Segregation Principle.
I want to define the interfaces with signals and slots, but I'm not allowed to do this.
How do you get around this shortcomming?
Keep in mind that signals and slots are nothing more than functions that have special behaviors. Thus, you can use them to create interfaces.
For a full description of the process and a complete workaround for complex cases, see Qt Quarterly #15.
I don't think you can easily get around that with Qt's signal/slot mechanisms. You could try looking at either boost::signals or the sigc library, which are both more flexible in where you can place signals and slots. Be aware of possible namespace collisions with either library and Qt's signals and slots macros.