Advanced Search

[João Netto]

Well, I can give one reason for it, a personal and very particular one, so
maybe it's not worth it.

I have a huge PDF that contains ID's for programming exercises, I would
like to see every occurrence of it when I search it, since every one of
them is preceded by UVa.

I don't really like the sidebar either, but I brought it here because maybe
some people like it.

And I mean that Okular stops, does the search, then it clears for the user
to use. At least it was my experience in the label search.



Em seg, 4 de mar de 2019 20:45, Albert Astals Cid <aacid at kde.org> escreveu:

> El divendres, 1 de març de 2019, a les 3:23:30 CET, João Netto va escriure:
> > Hi,
>
> Hey
>
> > Lately, I've been messing around with Okular search feature and I've been
> > trying to improve it according to user request, namely 399446
> > <https://bugs.kde.org/show_bug.cgi?id=399446> and 377487
> > <https://bugs.kde.org/show_bug.cgi?id=377487>.
> > One of the features that stood out and has some duplicates was the "Find
> > and highlight all", now, there are lots of ways that readers do that.
> > Evince has a side panel that is updated every time a match is found and
> > Adobe Reader has an advanced search that shows every match after the
> search
> > is done. I did not test other readers, but I'll include images of the
> > panels on both tested.
> >
> > The point that I want to bring in this discussion is, should Okular
> > implement this feature? I'm up to the job if it's the general consensus.
> > And, if yes, how should we proceed about that?
> > Should we add the sidebar right below Bookmarks, or we should do an
> > Advanced search and open in a new window?
>
> To me it being in the sidebar doesn't really make much sense, but it seems
> to be what evince and Adobe do so what do i know :D
>
> > As of now, there are four types of search ALLDOC, NEXTRESULT, PREVRESULT,
> > GOOGLESEARCH, alldoc finds and highlights all, next and prev is the most
> > used and googlesearch is for the thumbnail.
> >
> > If we do the evince way, we would have to redesign the next and prev
> > result, we would just use alldoc search, grab the metadata and implement
> on
> > the sidebar. The problem right now is that this consumes lots of time
> > because it stops the program to search. If we do this in a separate
> thread,
> > maybe worth the effort, but lots of change would be required to the
> > textpage.cpp. (Or we could add a find all button?)
> >
> > If we do the Adobe Reader way, the users who really want it still would
> > have it, they can endure the waiting, some small changes would be
> required
> > to textpage.cpp depending on how we choose to implement the advanced
> search
> > widget.
> >
> > I'm open to discussion to any point, and if we go through with this, I'll
> > make sure to take my time and do it, but I guess it will take a while.
>
> Honestly i don't see the need of doing an all document search every single
> time people do search one word (i.e what evince does), but well i guess
> that's obvious since otherwise I would have implemented it.
>
> For the people out there that for some reason need to find all the
> occurrences at the same time (noone seems to have explained why they need
> this with other reason than "evince and adobe do this", but whatever) i
> think a separate option makes more sense.
>
> What do you mean with "it stops the program to search" though?
>
> Cheers,
>   Albert
>
> >
> > Thanks for your attention.
> >
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/okular-devel/attachments/20190304/609f8345/attachment.html>