[Panel-devel] Proposal for changes to KRunner

[Aaron J. Seigo]

On Tuesday 20 November 2007, Ryan Bitanga wrote:
> On Nov 19, 2007 12:14 AM, Aaron J. Seigo <aseigo at kde.org> wrote:

> multiple actions with a SearchMatch class than with a SearchAction
> class. So I suppose it's only a matter of difference in taste.

ah, i see. you're talking about the semantic meaning of the class (it 
represent a match), whereas the class is currently named after what it does 
programmatically (it acts as an action in the application code).

hm. ok, let's table this one for a bit ...

> > have you done any benchmarking on how fast/slow QAction creation is? of
> > course, fetchActions would have to create the actions so we're left with
> > creating two objects (including the QAction) instead of just one. so this
> > would, if fetchActions is used, actually be slower and more memory
> > intensive than simply creating QActions in the first place.
>
> Which was why I later pointed out that we didn't really need
> SearchAction to inherit from QAction and be a QObject. If all we're
> looking for is something to contain, text, icon and data fields, we
> don't need a full blown QAction subclass. Meta-objects carry extra
> baggage with them.

not so much that it should matter given the # of matches we're showing; that's 
why i asked if you'd actually profiled this =)

the nice thing about QAction is, as i've noted, that we already have all those 
widgets that are set up to use them and they have a well known pattern of 
use. unless there is compelling reason to break with this set of design 
patterns (e.g. notable performance issues), we should stay with it.

> > i'm not sure i understand exactly what you're trying to achieve here, but
> > if i'm getting it right: you're looking for a second-pass run, where
> > runners can process the matches of other runners? filter runners or
> > action-augmenting runners?
>
> The intention was for a given match with multiple actions that can be
> performed on it, the runner should be able to distinguish which
> actions to perform. So yes, filtering will occur, but runners will
> only be concerned with matches they provided. So no external filtering
> runners would be necessary because the runner would select between
> possible actions for a given match itself.

ok, so this is much easier than what i was thinking you were suggesting. not a 
problem then, with the current design or not =)

> > > This would also allow us to permit user-created actions
> > > and have KRunner scan a directory and then add user-created actions to
> > > the pool of possible actions for that runner via an addAction(const
> > > QString& icon, const QString& name, const QString& exec, const
> > > QString& mimetype = QString::null) method. This would mimic behavior
> > > for creating konqueror service menus. We could write a dialog box for
> > > the creation of user-created actions to make it easier for users.
> >
> > so making SearchAction more expressive would probably be a good first
> > step.
>
> any ideas how to go about this?

well, they need to expose enough information to be used as matches. in 
konq/kfiledialog/dolphin we have the mimetype of the file. not every 
SearchAction will result in a mimetype, though that's one possible match 
item. so perhaps the SearchAction should publish an optional mimetype; what 
other things would be useful? i really haven't had a chance to brainstorm on 
this ... 

perhaps you have some ideas/thoughts on what would sort of information, if 
known about a match, would make it easy to identify it as relevant to a user 
supplied action?

essentially we'll need to let the user say "when an action is like X, do this" 
or "when an action has X, do this" or "when an action relates to X, do this". 
the question is what X is

> > the benefit of subclassing qaction is being able to use it in a number
> > flexible ways, including direct invocation via triggered() and by putting
> > it into widgets that accept QActions (which is all of them).
> >
> > it also gives us an API that any Qt developer would be familiar with.
>
> so why not provide a similar API by reimplementing the functions that
> are useful to runner authors?

because reinventing the wheel for no good reason (e.g. without profiling data 
to show that it is a performance bottlneck) is not a good use of time. that's 
why we have and use libraries in the first place.

> > what exactly is the benefit of not using QAction?
>
> This comes at the expense of thread-safety. Using ThreadWeaver,

ah, ok, so now we come to the issue: we need a pure-data class that can be 
made perfectly thread safe and keep the user interaction bits that need a 
long-lived event loop in the main loop. yeah, that's obvious now that i stop 
and think about it.

*thinks*

here's a slightly different approach: SearchContext (running in the GUI 
thread) publishes a QAbstractItemModel. the model is populated by the runners 
using (short lived) SearchMatch objects. the UI would then reflect the model. 
fewer individual objects sitting around, a way to identify matches by index 
as well as by runner .... thoughts?

in the meantime ... making SearchContext thread safe is probably fine; with 
the threading issue there, i'm ok with making SearchAction not a QAction, and 
once it's not a QAction then we can indeed change the name (RunnerMatch?)

> If you're still not sold on multithreading, the advantage is higher

it's not that i have any issue whatsoever with multithreading krunner, i'd 
*like* to see it. this was all about redesigning how the search action works.

> > exact and possible have almost nothing to do with the default match. if a
> > runner determines that "konsole" is an "exact match" for "kon" then it
> > can say so.
>
> Yes i am aware of that. But the selection of the default match is
> based on the first exact match retrieved, or if there are no exact
> matches, the first possible match, am I not right?

when one considers that this is also meant as a "run command" dialog, the 
reason for this choice becomes obvious. it must be able to, first and 
foremost, alway pick the command line command version that is being entered. 
everything else is icing.

> So flexibility is
> lost there, because exact matches are set as default before any
> possible matches. But this isn't difficult to fix.

why would you want non-exact matches picked before exact matches? by 
definition that doesn't make sense. if you mean "the user should be able to 
supply preferenes" well .. then that just becomes another runner, doesn't it?

> > i have been considering moving the default action selection out of
> > krunner itself and into SearchContext
>
> I guess this would be an acceptable move. At the very least it would
> simplify krunner.

yep.

> > runners already have no clue what the default match is =)
>
> Agreed but users can't set the default match as of the moment. krunner
> picks one for them.

well, yes. that needs to be added, but doesn't require much if any change in 
design; the "set this as the default match" could easily become another 
runner which either creates the search action on its own and uses other 
runners to actually act on it (so a sort of proxy runner) or which serves as 
a match filterer.. i prefer the former.

> No comment on the "direct object" idea? I'll see if I can put

i figured there were more concrete things to go through first.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20071120/d20a962d/attachment.pgp