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 ;)
Related
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 am trying to make changes to the behavior of a function and print the results to a file. The ViewCfg plug-in described in the Plug-in Development Guide does something similar, but I am trying to avoid having to use Ast.get, which ViewCfg uses. I am thinking of extending Printer.extensible_printer which, according to the Frama-C API Documentation, is something I can do if I want to obtain a custom pretty-printer.
However, if I extend the pretty-printer as described in the API docs, unless I'm doing something wrong, I notice that the changes I make take place regardless of which project is set as the current project. I'm using File.create_project_from_visitor to create a new project and Project.set_current to set the new project as the current project before I use the custom pretty-printer.
Is it true that any change made by a class that extends Printer.extensible_printer applies to all projects? I happen to be using frama-c-Aluminium-20160502, which I know is not the latest version.
EDIT: Sorry, I should have made this clearer in the beginning, but I'm not actually making changes to the behavior of a function. I'm reading in the behavior of a function, then based on that, I'm trying to generate as output valid C code that's meant to be read as input by another program.
Regarding AST.get, the only reason I was avoiding it was that it sounds like it gets the entire AST, while I'm only interested in part of it, i.e. behaviors. But if I'm just making things harder for myself by avoiding it, then I'll go ahead and use it.
If I have the structure:
api > v1 > *.go
I would like to be able to import api.v1 and from that, reflect out any of the types defined therein that satisfy, say, http.Handler.
I have reflect of types and methods down, but I can't seem to figure out how to just inspect anything that has a package v1 declaration and extract all types defined in there. Is this impossible to do?
Thanks!
If you don't use the imported code the compiler will not include it, so I think it's impossible.
If you are running the code somehow anyway (so it is included) you might as well just have it call a register function to register itself.
Programming in Go usually doesn't include the sort of "magic" you are asking for. At first it felt limiting to me, but I got used to it after a while and now I appreciate that things are what they look like, if that makes sense.
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
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.