Discussion:
[kdevqtdesigner] Help to port kdevqtdesigner in to KDevelop 5
Πέτρος Σιλιγκούνας
2018-10-16 15:36:52 UTC
Permalink
You can see here [1] the latest changes. I am getting linker's errors about
some functions that are unimplemented. I ported most of the code base to
newer C++ and Qt5 but I don't know where to go from here.

Any help would be appreciated.

[1] https://github.com/Petross404/kdevqtdesigner/compare/testing
Aleix Pol
2018-10-16 22:40:32 UTC
Permalink
You can see here [1] the latest changes. I am getting linker's errors about some functions that are unimplemented. I ported most of the code base to newer C++ and Qt5 but I don't know where to go from here.
Any help would be appreciated.
[1] https://github.com/Petross404/kdevqtdesigner/compare/testing
If there's things you would like to help with in KDevelop, we can
discuss, but I'd suggest not to push Qt Designer further into
KDevelop. We had it working and nobody was really impressed with what
put on the table and that's why we discontinued it.

Looking forward to working with you!
Aleix
Friedrich W. H. Kossebau
2018-10-17 02:21:18 UTC
Permalink
This post might be inappropriate. Click to display it.
Πέτρος Σιλιγκούνας
2018-10-17 05:25:19 UTC
Permalink
Thank you very much, I will try to accomplish this.
Hi Πέτρος,
Post by Πέτρος Σιλιγκούνας
You can see here [1] the latest changes. I am getting linker's errors
about
Post by Πέτρος Σιλιγκούνας
some functions that are unimplemented. I ported most of the code base to
newer C++ and Qt5 but I don't know where to go from here.
Any help would be appreciated.
Nice to see you are still seeing to scratch your itch here, as started last
December (
https://frinring.wordpress.com/2017/09/08/in-pane-preview-of-qt-ui-files-with-kuiviewer-coming-up/#comment-5689
).
Sadly myself I currently have no time to really help with any
implementation,
but let me at least point you to some building and linking initial code of a
reimplementation of the qtdesigner integration plugin. Which I had started
this spring, but then did not pursue more so far as it was low priority.
The code builds and links against current KDevelop, and I pushed that now in a
https://cgit.kde.org/scratch/kossebau/kdevqtdesigner.git (web UI)
The code so far only works for registering a custom document/view handler for
Qt Designer files, and itself only can load and show files.
As you found out, the Qt Designer library still exists in Qt5, e.g. is also
consumed in Qt Creator. Sadly though the interface has changed a bit, a
library Qt5DesignerComponent has been split off which has no proper CMake
Config files yet (see also comment in src/CMakeLists.txt). That needs filing a
bug and fixing in Qt, as well as writing some workaround cmake code in the
plugin to handle that properly (I only did a simple hack that worked for
me(tm)).
IIRC the code of the old qtdesigner plugin had some broken support for the
multi-view feature of kdevelop, the implementation would only work if people
did not do split views and have multiple views on the same UI file. My
reimplementation should have also deal with that, by having some intermediae
QBuffer object in the document, to which the views should then sync their
data. That syncing part is missing also yet, only sketched in my mind. :)
Another issue with the plugin is that in KDevelop/KDevPlatform switching
between text editor view and custom editor view seems broken meanwhile and not
possible for the same file, something has regressed in kdevplatform when it
comes to that feature over what I think to remember from kdevelop4. So once
the plugin is active, one currently no longer can edit UI files as plain text,
only be the plugin.
Personally as before I would like to see more non-text editor integration in
KDevelop, but seems current maintainers have no own needs here, so not pushing
myself into that direction :) and concentrating on other features which seem
more agreed about.
Though then KDevelop is plugin-based, and perhaps we can manage to fix the
core in a way, that the qtdesigner integration plugin can be made nicely work
and still maintained externally, without getting in the way of the maintainers
who are not interested in it :)
BTW: this mailinglist "kdevelop" is for users of KDevelop rather, you might
this email there, please subscribe to that mailinglist and continue
implementation discussion there.
In any case is this a bigger challenge you chose to master here, with lots of
hurdles. So hopefully you have good energies :) As said, myself will not have
time left to help you a lot, my KDevelop TODO list is full of own interest
things. Perhaps you find some other people here who will be happy to join your
existing effort for such a qtdesigner integration plugin?
Next to the code of the old plugin, some place which might hold some ideas for
you is the Designer-based plugin for Qt Creator, you can nicely browse the
https://code.woboq.org/qt5/qt-creator/src/plugins/designer/
That might help in case more API has changed for Qt5. But this is really
challenging stuff, given some of the Designer(Component) API used is also
private and might break between minor Qt versions. Really no free lunch here.
Good luck, lots to learn, you will be a Qt expert afterwards :)
Cheers
Friedrich
René J.V. Bertin
2018-10-17 08:04:08 UTC
Permalink
On Wednesday October 17 2018 04:21:18 Friedrich W. H. Kossebau wrote:

