Move eventFilter from contextbrowser into kate

[David Nolden]

Am Montag, 10. November 2008 16:29:49 schrieb Andreas Pakulat:
> I don't see any smartranges in my interfaces. Or does KTE::Cursor imply a
> smartrange? (didn't check on the interfaces at all, it was just a
> braindump)
Nope but smart-ranges are the only way how kate could know whether 
something "navigatable" is under the cursor, without that callback.
> So actually instead of the moved() signal, a callback like this:
>
> class BrowserInformationInterface
> {
> public:
>         KTextEditor::SmartRange browseableRangeForCursor(
> KTextEditor::Cursor );
> };
Yes, except that a KTextEditor::Range would be enough.

> Which would be implemented by kdevelop and a registering/deregistering
> function on the actual BrowserInterface. That would also mean that
> clicked() could provide a smartrange or a simple range, depending on which
> one is more apropriate.
>
> > Also, the browse-mode should work across all kate views open in the same
> > main window, which is ugliest part of the hackery, and would still need
> > to be done.
>
> This is for splitview, right? Well, you could add a startBrowseMode and
> endBrowseMode to the interface and then <something> could call that on all
> views, when one of them emits the browseModeStarted().
>
> > 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. I want it all to work using 
the keyboard exactly as well as it works with the mouse. 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.

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

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

Also it would make sense to wait a bit until the code browsing has matured a 
bit, and the navigation is really "ready", to see what we really need.

Greetings, David