I'm considering to build a QT Quick application that supports user/community defined plugins. Those plugins should be able to extend the existing UI, e.g. with custom windows or dialogs.
With the rather old QT widgets this would be no problem, since you can define a complete UI structure with C++ code which can be dynamically loaded at runtime.
However, QT Quick heavily relies on QML to create the UI. Doing this with C++ only is
quite complicated
highly discouraged by the QT docs
So what are my options to dynamically load user plugins into my existing QML UI at runtime? Is it even possible?
Related
So, I'm a newbie in Qt and my intent is to familiarize myself with Qt Graphics. However, most of the guides on the internet suggest to use QML instead Qt C++ when it comes to dealing with graphics.
Here is my question:
What is the difference between Qt C++ and QML?
What does QML give us, that Qt C++ does not?
UI Technology
It's actually not so much a question of QML vs C++, rather it is a question of what UI technology to use with Qt:
QtWidgets (code written with C++)
QtQuick (code written with QML/JS)
HTML5 (via WebEngine, embedded into a widget or QtQuick item)
OpenGL (embedded into a widget or QtQuick item)
Leaving aside HTML5 and OpenGL, the question QtWidgets vs QtQuick has been discussed in other placed, for example at Qt Quick vs. Qt Widget and at this Qt DevDays 2014 presentation.
My personal opinion: Use QtWidgets for traditional desktop applications, and QtQuick for mobile and embedded (devices with touchscreen), unless you have good reasons to do otherwise. QtWidgets has better and more mature support for traditional desktop controls, while QtQuick is better for animations and completely custom styling.
One reason to use QtQuick on the desktop is when you want lots of custom animations and styling, at the cost of fighting a bit more with traditional desktop controls such a toolbars, menubars, drag&drop etc.
Language
When choosing QtWidgets, the language is always C++ (well, unless you use the Python bindings). While you can use the Qt Designer tool to visually create UIs, in the end those get compiled to C++.
When choosing QtQuick, the language for the UI parts will be QML and JavaScript. However, in any moderately large QtQuick application, you will at some point also have a C++ part - for example to interface with other C and C++ libraries, for operations that don't have an associated JavaScript API or simply for quicker and more maintainable code than JS. C++ classes and objects can be accessed from QML, check the documentation for more details.
How does one build a custom widget in Qt/C++ (version 5.5) that loads the native OSX webkit? I read this tutorial but need to do something more powerful because Qt doesn't already contain the native webkit.
Qt 5.5 has a "tech preview" for the native webkit, but it's buggy -- when you load form controls, they appear all wonky.
I've taught myself some Objective C. So, I was wondering if I had to build something in Objective C and then somehow load it inside Qt/C++?
Or, perhaps I can build the interface in Objective C and then have it call Qt/C++?
Ultimately, here's what I want:
Uses native OSX webkit, not the one bundled with Qt, not the tech preview.
Embeds a link to my Qt/C++ class in Javascript. So, I can do something like: var sFileSelection = cpp.selectFile('*.txt'); and it calls a Qt class method selectFile(QString sFile) to do work such as show a popup select file window, and then Javascript receives this back in sFileSelection.
The better solution that has been proposed is to develop the app's GUI in Objective C, and then call a Qt/C++ Dylib (the equivalent of a DLL on Windows) from the Objective C to do the heavy-lifting. (Assuming you prefer to do most of the coding in Qt.) The drawback of the Qt Dylib is that it cannot draw GUI components or show things like a file dialog because it has no application context handle to use for such things. Therefore, those GUI things must be called from ObjectiveC. However, one can have the class method in Qt and then it can send a message back to ObjectiveC to call one of its own class methods.
As for how to load a Dylib created with Qt inside an Objective C application, that's another question entirely.
I have a question about the necessity of using MFC's built-in document-view architecture. I was given an old dialog-based project in which I have to replace the main dialog with a frame and add a ribon. It has sort of a doc-view architecture, created without the built-in classes and I preffer to reuse it in the new version. However, if I try to bypass the CDoc and CView derivatives, normally generated by the project wizzard, all I can see is an empty window without a ribon. So... do I REALLY have to implement these built-in doc-view architecture, or am I just missing something? Isn't it possible to use the already existing code from the project?
If you will be using multiple views & documents in your frame then it is advisable to use the existing framework's design (CDocument, CView etc).
If you are doing it only for ribbon and will be just moving your controls from dialog to frame then you can skip the standard Document/View architecture and directly instantiate ribbon control.
If you don't have to re-write a lot of code, then I would suggest that you use standard Document/View architecture as in a long run it will save a lot of time, make your app scalable to a bigger multi-doc design etc.
I'm new at QT, actually I didn't start yet but I'm intending to create a xml file (markups and nodes and everything .. ) from a QT user interface.
For example the user can find in my interface text fields where he can insert an employee name, id and age and my program will turn that to an employee node in my output xml file with its attributes name , id , age. so since I'm coding with c++ I wanted to create this interface as a QT GUI but I found that QT creator provides a project named QT Widget with the same option.
So I'm kind of confused now and I don't know what's the difference between them so I can chose.
I will appreciate any help from guys.
If I have understood your question correctly: a Qt Widget is a tiny element, one of the many items in a gui (buttons, comboboxes are all widgets). The Qt Widget, project type is for creating one, which you can use in a separate projects interface.
A Qt Gui is more likely the project type you want, that will allow you to drag in many widgets to create your 'interface text fields'.
You would use a Qt Widget project type if you need to do more advanced customization or create your own text field control.
Do you mean Qt Quick vs. Qt Widgets?
Qt Quick is a more recent type of Qt GUI which is created from a declarative markup languages known as QML. The QML source is interpreted at run-time as opposed to Qt Widgets which are compiled from C++ source code into native executable code. In addition to QML, Qt Quick uses inline Javascript for scripting the UI, but it can be (and usually is) interfaced from C++ for more complex processing.
EDIT: Qt Quick is also very much touch-oriented (at least at its current state) whereas Qt Widget GUIs provide a much richer set of UI elements. So if you are making a desktop application, you might want to leave Qt Quick alone.
I have been playing with Qt for a week or so, with the aim of integrating Qt dialogs into an existing application. I've figured out use a basic Qt Message box from my MFC application, eg:
extern "C" __declspec(dllexport) bool showDialog( HWND parent )
{
QWinWidget win( parent );
win.showCentered();
QMessageBox::about( &win, "About QtMfc", "QtMfc Version 1.0\nCopyright (C) 2003" );
return TRUE;
}
I've used Qt Designer to create dialog boxes. What I haven't figured out is how to bring all of these pieces together. Qt Designer leaves me with a .ui file. I've seen that I can use uic to compile that to a .h file, but where are the other parts, like .cpp files? Further, if I want to compile the Qt parts to a dll, which are loaded on demand, what is the process for that? To put it into context, the existing application has 1000's of dialogs that the user may want to use, hence they all live in dll's that are loaded as needed and the dialogs come as additional downloads, kind of a plugin if you will, separately from the main program.
This is probably missing a lot, so please bring on the questions.
thanks,
Daniel
Get the VS plugin, it makes Qt work seamlessly with VS.
It complies ui files into classes which you then call from your code. You can also write dialogs, menus, etc in your C code. Since it uses sizers for layout there isn't a lot of X-Y coords to manage to place every component.
Although if you can I would go for a big-bang approach of replacing the MFC main with a Qt main and moving the functionality over. AFAIK MFC dialogs should work perfectly well in a Qt app.