I suggested this in D18744#441906.

How about the following approach (not tested)? This way, other parameters (like nameddest) wouldn’t break it and can be added later.

In D20760#455512, @knambiar wrote:

Indeed, I thought about PDF alone (that’s my most pressing use case). In that case, should this combobox mention something like “only for PDF documents”?

Isn’t there a coding convention against non-ascii symbols in source code?

In D19717#454323, @joaonetto wrote:

It should work now, can you test it?

In D19717#454160, @joaonetto wrote:

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.

Hmmmmm, I can treat things differently if there's a new line in the search box.

Or maybe I should find a way to treat spaces the same as newline chars.

I'll have to take a look in the compare function to see how it would handle, maybe compare alphanumeric only?

If I can't do that, I'll have to treat them differently.

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?

In D18744#438675, @shubham wrote:

Do not delete area

In D18744#438076, @shubham wrote:

@aacid area is a RegularAreaRect object which is a QRect bounding the selected text. "area" is to be deleted in all the cases except the case in which it is not possible to delete it since "area" will not contain any text in it and hence it will be nullptr. (case: if text is empty string) and hence return is called instead of deleting the "area".

In T10034#178456, @ognarb wrote:

There is also asteroidOS that is interesting. It's an open source system for smartwatch build with qt quick. Maybe some collaboration with plasma mobile and/or kde connect could be interesting.

After reading some Wikipedia, I can say:

• Checkmarks use luma (NTSC)
• Your approach uses luma (sRGB)
• QColor::lightness() uses lightness (HSL-bi-hexcone)

In D19542#425756, @yurchor wrote:

Do you mean that the attached test case (text.pdf) works for you (the text in annotation window for the right blue pop-up note is visible)?

Erm, my Okular 1.6.2 already does this, just with another threshold. Below value() = 129, the text (and the header) become white, above value() = 128, they become black.

Isn’t auto a bit confusing as item type? A beginner like me wouldn’t understand that.

Joining KDE would make it easy to offer up-to-date packages to KDE Neon users, right?

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.

In D19183#420861, @aacid wrote:

Isn't this broken when using a RTL layout?

You have little conversation output, and I have little understanding of QEvent.

Up and down arrows are equivalent to arrow key behavior, both in the view area and the PageNumberEdit. It also fits better to documents with RTL page layout (mangas) (if there are such documents).

In D18744#413768, @aacid wrote:

Do not use Alt+Letter for a shortcut, it's bad.

In D18744#405851, @ngraham wrote:

However I wonder if maybe triple-click might be better though? Triple-click is used for "select everything" in word processors, so perhaps we could take advantage of some familiarity there?

In T10047#175270, @rooty wrote:

In T10047#174132, @ngraham wrote:

Yep, agreed. However Bob wasn't looking for a dashboard UI; he very explicitly wanted a "Dock" on the left.

with or without a top/finder bar?

That would be Add Panel -> Application Menu Bar, right?

In T10034#173309, @davidhurka wrote:

From a user point of view, KiCad could benefit from a KDE user interface. […]

There could be a menu item “Help...”, which explains all the terms like Panel, Widget, Launcher, Task Manager, System Tray,... It could just open Help Center -> Plasma Manual -> Using Plasma (-> The Panel). There would be a screenshot like this:

@ngraham wrote:

• Bob right-clicks on empty area of panel and sees "Alternatives..." It does not occur to him to click on it.

In D18623#402834, @emateli wrote:

Perhaps this patch might not be it, but Okular does actually need a "Night Mode" or "Reading Mode" of sorts, in similar fashion to many epub/pdf readers like @filipf suggests.

Maybe these questions would help me to imagine which people I would meet on KDE events:

In T10107#168489, @adrianchavesfernandez wrote:

Just for the sake of brainstorming (stupid/funny included): […] current country, political preferences, music preferences, movie preferences, book preferences, sport preferences, videogame preferences, number of pets and their species…

Additionally: General/special interests.

In D18238#394075, @ngraham wrote:

I'm not really sold either. No other app has this setting. It seems like one of the major reasons why we have a color scheme and color chooser system is precisely so individual apps don't have to implement features like these themselves.

I think this is okay for graphic areas, while the color scheme is good for generic GUI elements (text areas without graphics).

In D18238#394075, @ngraham wrote:

Kate uses the "Selection Background" color to highlight search results and it works okay.

Yes, but it also uses "View Background", while the background color of a PDF file can be different.
Picture with search (find bar, thumbnails panel) in PDF from https://www.dpdhl.com/content/dam/dpdhl/en/media-center/investors/documents/annual-reports/DPDHL_2017_Annual_Report.pdf
How about just inverting the color?

From a user point of view, KiCad could benefit from a KDE user interface. It’s a well known and probably great EDA tool, but every time I try to get started, the bad UI stops me. (But that’s common for almost all EDA tools I know.) (Yes, it’s UI could also be great with wxWidgets, which it uses currently.)

I think, this action should be in the menu, under “Zoom in” and “Zoom out”. That’s the way I learn about available actions, when I customize my toolbars.