I want to find some information about Model/View's implementation, but it's not documented.
By the way, I don't want information about how to use Model/View, what I want to know is its procedures, such as which function is called when, etc.
Investigate this yourself. You can
look at the source code
use an interactive debugger
write some code to try to intercept the signals and slots (I believe there's something built into Designer)
use a Qt-specific tool to look at the live objects like Qt Inspector
http://doc.qt.nokia.com/4.7-snapshot/model-view-programming.html
Related
I read https://doc.qt.io/qt-5/qml-qtwayland-compositor-waylandview.html#details but still cannot understand what is WaylandView.
I tried to see how WaylandView works, but which type cannot be found.
WaylandView is not a type
I also tried WaylandQuickItem which looks like the wrapper class of WaylandView. but cannot understand the difference, why make WaylandView registered in QML but cannot create the instance? What it is used for?
WaylandView is mostly used if you are implementing a compositor in C++. In QML it's mostly an implementation detail, and WaylandQuickItem and ShellSurfaceItem wraps and uses it internally.
If you need to do something really specific that's incompatible with ShellSurfaceItem and WaylandQuickItem it could probably be useful, but otherwise it's safe to ignore it.
The QML cocumentation could probably have been better for that type ;)
I'm using the qdbusxml2cpp tool to generate a D-Bus adaptor class for my D-Bus server. However, it has the following drawbacks:
Code is generated once, and then you're not supposed to modify it. But what if we have to make changes (see below) and then the XML changes (in a backwards compatible way, of course)?
It is assumed that the "adaptee" has the exact same functions and signatures as the D-Bus interface. In my case, that's not exactly true, e.g. some methods are named differently. Because the generated code uses QMetaObject::invokeMethod, this is only detected at runtime. And we can't sensibly modify the generated code if we might need to regenerate it in the future.
It would be much nicer, in my opinion, if qdbusxml2cpp would generate an abstract class, just a header, where all methods are pure virtual. Then I can write an implementation of that class that simply calls the right methods on the adaptee, without going through the Qt metatype system. This solves both problems:
If the XML changes, we just regenerate the header. Now the compiler will complain until we implement the new interface correctly.
We have the freedom to call whatever functions we like on the "adaptee" class, instead of maintaining the exact same signature as in the public D-Bus interface.
I couldn't find any tool or qdbusxml2cpp fork that does the above. Before I write it myself, are there any problems with the above approach that I might be overlooking, design-wise or technical? Perhaps limitations of the metatype system related to abstract classes or pure virtual functions?
Note that I need this to work not just with methods, but with properties and signals as well.
I've also considered writing an "intermediate" adaptor that wraps the "adaptee" and offers the exact interface that the D-Bus adaptor expects, but the D-Bus adaptor would still be using the metatype system and runtime checks. Surely we can do better.
As you've discovered, there's no way to do what you want with qdbusxml2cpp directly. Which means that we have a few options here, some that you've already listed out:
It would be much nicer, in my opinion, if qdbusxml2cpp would generate an abstract class, just a header, where all methods are pure virtual.
There doesn't seem to be anything terribly wrong with this, although some tools/IDEs may not play nicely with it. One downside to this is that whenever something changes, you would have to ensure that you update all parts of the C++ source as well, not just your header, e.g. if there is boilerplate that has to change whenever a new method is added.
Code is generated once, and then you're not supposed to modify it. But what if we have to make changes (see below) and then the XML changes (in a backwards compatible way, of course)?
Depending on how well the code generator works, I've sometimes found it easier to simply use the generated code as a starting point and then simply modifying it from there. Most of the chages are generally pretty simple.
One other option that you could do is to use a different library to do the DBus communications.
dbus-cxx
dbus-cpp
dbus-cplusplus
I use(and maintain) dbus-cxx; there is a tool included(dbus-cxx-xml2cpp) that generates adaptee classes that are similar to the output of qdbusxml2cpp in that the adaptee class simply calls a different class that handles the actual response. The downside is that the xml2cpp tool is not that smart, and will not always output correct code. And to use dbus-cxx in a Qt application, you need to turn off the Qt keywords. However, it does have the advantage of using templated functions, so if your signature is incorrect you will get a compile error.
Unfortunately, there isn't really a good "right" way to do this, so I'm afraid that I don't have a "Do it this way" answer.
I do not know Javascript and have never used Qt. I do use c++ but I don't think that is much help? It is a pretty simple script but I can't find any tutorial etc for Qtscript.
Qt's own documentation is a good place to start. Try Making Applications Scriptable and Qt Script Examples.
I noticed that modal dialogs on QT uses a local QEventLoop with the ProcessEventFlags set as "DialogExec"
eventLoop.exec(QEventLoop::DialogExec);
The QT assistant has no information on what this enum means. There is another one called EventLoopExec. Anyone has any idea what they actually mean and why aren't they documented?
Thanks
I did some poking around and this is what I found:
This enum is intentionally omitted from the documentation, along with several other QEventLoop::ProcessEventsFlag enum values (X11ExcludeTimers, ExcludeUserInput, WaitForMore, EventLoopExec) as there is an \omitvalue in front of each one in the comments that generate the docs.
There is only one place in all of Qt that actually uses it, in qeventdispatcher_mac.mm in which it appears to be some kind of mac-specific optimization according to the in-line comments
The intentional omission of these values from the docs leads me to conclude that they're for internal Qt use only, and that you shouldn't need to use them or worry about them.
Once I've seen a nice tool called .NET Reflector. It can show the entire object hierarchy of .Net binaries/apps (sorry if the term is wrong).
Is there something like this for Qt? As Qt has very good QMetaObject abilities, it should be possible to traverse object-trees, call methods(slots), change properties, etc.
I am currently re-factoring a Qt project. The naming of variables is very domain specific and I am not the expert in this domain. So, it is difficult for me to map a widget-variable to the widget on the screen. Such tool would be a great help for me to understand the code.
Thank you very much in advance!
For simple uses you might want to take a look at QObject::dumpObjectTree()
If you need something more advanced there's kspy
kspy: examines the internal state of a
Qt/KDE app KSpy is a tiny library
which can be used to graphically
display the QObjects in use by a
Qt/KDE app. In addition to the object
tree, you can also view the
properties, signals and slots of any
QObject. Basically it provides much
the same info as
QObject::dumpObjectTree() and
QObject::dumpObjectInfo(), but in a
much more convenient form. KSpy has
minimal overhead for the application,
because the kspy library is loaded
dynamically using KLibLoader. See /usr
/share/doc/kspy/README for usage
instructions. This package is part of
the KDE Software Development Kit.
It depends on KDE's klibloader so if you are not under KDE you have to modify it but it should be rather easy. Sources are here.
There's QSpy project. It inspects all QWidgets of running application. I'm not sure how well it works, because I couldn't use it on Mac OS X. Maybe on Windows it works better. https://github.com/sashao/martlet
http://qt-apps.org/content/show.php/QSpy?content=102287