Search Indicators in Dolphin

Vishesh Handa me at vhanda.in
Mon Jun 3 11:25:13 BST 2013


Hey Frank


On Mon, Jun 3, 2013 at 1:57 AM, Frank Reininghaus
<frank78ac at googlemail.com>wrote:

> Hi Vishesh,
>
> sorry for the late reply. I was at a friend's wedding, which involved
> quite a bit of travelling.
>
> 2013/5/29 Vishesh Handa <me at vhanda.in>:
> > 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.
>
> Well, we do have signals "directoryLoadingProgress(int)" and
> "directorySortingProgress(int)" in KFileItemModel, which result in a
> notification in the status bar, but I guess that these are not really
> suitable for the case that indexing the home folder will take a few
> hours ;-)
>

Depends on the number of files, but I do not feel that using the status bar
would be enough. We need something that would be a lot more intrusive and
visible to the user.


>
> > 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]
>
> I'm not sure how useful such a progress bar would be. If indexing the
> home folder takes a few hours, it's not very likely that the user will
> watch the progress bar proceed to its end and leave the search
> untouched in the mean time, I think.
>

Yes, they might still search, but they will get incorrect results, and then
they will not blame Nepomuk or Dolphin.


> An alternative might be to just use the "filenamesearch" kioslave if
> the indexing is not finished yet and possibly show a message informing
> the user about that and providing an estimate of the remaining time
> until the indexing is finished.
>

We already have basic indexing in Nepomuk which indexes the file names and
file types. We can still use Nepomuk.

Btw, on a slightly unrelated note, we need to give the user some kind of
feedback when they are using the filenamesearch kioslave or the Nepomuk
kioslave.

>
> > 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.
>
> Well, searching something in ~ and its subfolders is probably quite a
> common case, but OTOH, indexing ~ might take quite a bit of time, so I
> wonder how useful such an option would be?
>

The default option is to have your entire home directory indexed. That is
the most common case.

In fact, normal users do not care about indexing, so we should be indexing
everything. I think Nepomuk has reached the point where we can index
everything quite fast.

This option will mostly be used in the case of extra devices which are
generally mounted in /media.

Also, even if it takes a lot of time, then that will be done in the
background and will be scheduled so that it is not intrusive to the user.


> Best regards,
> Frank
>



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


More information about the kfm-devel mailing list