Search Indicators in Dolphin

[Vishesh Handa]

On Thu, May 30, 2013 at 12:05 AM, Mark <markg85 at gmail.com> wrote:

> Ohh, it is.. forget my suggestion then :p
>
> Guess i should enable it a bit more often, hehehe
> Though the reason for disabling was benchmarking listdir performance
> with half a million 0 byte files. The nepomuk indexer took ages in
> that folder. Note: 0 bytes!
>

Well, I haven't ever tried half a million files, but on average we take
about 50-80 msecs per file. This number should be a lot lower with 4.11
because of the massive improvements I've been doing, but even then it would
still be at least 20-30 msecs.

so half a million = 500,000 * .025 = 12500 seconds = 208 minutes = 3.47
hours.

I'll try creating such a test case and optimizing for it when I get the
time.

>
> On Wed, May 29, 2013 at 8:28 PM, Vishesh Handa <me at vhanda.in> wrote:
> > Hey Mark
> >
> >
> > On Wed, May 29, 2013 at 11:52 PM, Mark <markg85 at gmail.com> wrote:
> >>
> >> Hi Vishesh,
> >>
> >> I'm just going to throw in a small idea that might help the user
> >> experience.
> >>
> >> Why don't you just do a very quick simple index first? As in the same
> >> as you would get when you do: "find . -iname 'something'"? Or even
> >> better, just quickly build up a list of files and use that as base
> >> index. When users search they are very likely searching for files thus
> >> they will get results based on the filename. It might not be as
> >> accurate as it could be when all files are indexed, but it is likely
> >> to show the user something rather then nothing.
> >
> >
> > That's exactly what we do.
> >
> > We first index the filename, mimetype and modification time. This way
> simple
> > searching and the "Videos", "Audio" and other options work, and so does
> the
> > "timeline". In fact currently this basic indexing always runs even when
> > you're on battery.
> >
> > You can manually pause/resume it though.
> >
> >>
> >> Just my 5 cents :)
> >>
> >> Regards,
> >> Mark
> >>
> >> On Wed, May 29, 2013 at 8:12 PM, Vishesh Handa <me at vhanda.in> wrote:
> >> > Hey Frank
> >> >
> >> > I've been trying to figure out how to schedule the indexing of the
> >> > files.
> >> > Currently, it only indexes the contents of the file when idle. This
> >> > obviously doesn't work in all cases as many users will not be leaving
> >> > their
> >> > system idle.
> >> >
> >> > So, when users try to search, it does not give them the correct
> results
> >> > and
> >> > that leads them to believe that nepomuk is not working.
> >> >
> >> > One way of fixing this is by always indexing the files and adding
> >> > appropriate delays so that the user is not bothered, and that is what
> I
> >> > am
> >> > going to do for 4.11. However, until the indexing has been completed
> we
> >> > still have the same problem.
> >> >
> >> > The proper way to fix this would be to have some kind of "indexing
> >> > progress"
> >> > bar which is shown to the user when they try to search.
> >> >
> >> > So, if the user tries to search through a folder which is marked for
> >> > indexing and still not indexed, it will say "These files are currently
> >> > being
> >> > indexed. The search results may not be complete" and it will show a
> >> > progress
> >> > bar, and maybe even try to approximate the amount of time the indexing
> >> > will
> >> > take.
> >> >
> >> > Would you be okay with something like this in Dolphin? I'm imagining
> >> > something like the KMessageWidget, but with a progress bar. [1]
> >> >
> >> > Also, maybe it would be nice that if the user tries to search through
> a
> >> > folder which is not indexed, a message widgets appears which says that
> >> > this
> >> > folder is not indexed, and therefore searching will be slow, and then
> >> > gives
> >> > the user the option to index the folder.
> >> >
> >> > What do you think?
> >> >
> >> > [1] http://osxdaily.com/wp-content/uploads/2010/08/mds-updating.jpg
> >> >
> >> > --
> >> > Vishesh Handa
> >
> >
> >
> >
> > --
> > Vishesh Handa
>



-- 
Vishesh Handa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20130530/40e6b374/attachment.htm>