[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: Kicker find as you type
From:       Dominik Seichter <domseichter () web ! de>
Date:       2005-05-09 15:09:23
Message-ID: 200505091709.27688.domseichter () web ! de
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Hi

Am Monday, 9. May 2005 16:15 schrieb Gábor Lehel:
> On 5/9/05, Dominik Seichter <domseichter@web.de> wrote:
> > > > For all keyboard freaks, we may have a prefix in the search field,
> > > > like run [application] or r [application]
> >
> > I think it would be enough, if the search field would just work like
> > minicli. Typing xcalc and pressing enter will start xcalc. Isn't that
> > easier than a prefix? Also one could use webshortcuts like "gg:Kicker
> > find as you type" to google in the search field if it worked like kicker.
>
> Personally, I'd like it to work like amaroK's search field -- pressing
> enter while the focus is still in the search field opens the first
> matching entry, and closes the menu.
If we agree that the search line should not behave like minicli, enter should 
execute the first found entry. I like the idea first to give the search 
widget the same features as minicli, but honestly, if you want minicli you 
can launch it faster than opening the kde menu and typing your command there. 
So maybe it is pointless that the search widget should have minicli's 
features.

> > > - Do users make use of the Quick Search?
> > > - Do they have problems handling it (input field in a menu)?
> > > - What do they enter (app name vs keywords vs both?)
> > > - Do they have problems initiating the search by clicking . or /? Is it
> > > necessary to have those search initiators at all?
> >
> > Currently we decided to give the search line the initial focus, after it
> > is lost once (for example because of using the up/down arrows) one can
> > access it fast using SHIFT+/ or using SPACE. This is still up for
> > discussion, though.
>
> Is there any reason against having / and . as well (or instead, though
> I don't see the harm in having more)? Also, SPACE would conflict with
> the existing find-as-you-type in the menu, for entries with a space in
> them (eg, 'Control Center', or when only the descriptions are shown --
> 'Text Editor' for instance).
Agreed. / and dot should be fine. Patched in CVS.

CU Dom
-- 
**********************************************************************
Dominik Seichter - domseichter@web.de
KRename  - http://www.krename.net  - Powerful batch renamer for KDE
KBarcode - http://www.kbarcode.net - Barcode and label printing
KDE Mass Mailer - http://www.kmassmailer.net - Mass mailing for KDE
SchafKopf - http://schafkopf.berlios.de - Schafkopf, a card game,  for KDE
**********************************************************************

[Attachment #5 (application/pgp-signature)]

_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability


[prev in list] [next in list] [prev in thread] [next in thread]