I'm writing a multi-language program with the Qt framework. I want to change the language at runtime. I wrote the code below in a slot but it does not work.
QTranslator translator;
translator.load("arrowpad_tr");
qApp->installTranslator(&translator);
Installing a translator only means that the specific translator becomes available. This is signaled by a LanguageChange event for the QCoreApplication. What you will still have to call is retranslateUi(); which will take care of the actual translation for Qt Designer widgets. For custom widgets you will have to create something similar based on the event.
Related
I've never used QML before and I don't know if the following is even possible at all.
I'm currently porting a C++ Qt Application to Qt 5.5 with existing code and lot of UI files. This application later loads a lot of C++ plugin dll at runtime. Now every plugin should have its own configuration dialog; although none of these plugins currently have a Qt dependency.
I'm currently thinking about extending the interface with something like:
class CPlugin {
public:
virtual std::string const& getQmlDescription() const;
virtual std::string const& getQmlFilePath() const;
};
So every plugin can return a set of QML data on how it wishes it's configuration dialog to look like.
When this plugin should get configured by the user, this application displays an empty QDialog and asks the plugin "give me your qml config data"; which is then rendered and executed inside the empty QDialog.
Can this QML data in terms of a string buffer or a file path to the QML data be interpreted and rendered into a empty QDialog at runtime?
Bottom line:
Can QML be handled like this at runtime?
Can I embed a QML Dialog description inside a traditional QDialog window or does these two types not mix?
Is this even remotely a good idea or should I do a hell lot differently? :)
There's no reason to use a QDialog. You could do it, but a QDialog is rendered using the raster paint engine, and you'd be using the CPU to composite that with the OpenGL frame buffer that Qt Quick renders into. It'd be a bad premature pessimization.
In your scenario, the QML from the plugin would be passed to QQuickView. You will also find that the plugins will need access to the QML engine to set up the context objects to interface C++ to QML, and to register their objects. You can use a global engine instance, and pass it to plugins. Or, to isolate them, use a dedicated engine that only services these plugins.
Qt Quick is flexible in that you are not forced to have the Qt Quick items from the plugins in separate windows. You can set them up in a flickable front-end for mobile devices, dockable front-end for desktop applications, etc. The visual items from the plugins can be instantiated any way you wish - multiple times, inside of other items, etc.
So, it might be a better idea for the plugins to register their visual Item types with the engine, and let your application decide how to use these types, via a Loader, instead of simply passing you raw QML to deal with.
I designed a Qt application by Qt creator. As you well know when you build a new form is possible to drag an drop the default items inside the main window. Instead of use classical "push button" I created a custom button by adding .qml file to the project. The problem now is that I don't know how I can use (or integrate) the new button inside the form of my project.
Thanks in advance
As long as your component is in the path of your application qml files, all you need to use your component is to place it somewhere. You don't need to include or import anything. Any user component is directly available to the entire project.
As long as the QML component is made from only built in components, it can even be safely loaded from arbitrary location on disk, over network or just from a source string. Check this answer for details on dynamic instantiation.
A friendly advice - type the code, do not use the visual editor - it is pretty weak.
EDIT: I don't know about you, but for me, seems like every custom qml file in the project qml folder is automatically added to the QML types in the designer library. So contrary to what I assumed, you shouldn't really need to do anything to get your custom type available for use in the designer.
I found this 1 year-old question when facing the same problem. This is what I found out:
If you save your custom button with an initial uppercase letter (CustomButton.qml instead of customButtom.qml), QtDesigner shows your component in the library panel correctly.
Sometimes you need to restart QtDesigner to work.
I don't do a lot of Qt programming so this may sound like a silly question, but what happened to QListViewItem in qt4?
I have this application I wrote some time ago in qt3. I changed that to qt4 using the aptly name "qt3toqt4" program (all this on a Fedora platform).
Internally it seems to change a lot of classes from QClass to Q3Class (probably to provide some sort of backwards compatibility) and then compile it with qt4. I had some problems with it today (to do with reading stdout from a QProcess, but that aside) and I decided to simply rewrite the application in qt4.
Now for the problem - I use a QListView and to this I add loads of QListViewItems in a tree like structure. Something like this:
But that doesn't seem to be available anymore in qt4. And I can't find any examples that provide this behaviour either. Is there a way to do this in qt4? To maybe make it more complicated - I used my own QListViewItems (derived from QListViewItem) ...
The widget you are looking for in Qt 4 is QListWidget and its item class QListWidgetItem. It pretty much corresponds to the QListView widget in Qt 3 with a classic item-based interface for adding and removing items. You can subclass QListWidgetItem just as you subclassed QListViewItem in Qt 3.
Just to complete this question. It is QTreeWidget and QTreeWidgetItem that implement this behaviour in qt4.
I'm currently trying to get Qt working with my existing program.
I'm using SFML for creating my OpenGL rendering context and creating the window. The things I tried out so far however always create a separate window by Qt instead of just rendering into the existing context.
Is there any way I can force Qt to render to an already existing OpenGL context?
I've not looked into the specifics, but this has been done for openage.
I think looking at the documentation for QQuickRenderControl might be a good place to start.
Qt wants full control over the windows and the event loop, so this will not work (unless you put a lot of effort into it). Your best bet is using a QGLWidget and emulate the event management of SFML with that, so that your application effectively runs on Qt. It is very well possible to render Qt widgets into a OpenGL window (Qt has a OpenGL widget backend) but this must be still managed by Qt itself.
The qt designer portion of qt creator has many built in widgets. But let's say I want to add custom widgets created in the same qt project to the ui file of the window. By taking these steps:
Create a new Qt GUI application with a main window, we'll call the window A.
Add a new widget to the project, the widget just uses standard UI components, say buttons. We'll call this widget B.
Add an instance of widget B to window A.
Now, I know one way to do that, and that is:
In window A, add a blank widget (or widget container, from the containers section of the list of possible widgets. We'll call this widget C.
Promote it (widget C) to widget B.
However, the problem with this is that Qt Creator's designer treats it like a generic QWidget. And as such, you can't do things like add it to a splitter, or connect signals/slots that are specific to the widget.
So is there any other ways to add widget B to window A in the ui file using qt creator? Thank you.
I'm not sure to understood your question well so I could ask the wrong question. Are you sure your "B" widget is a subclass of QDesignerCustomWidgetInterface? This should expose all stuff that your widget/plugin offers...
Last note: a friend of mine tried to add a custom widget like you. And at the end of the described procedure that Lol4t0 told you, he found you must compile plugin with the same compiler with wich qtcreator/designer was compiled. This happens because as we know c++ doesn't keep ABI compability (instead of i.e. C language) stuff like: Name handling can change from compiler to compiler, how data is loaded into registers can change...and so on. My friend tried to compile plugin with mingw, but he found that qtcreator was compiled with visual studio compiler. Therefore if you want to deploy your plugin on Windows or you compile your plugin with visual studio, or you have to compile qtcreator/designer from scratch.
I know this is a very old question, and I'm not sure what capabilities Designer had in 2012, but I came across this in a Google search for something else and figured I'd add some missing info:
However, the problem with this is that Qt Creator's designer treats it like a generic QWidget. And as such, you can't do things like add it to a splitter, or connect signals/slots that are specific to the widget.
Generic QWidgets can be added to splitters with no issues these days.
As far as signals and slots go, you can use them like so:
After promoting a widget to your custom widget, right-click it and choose "Change signals/slots..." from the context menu.
Add the signatures for any custom signals and slots you want to be able to use in Designer / Creator here.
Now those signals and slots will be accessible in Designer like any other signals and slots.
The only thing you can't really get with promoted widgets is access to custom properties in the property panel; for that, yeah, you'll need to go through the custom widget creation process.