Bug 360020

We try to do this, so what you're seeing is apparently something which escaped our attention.

Could you please describe what exactly goes wrong, preferably with screenshots, and reopen this bug?

=> screenshot, please.

Created attachment 97650 [details]
Looks reasonable to me

FYI, this is what I get (breeze-dark for both the icon theme and the color theme).

The [+] in the TagListWidget is clearly wrong (I only noticed when I went looking).

The icons suck and the link colors are wrong, but these colors come from the respective themes.

Comment on attachment 97650 [details]
Looks reasonable to me

Tag "+" and general tagwidget thing is fixed in the header commit series (patch that removes the fugly qss abuse ;-)

PS: oc. i wanted to see a screenshot from Hohyeis, illustrating *his* concern ;-)

Created attachment 97651 [details]
Message window

The Trojita I have is version 0.6 using Qt5.5.

I see the problem in the message pane of the aggregate main window -- not in the independent message window.
The values From, To, and Tags fields all have a poor combination of background and foreground colors.

In Jan's screen capture, there are also problems.
The highlighted subject line and the "+" sign by Tags.

The tagwidget is addressed.

The problem seems to be about the link colors, but what strikes me odd is that the base color in the message tree seems to be black, while it's apparently white on the filter line and the message view itself it seems to be white, where the partwidget is black again.

Do you use KDE and its overly complex color schemes?
Can you please export and attach yours in case?

I use XFCE. I do not use KDE.
The theme was made with qt5ct, if I recall correctly.
I will attache the color theme from ~/.config/qt5ct/colors

Created attachment 97652 [details]
color file for qt5ct

Base should be black

> I use XFCE.
While the scrot looks like fusion, can you please check whether
    QT_STYLE_OVERRIDE=Fusion trojita
exposes the same issue (I worry Gtk to intervene here)

With QT_STYLE_OVERRIDE=Fusion , Trojita displays the same.

> while it's apparently white on the filter line and the message view itself it seems to
> be white, where the partwidget is black again.

That's how my build (latest git, Qt 5.6 from Nov?, Plasma5 from Feb) behaves when I change the color theme at runtime through Plasma's systemsettings. The backgrounds are correct after I quit and restart Trojita.

Hohyeis, could you please confirm that whether these white backgrounds happen all the time, even after Trojita's restart, or whether this is just at the time you switch the theme?

They happen when I Trojita restarts -- even when the theme is not changed during a run of Trojita.
I may be able to build Qt and Trojita myself and see whether the error reproduces.
Currently, I'm using the build which is in Manjaro/community.

Let's see whether it's the xfce QPA plugin:

QT_STYLE_OVERRIDE=Fusion XDG_CURRENT_DESKTOP= DESKTOP_SESSION= trojita

Unsetting variables XDG_CURRENT_DESKTOP DESKTOP_SESSION had no visible effect.

Could you please double-check that you quit the application through (menu) IMAP -> Exit instead of just closing the window? There's code for minimizing to systray and IPC, and Trojita will refuse to start more than one instance at a time.

In other words, please check the output of e.g. `ps auxww | grep trojita` to make sure that there's no Trojita left running.

I have now verified with 'ps' that Trojita is not running before restarting.

I have now built Trojita from the Git repository code with the binary distribution of Qt5.6RC from the Qt project.
It looks the same.

It will be the custom palette calls.

a) EmbeddedWebView:
    // Redmine#3, the QWebView uses black text color when rendering stuff on dark background
    QPalette palette = QApplication::palette();
    if (palette.background().color().lightness() < 50) {
        QStyle *style = QStyleFactory::create(QStringLiteral("windows"));
        Q_ASSERT(style);
        palette = style->standardPalette();
        setPalette(palette);
    }

and b) MessageView
   QPalette pal = palette();
   pal.setColor(backgroundRole(), palette().color(QPalette::Active, QPalette::Base));
   pal.setColor(foregroundRole(), palette().color(QPalette::Active, QPalette::Text));
   setPalette(pal);

If (a) is the trigger, that's kinda our problem (and we've css to define colors of all elements in the message)
(b) would imply that qt5ct uses the style hooks to alter the palette for each widget during polishment - and that would be terrible behavor and a bug in the qt5ct platform theme.

@Hohyeis
ready do compile some patches?

Disregard my last question ;-)

I've uploaded some patches which appear to address everything that I was able to see, I think. Please take a look at the patch series which ends at https://gerrit.vesnicky.cesnet.cz/r/634/ ; there's a button "Download" at the right top which shows you a command for checking out these changes into your local git tree.