Hi,
Post by Friedrich W. H. Kossebau
Another issue with the plugin is that in KDevelop/KDevPlatform switching
between text editor view and custom editor view seems broken meanwhile and not
possible for the same file, something has regressed in kdevplatform when it
comes to that feature over what I think to remember from kdevelop4. So once
the plugin is active, one currently no longer can edit UI files as plain text,
only be the plugin.
This rings a bell, I have definitely seen behaviour like that in KDevelop (probably v4, possibly with other doc types too).
Post by Friedrich W. H. Kossebau
Personally as before I would like to see more non-text editor integration in
KDevelop, but seems current maintainers have no own needs here, so not pushing
My 2 cents:

Honestly I think I agree with Aleix here. KDevelop already has a large list of plugins which are built and installed and loaded by default, many of which are probably unused or even irrelevant much of the time for lots of users. But they do consume resources, and that's something KDevelop already does extremely well for its core functionality.

Better and more integration is always nice but it can also be done with external applications, like my own mod which allows opening Qt help documentation links in an external viewer, or the ZealSearch plugin. This also has the advantage that you can put the 2 (or more) views as you want on your screen(s) and don't have to switch back and forth between tabs inside a single application.

Apple's Xcode IDE has suffered from the same integration drive; before v4 it was relatively lightweight and only contained a doc viewer which could sadly not be run separately; the UI editor/designer was a separate app as were a number of the analytic instruments. Now everything is included in a single monolithic application which, as a result, takes a lot longer to start and a lot more resources to run.

What I do miss in KF5 is the kuiviewer which apparently didn't get ported and which was very handy to take a quick (and cheap) peek at .ui files without having to fire up a more cumbersome editor. Wouldn't porting that and giving it a kpart design allow sufficient integration at least for previewing .ui files? Note that I'd still prefer to use the external application if the kpart were to reuse the main KDevelop window instead of a dedicated window that would show the UI more like it would appear in the target application.

R
Friedrich W. H. Kossebau
2018-10-17 11:06:19 UTC
Permalink
Post by René J.V. Bertin
Post by Friedrich W. H. Kossebau
Personally as before I would like to see more non-text editor integration
in KDevelop, but seems current maintainers have no own needs here, so not
pushing
Honestly I think I agree with Aleix here. KDevelop already has a large list
of plugins which are built and installed and loaded by default, many of
which are probably unused or even irrelevant much of the time for lots of
users.
That is why plugins can be disabled if one does not use them.
Settings->Configure KDevelop...->Plugins, there disable all those you
personally do not need, by untoggling the checkbox of a plugin listed.

Like with e.g. rich text document editors, everyone uses a different 20 % of
the features available.
Post by René J.V. Bertin
What I do miss in KF5 is the kuiviewer which apparently didn't get ported
and which was very handy to take a quick (and cheap) peek at .ui files
without having to fire up a more cumbersome editor. Wouldn't porting that
and giving it a kpart design allow sufficient integration at least for
previewing .ui files?
Miss it some more, and once you miss it enough to start researching the state,
you will find that it got ported, that it had been done as KPart technology
since the very start, and that as before you can use it inside KDevelop5.

And obviously some people who are into it find it not a good enough solution.

