Improving generic KPart support in KDevelop (by example of Okteta)

[Friedrich W. H. Kossebau]

Hi Andreas,

Mardi, le 4 août 2009, à 14:54, Andreas Pakulat a écrit:
> On 04.08.09 14:35:20, Friedrich W. H. Kossebau wrote:
> > Bug: Usage of groups in XMLGUI
> > ------------------------------
> > What is the reason for all the grouping with e.g. "<DefineGroup
> > append="new_merge" name="new_merge"/>" in kdevelopui.rc?
> > This breaks proper integration of all non-Kate KParts.
> >
> > Just load an image and
> > see "Save As..." and "Properties" added as last items to the "File" menu
> > instead of where "ui_standards.rc" would place them. I for now "fixed"
> > the oktetapartreadwriteui.rc file by also making use of the groups, but
> > this is KDevelop-specific and a broken hack.
>
> Groups are a supported feature of xmlgui and allows us to keep control over
> where exactly actions from loaded kparts are shown in the menu. IMHO kparts
> not using groups are just broken, even ui_standard.rc supports groups as
> far as I understand (with those MergeLocal name="...." stuff) and thats
> where most of our group names from from.

But I wonder if groups are needed here? What is different here from e.g.
the other big kpart-using program, Konqueror*? There those groups aren't 
(re-)defined, and all actions smoothly integrate as defined in ui_standard.rc

E.g. the image KPart (don't know which one is it) creates a 
standard "file_save_as" action. In ui_standard.rc the place of this action is 
defined. But in KDevelop it does not appear there or anywhere near the save 
actions, but at the end of the menu. This might be a bug in XMLGUI, but then 
I also still do not understand what 
	<DefineGroup append="save_merge" name="save_merge"/>
exactly adds? There is a
	<MergeLocal name="save_merge"/>
in ui_standard.rc, so all actions other than standard actions just have to be 
given as
	<Action name="file_my_crazy_save" append="save_merge"/>
in your apps/parts ui.rc file, so they appear in that area. Why doesn't this 
work for KDevelop, too?

Effectively this breaks integration of all KParts in KDevelop which rely on 
ui_standard.rc and happily integrate in Konqueror. And to be honest, with 
Konqueror the testing ground for KParts I suspect it is Konqueror which does 
it the wrong way ;)

* 
http://websvn.kde.org/trunk/KDE/kdebase/apps/konqueror/src/konqueror.rc?view=markup

> > Bug: Save/Revert for ReadWriteParts
> > -----------------------------------
> > Are there any reasons save/revert actions are not offered out of the box
> > for ReadWriteParts in KDevelop?
> > A KPart::ReadWritePart implements both a "save()" and a "saveAs(const
> > KUrl&)" method. So I would have expected that KDevelop itself sets up
> > these actions. But it doesn't. And it also doesn't include them in the
> > actions "Save All" and "Revert All". Not what is expected :)
>
> We don't support read/write parts currently, thats all. PartDocument would
> need to be extended to support both read/write as well as read-only parts.

I will see what can be done. Looks like the basic infrastructure is all in 
place, just needs some wiring up. But then I haven't yet looked under all 
stones.

> > Feature: Embedded tool views
> > ----------------------------
> > How to support tools which have a small control/tool view that is
> > embedded and not a dialog?
>
> You'll need to leave the kparts approach and write a kdevelop plugin to do
> this. There's no way to have kparts create toolviews. As a start look at
> the designer plugin in playground/devtools/kdevelop4-extra-plugin. It tries
> to integrate Qt designer into kdevelop by providing a custom document type
> and toolviews that interact with each other.

Thanks for the pointer. Hm. Will take a look this afterwards, once the generic 
KPart support works for me :)

> > Feature: Statusbar items
> > ------------------------
> > Could there be an option to show statusbar items like the KPart has for
> > row/column?
>
> Same as the one above, with a kdevelop plugin this will just work.
>
> > What do you think? Who of you works on these parts of KDevelop? For a
> > start, where would I need to look to solve the Save/Revert problem?
>
> kdevplatform/shell/partdocument.cpp.

So I have to make my own hands dirty, oh well, was to be expected ;) 

Have started to look around. I hope it's okay that I directly commit all the 
little fixes for things that I see while trying to grasp how things are 
working. For bigger changes involving logic/behaviour (like adding support 
for write of PartDocuments) I will of course use the reviewboard.

Cheers
Friedrich
-- 
Okteta - KDE 4 Hex Editor - http://utils.kde.org/projects/okteta