Sorry, being busy with college and stuff.

Nope, this revision can be abandoned as it no longer works.

This was merged on invent.kde.org.

This commit breaks my compiling environment with kdesrc-build.

Implemented buttonGetIcon and buttonSetIcon

Updated with the code against master

Wasn't supposed to be closed. It closed with a wrong commit on my side branch.

Changed button code to be transparent when there's no text.

Updated Diff to track changes based on master

Updating revision to match the current branch

This broke the compilation process on my machine. I just tested with a clean version of KDE Neon, Poppler 0.62, and it doesn't compile, something about FormFieldsSignatures.

Documentation and fixing spaces

Implemented setInterval/clearInterval. WidgetScripts are now supported on pageOpening/Closing.

In D21202#466066, @aacid wrote:

Do you have some files that exercise this?

Who would we autotest this?

Declared g_displayProto as std::unique_ptr

Remove unintentionally left qDebug()

Loops now use const and more efficient way of acessing LinkedList

Removed useless iterator

Changed for to range based loops

Fixed copyright

Added documentation

Hmmmmm. I can think of checking if the '\n' is in the search bar.

It probably will work, I'll try it

In D19717#454164, @davidhurka wrote:

Made the necessary changes to work with any type of space.

In D19717#454108, @davidhurka wrote:

In D19717#453821, @aacid wrote:

There's a downside to this is that now if you actually put a newline character in the search it will fail where previously it worked.

On the other hand typing an actual newline character is kind of hard (i had to copy it from a newline in kate) so maybe we can just accept that noone really knew how to do that :D

Opinions?

The use case to insert a newline could be:
Someone is testing a LaTeX document, and searches for a passage from the source code (maybe some verbatim code).
One would just copy the passage in Kate and paste it into the search box in Okular.

In my opinion is better to have it this way, I guess most users don't know about the newline.

Ping on this.

Yes, it should. I had some oversights that I hope are fixed now.

• Bug fixing. Also, fixed some things I'd not seen before

I wasn't initializing m_wholeWords in searchLineEdit, that was causing it. Hope it works now.

Fixed variable not initalized. Also, now you won't find words split with -, like Oku-\nlar

Doesn't find anything no matter what direction.

• Well, now it proves it doesn't find anything, is this sufficient?

It shouldn't find anything, and it doesn't.
If not, I'll take a deeper look when I get home, this was just a top of my head solution.

Are you okay with the method?

Just added some screenshots with the results.

Updated with new icons, should use latest breeze-icons. Also fixed typo

Ping

In D18358#426098, @ngraham wrote:

We're waiting for icons, but I just heard not 5 minutes ago that they're in progress, in fact.

I think it has most cases covered, I added a lot of tests which reflect on the new changes.
I'll wait on feedback.

Fixed word being in the same textEntity and added some new tests.

In D19123#423152, @davidhurka wrote:

In D19123#414714, @joaonetto wrote:

This works properly for most cases, but still, it has some limitations.
If searching for r on a text, and the text contains R$, the R will be found.
Every word that has a space behind and a symbol after, or a symbol before and space after, or symbol before and after, will be found.
I guess that's a good trade-off, but we can work to improve it, if wanted.

This sounds optimal to me, not like a trade-off. Or how could it be improved?

By requiring whitespace on both sides, BAUD would not find USART0.BAUD, and argv would not find char *argv[].

Fixed typo

Removed useless code, remodeled tests and fixed corner case

Added some tests to validate the diff, and fixed a bug.

If I understood well, this should fix the binary compability issues.

Fixing binary compability issues

I'll fix the binary compatibility issues, I didn't know it would break it.

This works properly for most cases, but still, it has some limitations.
If searching for r on a text, and the text contains R$, the R will be found.
Every word that has a space behind and a symbol after, or a symbol before and space after, or symbol before and after, will be found.
I guess that's a good trade-off, but we can work to improve it, if wanted.

Updated comment on SearchText