I just noticed there are differences elsewhere like the borders around the color boxes in System Settings. This bug is likely not in Okular, but I have no idea where to report it. Maybe you can identify the problem by checking where Okular gets this color from?

which style are you using?

(In reply to Albert Astals Cid from comment #2)
> which style are you using?

It was Breeze Dark, but I changed a few of the colors in System Settings, as shown in the screenshots. 

While the unexpected color change seems to be a separate bug, I think Okular should still use the 'view background' color.

i'm asking for the widget style, not color theme.

(In reply to Albert Astals Cid from comment #4)
> i'm asking for the widget style, not color theme.

Breeze with default config.

There are two issues reported here. 
The one in the description is definitely an "Okular" thing. The color used by the background is a mix between colors from the palette, which explains the behavior you describe. 
To double check, can you veryfy that you get the same colors when changing widget style ? 

okular -style plastique 
or
okular -style fusion
(depending on whether you use the kde4 or the kf5 version of okular)

For the 'issues' reported in comment1, could you post a screenshot ?

Yes, the problem remains when using a different widget style. 

The issues I mentioned in comment 1 are shown in the screenshots I posted earlier. Look at the top two color boxes on the right side of System Settings main window. The border is the same color as the background in Okular, dark in the first image and light in the second.

(In reply to rasq37 from comment #7)
> Yes, the problem remains when using a different widget style. 
> 

> The issues I mentioned in comment 1 are shown in the screenshots I posted
> earlier. Look at the top two color boxes on the right side of System
> Settings main window. The border is the same color as the background in
> Okular, dark in the first image and light in the second.

Well if you are talking of the button 'outline', this is different, and intended. It is a mix  and is a mix between the "button" and the "buttonText" color. This is to make it stick out.
The fact that it resemble the okular background is probably just a coincidence.

So bottomline: the issue with the okular background (about which this bug report originally is), and the fact that it is not using the "View" color, has nothing to do with breeze. 

Reassigning to Okular, and sorry for the back and forth.

(In reply to Hugo Pereira Da Costa from comment #8)
> It is a mix  and is a mix between the "button" and the "buttonText" color.

In those two pictures the only change that was made was window background color. I changed it from #191919 to #181919 which should be imperceptible, and the button colors were not changed at all. This does not seem like intended behavior. Is it possible there is a bug occurring when mixing colors?

I guess I misunderstood which colors you refer to.
If we are talking about the 1 pixel outline that surrounds buttons, then this one does not change from one screenshot to the other and this is the intended behavior I am talking about

If we are talking about the "shadow" around the color square, in the color buttons, then I have no idea how this one is calculated and this is again unrelated to breeze (and okular)

> the "shadow" around the color square, in the color buttons

Yes, this is what I meant. So maybe Okular or System Settings devs can track down where the bug is occurring and move this report to wherever it belongs?

This is 'QPalette::Dark', which was also traditionally used as the (darker) background next to white pages in KOffice, Calligra, and also for MDI window areas.

If you used the view color, you would get a glowing white as the background with standard (bright) color schemes, and therefore have no contrast to the pages.

Unfortuately KColorScheme has no suitable configurable color for those background areas.

Except suggesting to make the color configurable I have no idea how to compute a suitable color derived from the other colors configured by the user.

About the unexpected color change: does this mean the bug is from QPalette? I don't understand how that's related to my KDE color theme.

About Okular's background color, this is a separate issue, so I made a feature request here: https://bugs.kde.org/show_bug.cgi?id=372055

If I understand this report correctly, this is not really a bug (in QPalette, or whereever the actual color for QPalette::Dark is computed).

While the documentation states that QPalette::Dark is darker than the other colors, applications should never have invisible color combinations. So if your background color is already quite dark, then QPalette::Dark has to be _brighter_ to be visible against the dark background (simply speaking, you cannot get darker than black, and you cannot read black on black).

Since Okular does not actually render anything (text or graphics) over this background, it could indeed use any dark color, e.g. half brightness of QPalette::Window, even if it was already black. If it was decided not to implement bug 372055, then this could be a practical solution.

Ok, I suppose that makes sense. The color changes a lot more than I feel like it should, but it wouldn't matter if I could pick the color myself. I hope to see you add this feature.

FWIW, choosing the background color within Okular itself is tracked with https://bugs.kde.org/show_bug.cgi?id=182994