xmlgui, DefineGroup vs. MergeLocal

[Andreas Pakulat]

On 14.09.09 12:31:27, David Faure wrote:
> 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...]

Ok, but the append probably didn't cause any problems. One thing thats
unclear: What happens to actions if I don't have a <Merge /> for, say
the filemenu. Only <DefineGroup/> elements? Are they simply appended or
are they not shown at all?

> > 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.

Ok, after some playing around I'm pretty convinced that its not
KDevelop's fault. It really is that we need to define some groups
"globally" within kde that parts can re-use similar to the mergelocal's
in ui_standards.rc.

As concrete example, lets take KDevelops File menu (just ignore the
append's):
  <Menu name="file">
    <text context="@title:menu">&File</text>
    <DefineGroup append="new_merge" name="new_merge"/>
    <DefineGroup append="open_merge" name="open_merge"/>
    <DefineGroup append="save_merge" name="save_merge"/>
    <DefineGroup append="revert_merge" name="revert_merge"/>
    <DefineGroup append="print_merge" name="print_merge"/>
    <Action name="file_closeother" append="close_merge"/>
    <DefineGroup append="close_merge" name="close_merge"/>
  </Menu>

Now if KDevelop loads a kpart that doesn't use any of these groups and
just "dumps" its actions into the file menu, then they're added _after_
the quit action at the end of the menu.

That could be fixed with a <Merge/> tag, but the question is where to
put that merge tag. Basically if a kpart has a save and a special close
action I'd like to have either in the apropriate group as opposed to
being just "somewhere at the end, but before quit". Konqueror doesn't
have this problem so much as its "always" embedding something and can
live with the fact that all the actions from the 'something' are behind
its own ones.

> 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.

Ok, please lets do that, as I said before I'm up for fixing up kparts in
trunk/ as we go along. So we just need to find the "common" groupnames
for the usual menus. How about the following:

We stick to ui_standards.rc here and simply take over the merge's from
there and create similar named groups by replacing the _merge with
_group? Of course only those that make sense in the scope of konqueror.

> > 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

Well, I guess not "most", but some:
andreas at trinity:~>grep "append" /usr/local/share/apps/*/*part*rc
/usr/local/share/apps/akregator/akregator_part.rc:      <DefineGroup append="top_merge" name="top_merge" />
/usr/local/share/apps/kaddressbook/kaddressbook_part.rc:      <Action name="edit_delete" append="edit_paste_merge"/>
/usr/local/share/apps/kcontactmanager/kcontactmanager_part.rc:      <Action name="akonadi_paste" append="edit_paste_merge"/>
/usr/local/share/apps/kcontactmanager/kcontactmanager_part.rc:      <Action name="akonadi_item_copy" append="edit_copy_merge"/>
/usr/local/share/apps/kcontactmanager/kcontactmanager_part.rc:      <Action name="akonadi_item_delete" append="edit_delete_merge"/>
/usr/local/share/apps/kmail/kmail_part.rc:   <Action name="filter" append="save_merge"/>
/usr/local/share/apps/kmail/kmail_part.rc:   <Action name="popFilter" append="save_merge"/>
/usr/local/share/apps/kmail/kmail_part.rc:   <Action name="sieveFilters" append="save_merge"/>
/usr/local/share/apps/korganizer/korganizer_part.rc:      <Action name="print_setup" append="print_merge"/>
/usr/local/share/apps/korganizer/korganizer_part.rc:      <Action name="edit_delete" append="edit_paste_merge"/>
/usr/local/share/apps/korganizer/korganizer_part.rc:      <Action name="filter_select" append="save_merge"/>
/usr/local/share/apps/korganizer/korganizer_part.rc:      <Menu name="sidebar" append="show_merge"><text>&Sidebar</text>
/usr/local/share/apps/korganizer/korganizer_part.rc:        <Action name="show_resourcebuttons" append="show_merge"/>
/usr/local/share/apps/korganizer/korganizer_part.rc:      <Action name="conf_datetime" append="save_merge"/>
/usr/local/share/apps/korganizer/korganizer_part.rc:      <Action name="conf_resources" append="save_merge"/>
/usr/local/share/apps/korganizer/korganizer_part.rc:      <Action name="edit_filters" append="save_merge"/>
/usr/local/share/apps/korganizer/korganizer_part.rc:      <Action name="edit_categories" append="save_merge"/>
/usr/local/share/apps/oktetapart/oktetapartbrowserui.rc:    <Action name="export" append="save_merge" />
/usr/local/share/apps/oktetapart/oktetapartbrowserui.rc:    <Action name="copy_as" append="edit_paste_merge" />
/usr/local/share/apps/oktetapart/oktetapartbrowserui.rc:    <Action name="edit_select" append="edit_select_merge" />

The last one was the initial reason the whole discussion started :)

> > 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.

Ok, I guess that I've already explained what happens if there's no
<Merge/> tag to myself above :)

Thanks a lot for your insights, make some things a lot clearer.

Oh, btw, while we're at it any idea why deregistering an xmlgui client
and then later on re-registering it puts all its actions at the _end_ of
the relevant menu, instead of in the "middle" where the group is into
which the actions belong?

Andreas

-- 
You never know how many friends you have until you rent a house on the beach.