xmlgui problem with actions

[Andreas Pakulat]

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.

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

Andreas

-- 
You are a very redundant person, that's what kind of person you are.