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

List:       kde-usability
Subject:    Re: Kicker find as you type
From:       Gábor_Lehel <illissius () gmail ! com>
Date:       2005-05-09 22:36:13
Message-ID: 9cfeadb805050915363fc9aafd () mail ! gmail ! com
[Download RAW message or body]

On 5/9/05, Dominik Seichter <domseichter@web.de> wrote:
> 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.
basically agree with this

> > > > - 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.
You mean SVN =)
Anyways, I just tried it out myself and can already report a bug: if
the number of recent apps to show is 0, it fills the top of the menu
with 'quick search results' labels when you search. Also, the menu
resizing can be a bit disconcerting, at least when you have it on top
like I do... (happens when the number of recent apps in the menu is
less than the max).
(I'll be switching back now, though, as the version you branched from
apparently didn't yet support treating max taskbar button width = 0 as
unlimited, and hence I seem to be without a taskbar...)

> 
> 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
> **********************************************************************
> 
> 
> 


-- 
Work is punishment for failing to procrastinate effectively.
_______________________________________________
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]