xmlgui problem with actions

[Vladimir Prus]

On Wednesday 18 June 2008 12:40:26 Andreas Pakulat wrote:
> On 18.06.08 12:20:08, Vladimir Prus wrote:
> > On Wednesday 18 June 2008 12:05:53 Andreas Pakulat wrote:
> > > On 18.06.08 10:45:30, Vladimir Prus wrote:
> > > > On Wednesday 18 June 2008 10:33:24 Andreas Pakulat wrote:
> > > > > On 18.06.08 08:52:30, Hamish Rodda wrote:
> > > > > > On Wed, 18 Jun 2008 07:31:15 am Andreas Pakulat wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > it seems that there's a problem with xmlgui and actions, specifically if
> > > > > > > two xmlgui clients provide the same action in their action collection.
> > > > > > > In our case thats Kate and QtDesigner. For some reason the QtDesigner
> > > > > > > action isn't removed from the menu and thus "blocks" the kate action,
> > > > > > > which means the shortcut for saving breaks (as its assigned to
> > > > > > > qtdesigner still).
> > > > > > 
> > > > > > Ugh.
> > > > > > 
> > > > > > > Anybody has an idea how to fix this, without removing the save action
> > > > > > > from qtdesigner plugin? Or should the save action be part of the
> > > > > > > platform and work on any document via public API?
> > > > > > 
> > > > > > Maybe platform level, we have the code for it already.  Sigh, these days 
> > > > > > xmlgui just feels like a big hack.
> > > > > 
> > > > > I've had a quick look last night and the problem really is that the
> > > > > designer actions do not get "unmerged" when designer document goes out
> > > > > of focus. This works just fine for katepart. I'm wondering wether the
> > > > > designer xmlgui client needs to do this itself or wether xmlgui should
> > > > > do this automatically??
> > > > 
> > > > Hmm, isn't Shell::MainWindowPrivate::changeActiveView supposed to do all
> > > > this -- for the case when a view goes out of focus? Ah, could the issue
> > > > be that desigher windows are not xmlguiclients, whereas designer plugin
> > > > itself is? So the actions are never unregistered.
> > > 
> > > Aaah, so I need to provide an xmlguiclient-enabled qt widget as return
> > > value for createViewWidget? That should be documented :)
> > 
> > Well, I think it's the other way around -- a plugin may not be an xmlguiclient.
> > We have major issue with mainwindows already -- since one xmlguiclient can
> > be part of only one main window, if any plugin is xmlguiclient, then its actions
> > can be available in only one main window.
> 
> So you can't use one xmlguiclient in multiple mainwindows? Thats bad.

Well, xmlgui :-)

> 
> > And if plugin cannot be xmlguiclient and you want to contribute actions via
> > xmlgui, it naturally means that a view should be xmlguiclient.
> 
> But what about plugins that don't contribute a view? Like the
> projectmanagerview, or the run-stuff? How do these contribute to the
> menu if they cannot be xmlguiclients?

It's a good question. I think we talked about this with either Alexander, or Hamish,
but I don't remember the final solution. IIRC, the *idea* was that each plugin
has 'createXMLGUIClient' method that gives you an xmlguiclient that can be plugged
into each mainwindow. This is not implemented.

- Volodya