Some code that exposes two custom widgets to Qt Designer or Qt Creator's designer tab.
See task T8462
Details
Details
- Apply patch
- Build
- Create a directory with a "designer" subdirectory somewhere, e.g.~/qt_plugins/designer
- Copy resulting build/plugins/qt/designer/kritadesignerplugin to the previously created "designer" directory
- Launch Qt Creator or Qt Designer with QT_PLUGIN_PATH set to the root directory you created in step 3, e.g. QT_PLUGIN_PATH=~/qt_plugins qtcreator
- Open an .ui file with either of the exposed widgets, e.g. wdg_level.ui
- The custom widgets should now be available in the widget list under "Krita", and should be rendered properly in the designer view
Diff Detail
Diff Detail
- Repository
- R37 Krita
- Lint
Lint Skipped - Unit
Unit Tests Skipped
| plugins/qt/designer/CMakeLists.txt | ||
|---|---|---|
| 14 | The library should be installed somewhere. I don't know if we want to install it in the Qt install folder though, and if we install it somewhere else, the user has to manually tell Qt Creator where that is on startup anyway. Personally I start Qt Creator with a custom path where all my local plugins reside. Maybe we should expose a custom define for this? | |
| 16 | I haven't checked how this is all set up. I wouldn't be surprised if we run into linking issues for more advanced widgets. Note that Qt Designer has to be able to use this library outside of Krita, so if it dynamically links to other libraries then they need to either be in a system search path or (under Linux) included in LD_LIBRARY_PATH before starting Qt Designer or Qt Creator. | |
| plugins/qt/designer/KisColorSpaceSelectorPlugin.cpp | ||
| 44 | This should create an return an instance of the widget this plugin is intended for. Depending on the widget and plugin type, we might also want to connect some signals so Qt Designer can react to certain changes. | |
| 49 | This shows up in the Designer's widget list | |
| 54 | This places the widget under a specific label. We could have all widgets placed under the same label, or we could split them based on type if it becomes too crowded. | |
| 59 | An empty icon will be replaced by the default Qt widget icon (Qt logo) in the Designer's widget list. It could be worth creating custom icons for a better visual overview when more widgets have been added. | |
| 64 | Should some other translation mechanism be used? Does it matter? This is the tooltip you get if you mouse-over the widget in the Designer's widget list. | |
| 69 | Extended help text. I think it's shown if you use the desktop environment's "?" button and click on the widget in the Designer's widget list. | |
| 74 | A container widget is a widget that is intended to hold other widgets, e.g. QGroupBox. This is not such a widget, so we return false here. | |
| 79 | These are default values for a new instance, i.e. what gets set when you drag a widget from the Designer's widget list to the form. Normally we just need to change the class and name values here. It might also be a good idea to set width and height to something sensibly, so the widget can be interacted with if it's dropped onto a surface without a layout. | |
| plugins/qt/designer/KisColorSpaceSelectorPlugin.h | ||
| 22 | This is all boiler plate, and can be copied almost verbatim for each plugin. | |
Comment Actions
Note that I've only tested this under Linux (Ubuntu 17.10). There are quite a few gotchas for Windows, which requires that the plugin is compiled under similar conditions as Qt Designer itself. See https://doc.qt.io/qtcreator/adding-plugins.html#matching-build-keys
| plugins/qt/designer/KritaDesignerPluginCollection.cpp | ||
|---|---|---|
| 28 | New widgets have to be added here, or they won't show up in the Designer's widget list. | |