The “Live Preview” plugin for the editors/IDEs Kate & KDevelop (see introduction) makes use of KParts plugins to support different file formats. Thus it can also pick up the range of existing KParts implementations out there right from the start.
A perfect user experience with the “Live Preview” plugin means:
- automatic updates of the preview while one edits the sources, without a reset of the preview settings (scroll position, zoom state, etc.)
- not going through the file system to push changes in the sources to the preview
For that usually some more work needs to be done to the existing KParts plugins.
Editing in the Qt UI file worlds
One of those plugins, where I also have personal interest in and thus giving priority, is the KParts plugin from the KUIViewer, a tool to display and check Qt user interface (*.ui) files. Because in the recent time I have edited Qt UI files quite often and started to do this manually directly in the XML-based sources instead of in Qt Designer, as it became quicker to do for me the more I had learned the syntax. But for checking the current state I still had to save the file and load it separately in Designer or KUIViewer.
So the KUIViewer KParts plugin and the “Live Preview” plugin for KDevelop have started to improve my developer life 🙂
“Containers” for the rescue, once more
Besides some pain points though: if you used KUIViewer yourself before, you might remember that its code was operating straight forward. For one it instantiated any UI file as-is, e.g. showed a QMainWindow-based UI also as normal separate window in the workspace, so not embedded in the window of KUIViewer itself. Which comes at least as surprise, if not as something unhandy. Especially for the use with the “Live Preview” plugin, where the automatic update of the preview and thus the reloading of the UI file in the KUIViewer code means windows coming and going all the time.
Then normal widgets were shown as main widget of the KUIViewer window, which for very big or very small widgets result in according changes to the window and broken display in the “Live Preview” plugin.
Too much pain, and then I was looking at the sources anyway. So while extending the KUIViewer KParts plugin to implement the streaming API and restoring/keeping the view state on reloading from the same URL, I also reached out for the class QMdiArea for the rescue and changed KUIViewer to show the object defined by a UI file as a subwindow instead. And that way allowing widgets to have any sizes, but also taming QMainWindow-based UI to not escape the KUIViewer scene:
This change will be coming to everyone as part of KDE Applications 17.12.
And thanks to the respective code being in the KUIViewer KParts plugin, without any further changes we get the same tamed behaviour in the “Live Preview” plugin:
Improve your favourite KParts plugin for the “Live Preview”
If you edit some other sources often and want to be supported by the “Live Preview” plugin, get and build the plugin quickly yourself, the current state works good enough.
Then see if there is a matching KParts plugin you then can improve as needed.
The “Live Preview” plugin is currently planned to be released as official part of KDE Applications 17.12 and later as well, possibly as part of the Kate repo. So a few months left to shape up your favourite KParts plugin. Go for it now to be done in time 🙂
Awesome !
That’s really a great job !
[…] In-pane preview of Qt UI files with KUIViewer coming up […]
This is so cool… can’t wait to see this evolve with other previewable formats, like Markdown, YAML, etc.
[…] KParts plugins have already seen such adaptions, like the SVGPart and the KUIViewerPart (see also blog post), adaptions to be released with KDE Applications 17.12. Another KParts plugin has been written with […]
[…] KParts plugins have already seen such adaptions, like the SVGPart and the KUIViewerPart (see also blog post), adaptions to be released with KDE Applications 17.12. Another KParts plugin has been written with […]
[…] KParts plugins have already seen such adaptions, like the SVGPart and the KUIViewerPart (see also blog post), adaptions to be released with KDE Applications 17.12. Another KParts plugin has been written with […]
This is still a preview of the .ui, right? I mean you can’t directly put widgets and stuff like qtdesigner, you have to edit the ui and preview what is looks like if I am correct.
It would be super handy to be able to create and edit windows, buttons etc like qtdesigner from within KDevelop. A plugin maybe could do the job.
Yes, it’s a “read-only” preview, no editing of the UI possible.
I agree it would be nice to have Designer-integration in KDevelop again. IIRC in older versions of KDevelop there was such an integration based on the Designer libs, but no-one of the active contributors cared enough to maintain and/or port it to newer Qt versions, so it got dropped.
So this task is waiting for some new contributor 🙂
Any tutorial or help about plugins in kdevelop? I world like to give it a try
There is some (possibly slightly outdated) introduction into kdevplatform design at
https://api.kde.org/extragear-api/kdevelop-apidocs/kdevelop/kdevplatform/html/architecture.html
To start your plugin, there is an app template for kdevelop plugins you can use (find in KDevelop by menu “Project” > “New From Template…”). One usually develops their plugin in an own repository, until it has matured enough to be merged into the kdevelop repo.
For a current example of supporting another editor component, there is the hexeditor plugin to serve as inspiration: https://cgit.kde.org/kdevelop.git/tree/plugins/okteta
And I just found the old version of the Qt Designer plugin, still in svn:
https://websvn.kde.org/tags/unmaintained/4/kdevelop4-extra-plugins/qtdesigner/ (updated, got moved)
Thank you. It seems quite challenging for me but during xmas holidays I will begin to read the code
I am trying to port kdevqtdesigner to KDevelop 5 here : https://github.com/Petross404/kdevqtdesigner
So far I managed to port only the CMakeLists.txt and fix some qt4 related errors about missing or deprecated headers.
I would be more than glad to see c&c and/or pull requests! Feel free to contact me.
Good to see! Every journey starts with some small steps. congrats to have your first done 🙂
Myself have lots on stuff on my plate, but might see to look at this perhaps around End of Year.