Kickoff / ALI extensibility

[Aaron J. Seigo]

On Monday 03 March 2008, Eike Hein wrote:
> Aaron J. Seigo wrote:
> > s,some,all,
>
> Automatically? I thought they were separate APIs ... was
> Kicker less of a mess than I remember ? ;-)

not really. see,  it was the same API for the menu and the buttons ... but the 
buttons were handled completely different from all other types of buttons 
(let alone applets). instead of a generic "button, with a possible menu" 
implementation, we had two very distinct button super classes (one of which 
lived in libkdeui!) and somewhere around a dozen built-in subclasses of them. 
it was a mess. the intentions were good, e.g. combining menu plugins with 
buttons, but there was a real lack of big picture oversight leading to these 
multiple code paths depending on whether it was a built in button (one of a 
few types), a menuext button, an applet or a panelextension.

>  > i think this is a natural direction ... it does mean briding between a
>  > QAbstractItemModel and a DataEngine for kickoff's purposes though.
>
> Which sounds like a pretty interesting thing to tackle :-).

indeed. should be pretty straightforward, too, i'd think.

> > the demarcation is pretty clear imho: one provides lists of possible
> > matches based on a query (up to the interpretation of the runner), the
> > other provides access to sets of information associated with well known
> > keys. you could certainly approximate (though not easily duplicate) a
> > dataengine with a runner and vice versa, but they are much more optimized
> > for their specific tasks.
>
> Yeah, the split as it is now certainly makes sense from the
> POV of optimizing for the different performance requirements.
>
> The reason I started pondering, though, is that if you want
> to make Kate sessions (as an example) appear in KRunner, a
> menu extension and a Plasmoid - all three -, part of the
> task is the same: discovery of the sessions. Ok, the Runner
> implementation might still want some extra tricks suited
> especially to incremental searching, but it got me thinking
> if there might be some clean way to combine the two at some
> point, to enable straight-forward sharing of codified know-
> how like that. It's a bit of an overall design thrust of
> Plasma to avoid duplicate data providers, after all.

perhaps putting the two plugins in the same library? or having the runner use 
the dataengine in the back ground, so that the runner essentially becomes a 
filter for the engine?

-- 
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: 194 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20080303/2385a1ba/attachment.pgp