Git commit 4557439352a85ac9ff9abbaf52cdb0e23fb9d156 by Jan Kundrát.
Committed on 05/03/2016 at 16:17.
Pushed by gerrit into branch 'master'.

Use Qt5's features for QLineEdit actions

Our LineEdit started as a class offering a clear button at the right
edge even on styles where this is not available. A feature like this
however got added to Qt in version 5.2, so it makes sense to start using
it instead.

This change makes it possible to deprecate the QSS usage, and therefore
fixes the style issues on (some) dark themes or dynamic palette changes.

The Qt's features do not work on QToolButton level, but on a QAction
level. This means that we have to open the QMenu manually.

The copyright info change reflects the fact that the history code was
contributed by Thomas in 2013. I'm leaving Glad in that file because he
still started doing this button UI thingy.

Change-Id: I818da0646a0fe6ed6c346c81e70ac6d2ffa0c9fd

M  +32   -69   src/Gui/LineEdit.cpp
M  +0    -6    src/Gui/LineEdit.h
M  +8    -18   src/Gui/MessageListWidget.cpp
M  +1    -1    src/Gui/MessageListWidget.h

http://commits.kde.org/trojita/4557439352a85ac9ff9abbaf52cdb0e23fb9d156

Git commit db916b2a18990cb487195462ff6ab991f20ad6b5 by Jan Kundrát.
Committed on 05/03/2016 at 16:17.
Pushed by gerrit into branch 'master'.

MessageView: Specify color roles without a QPalette detour

By specifying just the desired color roles instead of going through the
QPalette and doing that thing with colors, it seems that dynamic scheme
changes are now supported.

Change-Id: I0ab8fc0935fa91f67056cca5ecfee56424ce7e62

M  +4    -4    src/Gui/MessageView.cpp

http://commits.kde.org/trojita/db916b2a18990cb487195462ff6ab991f20ad6b5

Git commit 0107f850027ee5c190b710dff68c6767b271be55 by Jan Kundrát.
Committed on 05/03/2016 at 16:17.
Pushed by gerrit into branch 'master'.

Rely on systemwide palette for QWebView

This works well enough on this particular machine (a random snapshot of
Qt 5.6), so I'm optimistic that it might even work just fine all the way
back to Qt 5.2.

Change-Id: I894701c56f9e42118b516f9262ccab86f2136908

M  +0    -9    src/Gui/EmbeddedWebView.cpp

http://commits.kde.org/trojita/0107f850027ee5c190b710dff68c6767b271be55

Git commit 53ddfe7ebfe235ec8b0cf5823c81bbe41cda143c by Jan Kundrát.
Committed on 07/03/2016 at 14:32.
Pushed by gerrit into branch 'master'.

Use synthetic CSS for specifying colors of the "web" content

The usual story -- if the current color theme is dark and the QWebView
is showing an HTML message, Bad Stuff™ happens quite easily.

By going through a custom CSS stylesheet, we achieve more or less
consistent results as far as I can see -- including various HTML e-mails
that I have in my test collection. There are of course also e-mails
where it goes horribly wrong, so the real question is "should we try to
emulate dark theme on HTML content, or should we always use white
background in order to "better accommodate all content"?

Thomas was kind enough to add a heuristic which tries to arrive to font
colors which are usable on both dark and bright backgrounds, but as
usually -- it's just a heuristic, and it will break on certain inputs.

The alternative is to always and unconditionally force black-on-white. I
could do that pretty easily.

Change-Id: Iabdf9b0d97448b070fa7aa1ca4302cc6b2c8b77f

M  +27   -0    src/Gui/EmbeddedWebView.cpp
M  +1    -0    src/Gui/EmbeddedWebView.h
M  +1    -4    src/Gui/SimplePartWidget.cpp

http://commits.kde.org/trojita/53ddfe7ebfe235ec8b0cf5823c81bbe41cda143c

Git commit 6a65385a96221a285c9fe9e52d70bf5541071c36 by Jan Kundrát.
Committed on 07/03/2016 at 14:59.
Pushed by gerrit into branch 'master'.

HTML: Support selecting custom color schemes

...because one cannot please everybody, so let's add a funny button for
this. Oh well.
Change-Id: I51b380df4c93fb4e6eef175aaed99eaf742f8cba

M  +54   -16   src/Gui/EmbeddedWebView.cpp
M  +15   -0    src/Gui/EmbeddedWebView.h
M  +14   -0    src/Gui/SimplePartWidget.cpp

http://commits.kde.org/trojita/6a65385a96221a285c9fe9e52d70bf5541071c36

Created attachment 97760 [details]
Main window with message

The colors of background and text look alright now.  User theme colors are used.