D13777: KMessageWidget : revert to using highlight colour for Information style (WIP)

Thu Jun 28 15:14:52 UTC 2018

rjvbb added a comment.

  > Another idea would have been to have the widget style alter the appearance like it already does for things like `KTitleWidget`

  Care to develop?

  > - Suspend output in a Konsole window that has a dark background color: the text is unreadable.

  By hitting ^S? I get a yellow background regardless of the palette but it is possible that you're right that I should just use the application palette. Or (or and) maybe text should take the background colour intensity or better yet, colour contrast into consideration. Because what would happen if someone uses a dark scheme with a light (green or blue) colour for regular text, wouldn't that also lead to unreadable text?

  > - All Information-style widgets have a gray background.

  That depends on your palette. They are grey only when you also use grey (or black or white) tooltips. If that's the background you chose for delivering one kind of informational feedback, why not also use it for other kind(s)?

  > - Positive-style widgets are now blue.

  And why is that a problem? If you don't like blue, use a different palette? I agree blue is a problem (for physiological reasons) but in general, not just for positive messages.

  It would help here if there were documentation about what those messages are supposed to do. But conceptually speaking I think it's perfectly appropriate that they use the highlighting colour.

  *This* is where consistency comes in, IMHO.

  > - One of the goals was to match the colors of the Kirigami equivalent. Consistency is important.

  I've said this before, the consistency argument doesn't fly here IMHO, or rather, it works against the current state of things. Kirigami uses QtQuick which is a completely different beast than QtWidget-based things, and depending on the version you use it will not even use your selected widget style. Kirigami is also the newcomer, and IMHO it's not up to existing software to adapt to newcomers but up to those to adapt to the existing environment.

  > - There's no kind way to say this, but I don't think the new colors are attractive.

  There's also no kind way to say that you don't have to think so because those are *my* colours. And I'm sure I find the Breeze colour scheme much more disgusting O:-)
  No kind way either of saying that I don't use any kirithingy apps personally, in part because I don't care for the mobile-app look they have: form over function), and that I want to keep the subdued "professional" look I've achieved in the (KTextEditor based) applications I do use extensively.
  I'm reminded of a quote from a KDE ML I read this morning, with which I sadly have to agree:

  > "the wonderful thing about the apparent current mindset of the KDE developers, that the KDE desktop is no longer something for end-users, but just a toy for the edification of its developers. Continuity? Usability?  Bah, who needs that?  Here's some eye-candy instead."

  Let's avoid discussing tastes beyond the fact that one shouldn't impose a particular palette that isn't neutral (= grey scale).

  I notice that Qt's example "Settings Editor" application opens and parses ~/.config/kdeglobals just fine:

  F5967227: Screen Shot 2018-06-28 at 17.02.56.png <https://phabricator.kde.org/F5967227>

  That would mean that QSettings can indeed be used to get the colours to be used from that file. Which ones would we use?

REPOSITORY
  R236 KWidgetsAddons

REVISION DETAIL
  https://phabricator.kde.org/D13777

To: rjvbb, ngraham, #frameworks
Cc: broulik, cfeck, kde-frameworks-devel, michaelh, ngraham, bruns
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20180628/0a2d20fa/attachment-0001.html>