xmlgui, DefineGroup vs. MergeLocal

Friedrich W. H. Kossebau kossebau at kde.org
Tue Sep 15 22:30:37 BST 2009


Hi,

Lundi, le 14 septembre 2009, à 21:36, Andreas Pakulat a écrit:
> 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).

Oh well, it really was all but obvious that these are two different things 
also to me :)

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

But without an append one cannot define where this group is placed in the menu 
in the end. Yet I think one would like to have control about that, no? Can 
this be made an official feature?

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

Why only there? Looking at the ui.rc of KDevelop almost all DefineGroups which 
use an append have the same name for the group as the name of the append 
location.

Now, having to create the same standard groups in all hosts ui.rc files, is 
that what you propose, Andreas? Or should this be rather be done as kind of 
default by the XMLGUI code?

Not directly related, but idea popped up:
And what about using a naming scheme like with the icons, 
group.subgroup.subsubgroup...? An action would fall into the first group 
namespace the XMLGUI host offers. But perhaps this is KDE5 stuff, as any 
separator char might be already in use.

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




More information about the kde-core-devel mailing list