[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: The future of KAction
From:       Simon Hausmann <hausmann () kde ! org>
Date:       2005-11-21 6:19:43
Message-ID: 200511210719.44024.hausmann () kde ! org
[Download RAW message or body]

On Saturday 19 November 2005 13:25, Alexander Dymo wrote:
> On Saturday 19 November 2005 12:55, Simon Hausmann wrote:
> > > bool MyWindow::actionFilter(KAction *action, const QString &menu,
> > > 	const QString &group)
> > > {
> > > 	if (menu == "settings")
> > > 		return false;
> > > 	else if ((menu == "view") && (group == "navigation"))
> > > 	{
> > > 		if (action->objectName() == "go back")
> > > 			return false;
> > > 		return true;
> > > 	}
> > > 	return true;
> > > }
> >
> > I think it would be a lot easier to just make addActionGroup on the
> > plugin's side do nothing if the action group is not defined. The
> > application can then decide whether to provide such a placeholder or not.
>
> Yes, that would be easier to do but we already have smth similar with xml
> files and that's not flexible enough.
>
> Let's take a look at KDevelop + embedded Kate problem.
>
> Kate defines 26 actions and separators for the "tools_operations" group
> under the "tools" menu. There's nothing wrong with that but for KDevelop
> we don't need several actions, say "set_filetype", "tools_uppercase", etc.
> They are in the same group but we'd still want to remove them from the GUI.
> That's why I propose we have an actionFilter(). Usually it will not be
> used, group filtering will just work for most cases. But I can see some
> applications like KDevelop and Quanta using action filters.

To me filtering actions sounds like a last-resort where you attempt to avoid 
an ackward GUI by some heuristics by looking at the name of actions. Let kate 
rename the actions and your problem is back :)

To me it seems easier and cleaner by letting kdevelop not provide those 
placeholders (action groups) in the first place and making sure kate uses the 
same groups as kdevelop. You will have to talk to the kate developers, I see 
no way around it. But I heard they're friendly people :)

With blacklisting you have to adjust kdevelop to the latest kate version to 
make sure the integration looks nice and with whitelisting you potentially 
miss new actions kate adds in a new release. You sure could have both. For 
'approved' editors in the right version kdevelop could just use their GUI and 
otherwise (unknown editor) it could pick the most common actions itself and 
add them to the menus where you want them.

With an event filter I think you're likely to end up with a gigantic ugly 
function after a few releases that tries to look for actions with all sorts 
of different names. Do you really want that? :)


Simon
[prev in list] [next in list] [prev in thread] [next in thread]