xmlgui, DefineGroup vs. MergeLocal

Andreas Pakulat apaku at gmx.de
Tue Oct 13 15:20:52 BST 2009


On 13.10.09 11:46:17, David Faure wrote:
> On Tuesday 15 September 2009, Friedrich W. H. Kossebau wrote:
> > > > >  <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?
> 
> Good point.
> Unit test finally added, works fine, feature is declared official now ;)

Thanks.

> > > > 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?
> 
> Hmm. I see the benefit, this is a way to actually make (some of the) 
> ui_standards.rc merging available to parts (and other guiclients), since it 
> defines merging groups that happen to be exactly where the MergeLocals in 
> ui_standards.rc are ;-)
> Clever; this way we don't really break existing parts, since they have to use 
> group="...." explicitely.
> 
> Doing this automatically is an option; I think it's as simple as adding 
> <DefineGroup>s in ui_standards.rc, under each MergeLocal. Want to try that?

I'll try that over the weekend. Just to make sure I'm testing the right
thing: I'll add a <DefineGroup name="new_group" append="new_merge"/> to
ui_standards.rc and then use that group for an action in kpart and see
wether it shows up in Konqueror along the "New" actions, right?

> > 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.
> 
> I assume the use case would be "giving the host the ability to choose the 
> granularity it wants for the groups, either a few big groups, or a lot of 
> small ones"? Not sure if we need more magic in xmlgui though... :)
> More seriously the real question is how many apps would want to use this.

I don't think it would be used that much, currently ui_standards.rc defines
enough merge points (IMHO) and if the above works as expected there'll be
about the same amount of groups. Hence there should be some group a kpart
can choose to add its actions or the action is really so extra-special that
should appear at the end of the menu. At least I'm pretty sure that
KDevelop doesn't have a need for that.

Andreas

-- 
Perfect day for scrubbing the floor and other exciting things.




More information about the kde-core-devel mailing list