Move eventFilter from contextbrowser into kate

[Andreas Pakulat]

On 10.11.08 11:49:05, David Nolden wrote:
> Am Montag, 10. November 2008 11:27:51 schrieb Andreas Pakulat:
> > Hi,
> >
> > I was just pointed to some code in the contextbrowser which seems to cry
> > for moving it into kate. Its an eventFilter for the "html-like"
> > code-browsing in a kte-view. Looking at the code we need relatively little
> > from a new KTE interface to support this without the hackery I see here.
> > Basically something like this:
> >
> > class BrowseInterface
> > {
> >         void setBrowseModeTrigger( Qt::Key )
> >
> > signals:
> >         void browseModeStarted();
> >         void browseModeStopped();
> >         void clicked( KTextEditor::Cursor );
> >         void moved( KTextEditor::Cursor );
> > };
> >
> > What doe the maintainers of the contextbrowser think?
> >
> > Andreas
> 
> In general I agree, but it's not as simple as the interface you've written. 
> There is no smart-ranges for all browseable stuff, for example not for 
> include-directives, not for macros, and in future I'd also like doxygen links 
> to be browseable, also without attached smart-ranges.

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)

> Also at some point the 
> range under the cursor should be underlined when browseable. So a pure 
> kate-side implementation won't work, it will at least need to ask the 
> application whether there is something browseable under the cursor, and for 
> its range.

So actually instead of the moved() signal, a callback like this:

class BrowserInformationInterface
{
public:
        KTextEditor::SmartRange browseableRangeForCursor(
KTextEditor::Cursor );
};

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.

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

Andreas

-- 
You are so boring that when I see you my feet go to sleep.