[PATCH]: Kicker find as you type

Aaron J. Seigo aseigo at kde.org
Mon May 2 17:11:51 BST 2005

On Monday 02 May 2005 06:42, Dominik Seichter wrote:
> > or perhaps in the Applications section, and have it whittle down the
> > options so the user can learn where things are as well? (not sure how i
> > feel about that, actually)
> Maybe this is the best choice to go. Add a find widget to the main menu and
> show only the items matching the users request.  Some work would have to be
> done to prevent menu resizing in this case.
> One could even implement it directly in PanelServiceMenu (of course with a
> flag to offer the search functionallity only if wanted).

this sounds like an interesting avenue for exploration =)

> > and it seems to have some overlap with the exec applet as well. as in:
> > this functionality would be nice for the exec applet =)
> Yes, this would of course be nice for the exec applet, too. I do not have
> any idea right now, how the exec applet would look like with this feature.

populate the auto-completion menu with matches =)

> > > Now I would like to know, how this feature can be further improved and
> > > wether I should commit it to CVS or not.
> >
> > to be included in CVS it must follow the coding guidelines found in the
> > HACKING file.
> Of course.... cleaned up the code. Should be ok now.


> Maybe I could a method (or class - don't know):
> KService::List findMatchingServices( const QString & pattern );
> Is this sensible? Where should it go?

no, what i mean is that these two calls:

new PopupMenuTitle(i18n("Find an Application"), font())

require that this menuext be linked against internal kicker code (in ui/ and 
core/). while this was standard operating procedure before (and there is 
still one applet that does this =/ ) it causes lots of problems and is not 
something we do anymore in kicker =)

so ... PopupMenuTitle seems to do little more than set the font to bold. it 
should move to libkickermain for now, and then we should make KPopupMenuTitle 
be able to bold the font and be done with this kicker-specific class. but at 
least moving it into kicker/share/ for now alleviates the "internal linkage" 
issue and lets it be used where appropriate.

the updateRecentMenuItems() call is a bit trickier, but not by much. it just 
needs to be ripped out of PanelServiceMenu ande made into a singleton class 
which gets put into share/ ... this way it can also be accessed by other 
applets/buttons as appropriate.

> > and this way, we can put this item in a playground to start with until we
> > figure out exactly what to do with it ... the menuext's we have there
> > right now really need some sorting out in general.
> I think I'll try out some stuff this week and hope to figure out how this
> can be improved.


> Up till then, the menuextenstion is already a nice addition IMHO.

it's just not ready for HEAD yet. you can put it in a playground, but until we 
get the issues of where it should appear and work and the usage of internal 
code i'm not comfortable with adding it to kicker just yet. 

Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
-------------- 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/kde-core-devel/attachments/20050502/a785e510/attachment.sig>

More information about the kde-core-devel mailing list