Review Request: Libkonq support for the nepomuk search runner

[David Faure]

On Monday 19 January 2009, you wrote:
> On Monday 19 January 2009, you wrote:
> > On Monday 19 January 2009, Aaron J. Seigo wrote:
> > > On Monday 19 January 2009, Ryan P. Bitanga wrote:
> > > > I could write another patch for the locations runner. I think moving
> > > > libkonq out of apps would be a good idea but we'd have to review the
> > > > API somewhat more extensively. Since it abstracts file management it
> > > > has it's use outside of dolphin and konqueror. Could we move it to
> > > > kdelibs for 4.3?
> > >
> > > possibly, or perhaps some other shared location that doesn't have quite
> > > the same API requirements as kdelibs.
> > >
> > > David: what do you think?
> > >
> > > > Anyway, is the patch good to go if I move it apps?
> > >
> > > yes, except that i'd like to figure out what we want to do with libkonq
> > > first. no point in moving things back and forth, and for the Locations
> > > runner it's too critical to the usage of krunner to be able to rely on
> > > kdebase-apps being installed. it must stay in workspace.
> >
> > I'm out of context --
> 
> sorry, should've provided more information =)
> 
> > which part of libkonq is the Locations runner interested in?
> 
> the ability to offer the same actions that are seen in the context menus of 
> konq/dolphin/folderview. so if you enter a file name, you can get at things 
> like "open with..." 

So, KonqPopupMenu? But not really since you say there are runner-specific actions.
So, some code extracted from KonqPopupMenu? But then this isn't about moving
libkonq as it is now, but about refactoring some code first, right?

> since 4.2, krunner has supported actions-on-matches. the actions are supplied 
> by the runner (since the actions are very specific to whatever the runner is 
> doing) and in this case using libkonq avoid code duplication and ensures 
> consistency.

Yes but my question is _which_ libkonq exactly.

> we also have uses for servicemenus, but that's a different topic. =)

_That_ code is already factored out, please check if KonqMenuActions would do
the job as it is, and then we can move it to, well, maybe libkfile? or libkio.

What I'm pointing at here is that we don't need to move all of libkonq, we can
move the classes that do make sense for other users than dolphin+konqueror,
just like FileUndoManager has moved to kio already.

-- 
David Faure, faure at kde.org, sponsored by Qt Software @ Nokia to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).