new animation for rAc card generation

chrome/browser/ui/autofill/autofill_dialog_types.h

Index: chrome/browser/ui/autofill/autofill_dialog_types.h
diff --git a/chrome/browser/ui/autofill/autofill_dialog_types.h b/chrome/browser/ui/autofill/autofill_dialog_types.h
index 9b48b0a489ae1549da5fe9a148f555fa95fc0366..f2ebc2c452d60465231f1f7894482e4ce7c22078 100644
--- a/chrome/browser/ui/autofill/autofill_dialog_types.h
+++ b/chrome/browser/ui/autofill/autofill_dialog_types.h
@@ -10,6 +10,7 @@
 
 #include "base/callback_forward.h"
 #include "base/strings/string16.h"
+#include "base/time/time.h"
 #include "components/autofill/core/browser/autofill_metrics.h"
 #include "components/autofill/core/browser/field_types.h"
 #include "third_party/skia/include/core/SkColor.h"
@@ -213,10 +214,11 @@ struct SuggestionState {
 struct DialogOverlayString {
   DialogOverlayString();
   ~DialogOverlayString();
-  // TODO(estade): need to set a color as well.
   base::string16 text;
+  // TODO(estade): should be able to remove this; text is always black.

[groby-ooo-7-16, 2013/09/03 18:50:04]

Remove away. Or will that bite Android, too?

[Evan Stade, 2013/09/03 19:05:37]

Would rather keep this change focused; also verification of "should" in above
statement will require some small effort.

   SkColor text_color;
   gfx::Font font;
+  // TODO(estade): should be able to remove this; text is always centered.
   gfx::HorizontalAlignment alignment;
 };
 
@@ -229,9 +231,12 @@ struct DialogOverlayState {
   // more or less front and center.
   gfx::Image image;
   // If non-empty, messages to display.
+  // TODO(estade): make this a single string, no longer need to support multiple
+  // messages.
   std::vector<DialogOverlayString> strings;
-  // If non-empty, holds text that should go on a button.
-  base::string16 button_text;
+  // The amount of time this dialog is valid for. After this time has elapsed,
+  // the view should update the overlay.
+  base::TimeDelta expiry;

[groby-ooo-7-16, 2013/09/03 18:50:04]

Heh. I learned a new word :)

Should the controller push the status updates instead? We do call UpdateXXX for
lots of other things, so it feels odd to have this pull based.

Amongst other things, it'd hide the entire timer logic from the view and make it
slightly simpler.

[Evan Stade, 2013/09/03 19:05:37]

The reason I did it like this is because the controller doesn't really track
when something starts or stops showing. The controller never says "start
animation", it just knows that for the given state, this is what the dialog
should look like.

The controller/view relationship is pull-based with only "invalidate" messages
(i.e. UpdateXXX) being pushed. The view should be able to pull the current state
at any time, regardless of whether it got an invalidate message.

[groby-ooo-7-16, 2013/09/03 22:21:41]

Well, it sort of does track when it stops showing - DoFinishSubmit is posted
from the ControllerImpl.

I'd have preferred for all the timer stuff to be in the controller (amongst
other things because it's shared across platforms then), but I'm not going to be
too attached to that.

On 2013/09/03 19:05:37, Evan Stade wrote:

 };
 
 enum ValidationType {