This is something we'll have to address for all dialogs as we switch to Harmony. It's definitely the case that we don't want to have every dialog (re)define its own MD constants.

I don't claim that this is the best way forward, but changing from constants to getters is one option that springs to mind:

int GetHorizontalPadding() {
  return ui::MaterialDesignController::IsSecondaryUiMaterial() ? kValueMd : kValue;
}

We've had to do something similar in c/b/ui/layout_constants.cc so perhaps we should follow that example.

+pkasting as I heard he may be contributing to updating dialogs for Harmony and he's familiar with this general dilemma.

Yeah, if we want a common set of layout constants, and they need to be controllable at runtime (by IsSecondaryUiMaterial()), we need to use getters of some sort.  It's just a question of where to put them.

Are these things that can go in the Chrome layout_constants.* files, or are they in ui/views/ and would need to go elsewhere?

I believe we're talking about the ones in ui/views/layout/layout_constants.h

I was sort of hoping some of those could move up into chrome/, but probably not.

My guess is that simply changing these from constants to getters and leaving them in the same place is The Right Thing To Do.  We should probably only change them a few at a time, and with testing to make sure changes we make don't break anything we didn't intend to.

This bug doesn't have value at this point, as we've been converting all the dialogs to use a centralized set of getters, and layout_constants.h is now gone.