+pkasting and tapted

It seems like harmony uses the light color in a lot of places:
https://cs.chromium.org/chromium/src/chrome/browser/ui/views/harmony/harmony_typography_provider.cc?rcl=c2dcc712d18f9e4ebc4eccacd20d959befec9113&l=47

Could we add a new color for the button border?  Or is this all part of the harmony master plan?  FWIW, all UI elements look good on Harmony with the GTK theme except for button borders.

I don't know where button borders get colored -- trying to look through codesearch led me into a morass of functions and I don't have time right now.

Can you debug enough to tell where the button border is fetching its color from in Harmony vs. non-Harmony on Linux?  I saw a Linux-specific fucntion to render native button borders, is that getting called pre-Harmony but not post-Harmony?

> Can you debug enough to tell where the button border is fetching its color from in Harmony vs. non-Harmony on Linux?

On non-harmony, the entire button, border and all, were rendered natively by GTK.  So there was no concept of "button border color" before.

> I saw a Linux-specific fucntion to render native button borders, is that getting called pre-Harmony but not post-Harmony?

It would appear so.  This is how it gets rendered on non-harmony:

#0 0x7fa2524194dc base::debug::StackTrace::StackTrace()
#1 0x7fa24da6dd19 libgtkui::(anonymous namespace)::GtkButtonImageSource::GetImageForScale()
#2 0x7fa251d5fa93 gfx::internal::ImageSkiaStorage::FindRepresentation()
#3 0x7fa251d5ffd3 gfx::ImageSkia::ImageSkia()
#4 0x7fa24da6da95 libgtkui::(anonymous namespace)::GtkButtonPainter::Paint()
#5 0x7fa24de356ce views::Painter::PaintPainterAt()
#6 0x7fa24dde1480 views::LabelButtonAssetBorder::Paint()
#7 0x7fa24de3e70c views::View::OnPaintBorder()
#8 0x7fa24de3e4af views::View::OnPaint()
#9 0x7fa24dddb002 views::Button::OnPaint()

Are you recommending we should always draw native GTK buttons?  Personally, I would be in support of this.

Ah ha.  I was looking in the wrong button class.  Button border colors for these are computed in MdTextButton::UpdateColors().  Basically, the border is based on the text color.

I am leaning towards WontFix on this.  This is one of those cases where our appearance is intentionally not fully native.  The actual color used isn't garish (and, frankly, has better accessibility properties than black-against-dark-grey).

Would like designer opinion here about what principles we should use to decide future questions of "how faithful should we be to the native platform appearance?".

Just as FYI, this is how it looked before, and how a native app looks.

Also Linux users are especially care about integration, and we're likely to get some complaints if we deviate too much from the native look.

Deleted: Screenshot from 2017-12-07 17-10-34.png 55.2 KB

	Screenshot from 2017-12-07 17-10-34.png 55.2 KB View Download

Deleted: Screenshot from 2017-12-07 17-11-03.png 65.4 KB

	Screenshot from 2017-12-07 17-11-03.png 65.4 KB View Download

Yep.  Harmony is a balancing act between native concerns, cross-platform coherency, and consistency with Material Design.  I expect to get pushback from all directions.  (And I suspect Mac users are even more pedantic about platform appearance than Linux users.)

I take it that this is intended behavior.