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

List:       kde-usability
Subject:    Re: Easier Searching in KDE
From:       Gustavo Sverzut Barbieri <gustavo () gsbarbieri ! sytes ! net>
Date:       2004-05-24 14:47:32
Message-ID: 200405241147.33053.gustavo () gsbarbieri ! sytes ! net
[Download RAW message or body]

Em Segunda 24 Maio 2004 08:56, Dik Takken escreveu:
> On Sun, 23 May 2004, Jamethiel Knorth wrote:
> > So, every plugin MUST be able to function fully with one line of input,
> > thus allowing them to be used from anywhere. The added options have to
> > all have presets. That makes the search applet work, and it means a user
> > doesn't need to give much input if they don't want to.
> >
> > We need to have many more options available, or you cannot find something
> > very specific out of a huge mass of information, which is one of the
> > greatest values of searching.
>
> You can use different search plugins for that. Different plugins can be
> specialized in searching specific things, like music (look at the tag
> info in MP3's) and they should have default settings that are optimised
> for their own purpose.
>
> IDEA:
> -----------
>
> If we choose to go the google way (which is a wise thing to do IMHO),
> all search options should be available from the query line. For example,
> adding "size:200kb" to the query returns only files of that size. Some
> query options can be very specific to one search plugin. For example, only
> the Music plugin understands the "artist:Pink Floyd" search option.
>
> Here comes the trick:
>
> We could write one search plugin called 'General Search' that accepts all
> search options supported by all availabe search plugins. If the user only
> queries for a name, this general plugin will call all other plugins and
> display the results of each plugin. If the user uses search options that
> are specific to one or more plugins, the general search plugin only calls
> those plugins that understand that option. For example, when the user
> provides the  "artist:Pink Floyd" option, the general search plugin
> calls these specific plugins:
>
> * Local MP3/OGG/etc search
> * CD/DVD database on the internet (Amazon.com)
> * P2P network search
>
> For this to work right, all search plugins that have artist option should
> use the exact same name for that option. If one plugin calls the option
> 'Artist:' and another plugin uses the word 'Performer:', it won't work.
>
> If this can be implemented, it might be a good candidate for the default
> search plugin.

Indeed!
The only point I see against this is the slowness... google is fully indexed 
and does this all within mseconds. Searching the web or even search for files 
takes a lot of time in computer these days... slocate is good, but it 
generally is desync. Searching for contents is even more slow.
	Maybe we could come with a way to solve this:
		- the match list should first search local files in indexed mode, then check 
if they exists (avoid show non-existent), then proceed with something like 
"find", then with web, ... This may present first results really quick, but 
the other will still be delayed
		- cache previous results, maybe they're used again soon since users often 
refine their search
		- change kio_slaves to update a db everytime a file is modified...  with 
that we can have something fast for user and better sync'ed than slocate. The 
problem is other apps, like gnome or openoffice.

	All of them have problems. The real problem I see is with home dir... it's 
the part of the system that changes most and in short periods of time, 
probably the user changes and then search... that common case makes life 
difficult and should be optimized.



> > I'd say try to stick to the one-line search interface. The search system
> > people are most adjusted to is Google. Let them stay adjusted to it.
>
> Indeed. people who want to use the search options should take a look at
> the manual of the search application. If we provide a few good examples of
> search queries, this should be no problem. We could even add a quick help
> button next to the query input line that shows the 'examples' section of
> the manual in just one click.

Sure.
See my reply to Jamethiel about the real-time build thing. Maybe the options 
can be there to help people understand how to create they own one-line 
queries.

-- 
Gustavo Sverzut Barbieri
---------------------------------------
Engenharia de Computacao 2001 - UNICAMP
GPSL - Grupo Pro Software Livre
Cell..: +55 (19) 9165 8010
Jabber: gsbarbieri@jabber.org
  ICQ#: 17249123
   GPG: 0xB640E1A2 @ wwwkeys.pgp.net
_______________________________________________
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]