Move eventFilter from contextbrowser into kate

[Andreas Pakulat]

On 10.11.08 22:05:54, David Nolden wrote:
> Am Montag, 10. November 2008 20:35:12 schrieb Andreas Pakulat:
> > You don't need a filter for that, as you can simply choose to "do nothing"
> > when the action is executed. So you could check wether the view is a KTE
> > and wether there's a code-browser toolview visible. Another issue with an
> > eventfilter implementing shortcut logic is that the user doesn't get warned
> > about conflicts. Especially when Alt+Arrows/Enter is implemented this is
> > something that might happen easily. There's been a lot of effort done in
> > kdelibs to make sure that users don't end up with conflicting shortcuts and
> > even if they do so, that they at least get a warning.
> But don't ambiguous shortcuts block each other? I've noticed when hacking on 
> the shortcut in kate, that keys that are bound through KAction neither ever 
> reach the QObject::event() function, nor any event-filter.
> 
> This would work if kate would be the only entity using these shortcuts, which 
> would need one more interface to notify kdevelop of the shortcuts.

Maybe its the fact that I just got up, but I don't get you :(

If you have a KAction for that shortcut, available to XMLGUI (i.e. inside
an actionCollection thats associated with a xmlguiclient/plugin) then the
user can't create an ambiguous shortcut for that action inside the shortcut
editor. The editor will prevent that. OTOH if two plugins each manage to
provide an action with a default shortcut set that happens to be the same,
you'll get a nice message-box when you trigger that shortcut. It'll tell
you which actions have the clash, which makes it easy to go the the
shortcuts dialog and change either of the two and IIRC even tells you which
xmlgui client/plugin this comes from so you can notify the author.

Both of those are not going to work with a "shortcut" implemented via an
eventFilter.

Andreas

-- 
You have a deep interest in all that is artistic.