Not only because KParts with their single-view/single-document principle do
not match the multi-view design (kparts: multiple view -> multiple document
working copies), but also e.g. do not integrate with the statusbar (instead
trigger the "normal" QMainWindow one to be shown for the rest of the kdevelop
instance runtime).
And switching between a KPart-based display and the text editor display is not
directly possible, once has to open and close the views, also cannot show them
in parallel.

Given you like external things, here a link to some external blog post:
https://frinring.wordpress.com/2017/09/08/in-pane-preview-of-qt-ui-files-with-kuiviewer-coming-up/
(already linked in my first email, as this is where the discussion about the
qt desginer plugin revival started)

This might give you an idea how much some people are unpleased with the
current workflow options available. Everyone has different needs.

And yes, that preview ktexteditor plugin sadly turned out to be not perfect,
as KXMLGUI is no-where prepared for having components with rivaling shortcuts,
like one gets from the average KParts plugin. Actually an issue we have in
KDevelop as well with richer toolviews.
So it's currently in a limbo state, and I have a remove-feature patch prepared
locally for kate to remove that preview plugin again, as the shortcut thingie
is too much in the way. I stopped to use the plugin for this very reason, and
chance is everyone else did, too (besides some other principal and bug
triggering issues).

Someone (tm) needs to fix the middle-ware :)

Cheers
Friedrich
René J.V. Bertin
2018-10-17 12:50:34 UTC
Permalink
Post by Friedrich W. H. Kossebau
That is why plugins can be disabled if one does not use them.
Settings->Configure KDevelop...->Plugins, there disable all those you
personally do not need, by untoggling the checkbox of a plugin listed.
Yeah, but it's never really clear which plugins are enabled when you start a new session, and AFAIK it isn't really possible either to unload plugins.
More plugins also means longer build times if they cannot be (de)selected at that level.

Qt Creator has a -noload option to disable loading of specific plugins at startup; I don't KDevelop has something similar, correct?
Post by Friedrich W. H. Kossebau
Miss it some more, and once you miss it enough to start researching the state,
you will find that it got ported, that it had been done as KPart technology
Ah, indeed. I missed that, but then I've been keeping my KDE4 desktop and kuiviewer4 works just fine as a standalone viewer :)
Post by Friedrich W. H. Kossebau
Not only because KParts with their single-view/single-document principle do
Can't you create a new, dedicated window and hand that to the KPart?
Post by Friedrich W. H. Kossebau
current workflow options available. Everyone has different needs.
Yep, and you also cannot cater to everyone...

R
Kevin Funk
2018-10-18 05:44:59 UTC
Permalink
Post by René J.V. Bertin
Post by Friedrich W. H. Kossebau
That is why plugins can be disabled if one does not use them.
Settings->Configure KDevelop...->Plugins, there disable all those you
personally do not need, by untoggling the checkbox of a plugin listed.
Yeah, but it's never really clear which plugins are enabled when you start a
new session, and AFAIK it isn't really possible either to unload plugins.
More plugins also means longer build times if they cannot be (de)selected at that level.
Qt Creator has a -noload option to disable loading of specific plugins at
startup; I don't KDevelop has something similar, correct?
It has, in form of a env variable you can set:
export KDEV_DISABLE_PLUGINS=$PLUGIN_ID

Example:
export KDEV_DISABLE_PLUGINS=KDevWelcomePage

... or multiple ones:
export KDEV_DISABLE_PLUGINS=KDevWelcomePage;$OTHER_PLUGIN_ID

Wouldn't mind having sth similar as QtC's -noload in KDevelop, though. Patches
welcome, I guess. This one should be relatively trivial.

Regards,
Kevin
Post by René J.V. Bertin
Post by Friedrich W. H. Kossebau
Miss it some more, and once you miss it enough to start researching the
state, you will find that it got ported, that it had been done as KPart
technology
Ah, indeed. I missed that, but then I've been keeping my KDE4 desktop and
kuiviewer4 works just fine as a standalone viewer :)
Post by Friedrich W. H. Kossebau
Not only because KParts with their single-view/single-document principle do
Can't you create a new, dedicated window and hand that to the KPart?
Post by Friedrich W. H. Kossebau
current workflow options available. Everyone has different needs.
Yep, and you also cannot cater to everyone...
R
--
Kevin Funk | ***@kde.org | http://kfunk.org
Loading...