[kdevqtdesigner] Help to port kdevqtdesigner in to KDevelop 5

Friedrich W. H. Kossebau kossebau at kde.org
Wed Oct 17 12:06:19 BST 2018

Am Mittwoch, 17. Oktober 2018, 10:04:08 CEST schrieb René J.V. Bertin:
> On Wednesday October 17 2018 04:21:18 Friedrich W. H. Kossebau wrote:
> >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.

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.

> 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:
(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 :)


More information about the KDevelop mailing list