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

List:       kde-devel
Subject:    Re: kio-locate
From:       Fred Schaettgen <kde.sch () ttgen ! net>
Date:       2005-04-13 11:40:32
Message-ID: 200504131340.33046.kde.sch () ttgen ! net
[Download RAW message or body]

On Tuesday, 12. April 2005 08:50, Armin Straub wrote:
...
> As I am continuously asked to ask for inclusion to KDE, I hereby do exactly
> this :-) Do you want kio-locate to be included to KDE? (something like
> kde-extragear, as locate is not configured properly on a standard system)

That reason that people keep asking you to include it into KDE only means that 
they are missing something in KDE, but not that kio-locate is necessarily the 
best solution of their problem ;)
As the author of a third party application, a kioslave was the only viable 
option for you to deeply integrate a search function in KDE. But if the code 
enters KDE, then why not integrate the same functionality in a more sane way? 
I'm not sure if I know all possible uses of kio-locate, but wasn't the main 
idea just have a search function, which can also be used from inside file 
dialogs? If this is the case, then the kioslave interface for locate is just 
a very crippled _user interface_.
Wouldn't it be better to work on some hooks for the file dialog, so that 
search tools can be plugged in, which bring their own interface? You would 
gain a lot of flexibility, just think about the file counts, which are shown 
as part of the file name currently, or the name coloring which was requested 
on kde-apps.org. With a kioslave this will always remain somewhat ugly. 
I really don't want to take down kio-locate - you know I'm using it myself :) 
What I wanted to say is that in KDE you have the chance to remove limitations 
instead of working around them.

Fred

-- 
Fred Schaettgen
kde.sch@ttgen.net
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]