Move eventFilter from contextbrowser into kate

[Andreas Pakulat]

On 10.11.08 18:03:51, David Nolden wrote:
> Am Montag, 10. November 2008 16:29:49 schrieb Andreas Pakulat:
> > > The event-filter is btw. also used to allow passing the focus from the
> > > editor view to the code-browser, so we wouldn't get rid of that.
> >
> > Ok, so indeed I correctly understood your commit messages that I can go
> > to the context browser from the editor. This makes navigating the docks
> > inconsistent, because there's one which you can directly switch to, even
> > with a very very strange "shortcut". And there's another way for all other
> > docks, by simply calling the show <xxx> dock action, which simply focuses
> > the dock when its already shown. So I'd like to know the reasoning for
> > having a single-press+release on shift move the focus.
> Very simple: It makes keyboard-navigation consistent. Wherever you are, be it 
> quickopen, completion-list, or editor, you can always navigate the related 
> declaration/item using a very simple shortcut.

Hmm, I particularly dislike the shift-shortcut. I tend to hit shift a lot,
especially on smaller keyboards (laptop for example) that is without
actually hitting another key. We definetly need something more complex when
we want to make it switch the focus - IMHO.

> Whether this shortcut actually is the answer, I don't know. It needs some
> more serious testing, and maybe another idea for easy and consistent
> keyboard navigation.

Definetly, see above. But I agree its _extremely_ convenient to have the
same shortcut work all over kdevelop. Its still making things a bit
inconsistent, but at least the other option also works for switching the
focus, so nothing is taken away from the user. Thats good :)
 
> Most consistent would be if the code-browser could always be navigated using 
> shift+arrows and shift+enter, but that is needed by the editor. I think about 
> switching it to ALT+Arrows and ALT+Enter if that isn't used, then an explicit 
> focus-switch would not be needed any more.

Then we'd need to have Ctrl+Tab/Ctrl+Shift+Tab available for switching
between files. That would be my personal preference anyway as its used in a
lot of other GUI editors to switch between files.

> The code browser would probably 
> still need an event filter on the view though, a shortcut won't do, since 
> those events should only be taken when the code-browser is visible, a 
> text-editor has focus, and when there is no active completion widget.

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.

> > > So in general I would appreciate someone extracting such a nice
> > > browse-interface. Personally I'm happy that it works, and I'll
> > > concentrate on making more stuff work better, instead of refactoring, at
> > > least until we have a release. :)
> >
> > The problem with that approach is, that by the time we do have a release,
> > kdelibs is closed for new features for 4.3. So we actually do need to think
> > about the interface "soon" and get the code into kate, so we can have it
> > reviewed right after 4.2.0 hits the streets - kate devs are sometimes a bit
> > slow on that. Even if its in kate, that doesn't mean we have to refactor
> > the plugin instantly. I mean we still don't use the annotation interface
> > which was added for KDE 4.1 in any of our plugins...
> Ok. We have some other more important stuff about code-completion concerning 
> delimiter characters and change-notifications that I've talked with Niko Sams 
> about, that that will have higher priority for me.

Sure, I also didn't imply that you have to do this yourself :) I actually
think the part that needs implementing in kate could be done by almost
anybody, if you're up for a bit of input... But at least we have a starting
point now, so I'm sure we can tackle this after the 4.2.0 KDE release.

Andreas

-- 
You have taken yourself too seriously.