From kde-core-devel Mon Sep 14 19:36:21 2009 From: Andreas Pakulat Date: Mon, 14 Sep 2009 19:36:21 +0000 To: kde-core-devel Subject: Re: xmlgui, DefineGroup vs. MergeLocal Message-Id: <20090914193621.GE23641 () trinity ! apaku ! dnsalias ! org> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=125295703903345 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: > > > > > > > > No, > > [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 for, say the filemenu. Only 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 > and , 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): &File 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 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@trinity:~>grep "append" /usr/local/share/apps/*/*part*rc /usr/local/share/apps/akregator/akregator_part.rc: /usr/local/share/apps/kaddressbook/kaddressbook_part.rc: /usr/local/share/apps/kcontactmanager/kcontactmanager_part.rc: /usr/local/share/apps/kcontactmanager/kcontactmanager_part.rc: /usr/local/share/apps/kcontactmanager/kcontactmanager_part.rc: /usr/local/share/apps/kmail/kmail_part.rc: /usr/local/share/apps/kmail/kmail_part.rc: /usr/local/share/apps/kmail/kmail_part.rc: /usr/local/share/apps/korganizer/korganizer_part.rc: /usr/local/share/apps/korganizer/korganizer_part.rc: /usr/local/share/apps/korganizer/korganizer_part.rc: /usr/local/share/apps/korganizer/korganizer_part.rc: &Sidebar /usr/local/share/apps/korganizer/korganizer_part.rc: /usr/local/share/apps/korganizer/korganizer_part.rc: /usr/local/share/apps/korganizer/korganizer_part.rc: /usr/local/share/apps/korganizer/korganizer_part.rc: /usr/local/share/apps/korganizer/korganizer_part.rc: /usr/local/share/apps/oktetapart/oktetapartbrowserui.rc: /usr/local/share/apps/oktetapart/oktetapartbrowserui.rc: /usr/local/share/apps/oktetapart/oktetapartbrowserui.rc: 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 tag, just as if the action had > no group attribute. Ok, I guess that I've already explained what happens if there's no 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.