xmlgui, DefineGroup vs. MergeLocal

[David Faure]

On Sunday 09 August 2009, Andreas Pakulat wrote:
> On 08.08.09 18:56:52, David Faure wrote:
> > I see much confusion in this thread ;)
> >
> > Please do not confuse the two merging features:
> > * the merging of the application's xmlgui file with ui_standards.rc,
> > which uses MergeLocal (in ui_standards.rc) and the append and noMerge
> > attributes (in the application's xmlgui file)
> > and
> > * the merging of xmlguiclients (like parts) into the application
> > (the xmlguifactory, more precisely),
> > which uses Merge and DefineGroup (in the host), and the group attribute
> > (in the part).
> >
> > The reasons for this mess of two-different-kinds-of-merging are
> > historical -- Kurt was young ;).
> > I wanted to merge them (hehe) for kde-4, but this didn't happen.
> >
> > Please note that ui_standards.rc merging is not available for kparts
> > (this was also on the todo list for kde4, now for kde5; cf the "More long
> > term" section in the old kdeui/TODO.xmlgui).
> 
> Ok, so if I understand this correctly an app having:
> 
> <Menu name="File">
>  <DefineGroup append="new_merge" group="new_merge"/>

No, <DefineGroup name="new_merge"/>

[MergeGroup or even just Merge would be such a better name...]

>  <Action name="app_new_file" append="new_merge" />
> </Menu>
> 
> should be able to load properly written xmlgui clients that use
> 
> <Menu name="File">
>   <Action name="client_new_file" group="new_merge" />
> </Menu>

Yes. Unit-tested now, r1023244 in kdelibs/kdeui/tests/kxmlgui_unittest.cpp

> If thats correct, then:
> 
> a) Konquerors application xmlgui-rc file is broken as it doesn't define
> groups (well it defines some, but clearly not as many as it should given
> that its supposed to be able to embed any kpart)

Can you give examples of which groups you would expect konqueror to define,
in which menus?

The downside is making menus even more "jumpy". E.g. I expect that the File
menu contains the same first 7 actions no matter what the current part is,
otherwise it gets confusing, and the rest below that is already using <Merge>
and <DefineGroup>, maybe there's just one DefineGroup missing before Quit?
I guess I need concrete examples. Otherwise I would say that intuitively, it
makes sense that generic konq actions are separated from part-specific actions,
e.g. View Mode / Link to current location / Link view should stay together in 
the View menu, etc.

The other downside of this whole mechanism is of course that a part is 
supposed to be useable in other hosts than konqueror, and if those other hosts 
don't define the same merging groups you end up with unexpected ordering...
But ok, that's fixable if we define proper groups in konqueror and others apps 
follow the same naming, for example.

> b) most xmlgui clients in svn currently use append instead of group for
> their actions

Really?? unless I'm wrong, append does _nothing_ for parts.
It only works for "mainwindow" rc files, those that get merged with 
ui_standards.rc

> The latter unfortunately means that embedding such a kpart into a "properly
> written" host application adds all those actions onto the end of the menu
> instead of at the proper MergeLocal positions defined by ui_standards.rc.

Yes, so they use the wrong attribute, one that points to an unsupported 
merging mechanism (no ui_standards.rc merging for parts), and no wonder, it 
doesn't work ;)

> My main question is: How to fix this, I'm up for trying to find all kparts
> in at least trunk+extragear and fix them to use group instead. However I
> have no idea what happens then when the host doesn't provide a group with
> that name.

New question, new unittest :-)

As I expected: it then puts it into the <Merge> tag, just as if the action had
no group attribute.

-- 
David Faure, faure at kde.org, sponsored by Nokia to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).