paper?

heh, i still think of it as "quantum paper"...

fixed -> material

Container and DecoratedBox aren't necessarily opaque, so the unqualified parenthetical statement is a little confusing.

replaced with "maybe using a ..."

This is a nice short name. It's also a bit of a misnomer if we're going to say that splashes and ripples are drawn with "ink". A longer more horrible but more apt name would be MaterialAncestorDecorator.

as we discussed, i agree that the name is a bit sketchy but i think we want this to be more attractive than Container or BoxDecoration or even Image.

... because in that case ink well and ink response descendants will draw their splashes on the otherwise transparent material

done

I don't think we want DecoratedBox.image and Container.image.

Maybe if we had BoxDecoration.image then one could just write new Ink(decoration: new BoxDecoration.image(...))

Why don't you think we want DecoratedBox.image and Container.image? I mean, I don't know if we do, but maybe we do, if this works out well here...

The problem with only having BoxDecoration.image is that it's still pretty verbose, c.f.:

  new Ink.image(
    image: new AssetImage('cat.jpeg'),
    fit: BoxFit.cover,
    width: 300.0,
    height: 200.0,
 )

  new Ink(
    decoration: new BoxDecoration.image(
      image: new AssetImage('cat.jpeg'),
      fit: BoxFit.cover,
    ),
    width: 300.0,
    height: 200.0,
 )

IMHO we'd want DecoratedBox.image and Container.image constructors for the sake symmetry (because that makes the APIs easier to understand) and we wouldn't want Ink.image, et al because less API is more.

IMHO BoxDecoration.image balances the API weight than the other 3 constructors, but I defer to you.

I think we might want DecoratedBox.image and Container.image, I just think we should see how Ink.image goes before doing it. :-)

video_player provide a Texture, not a Image.
Do you have a solution?

What happens when a Material widget has more than one Ink descendant?

added some prose about this

Scaffold creates a Material widget, so don't most transitions occur "inside Material"?

Yup. I clarified this a bit to say that it's specifically a problem if you move ink features around.

I think the advice we want to provide is: don't allow the layout to be defined by the image's actual size. Either constrain the size of the image or specify it explicitly with width and height.

How about this:

  /// Either the [width] and [height] arguments should be specified, or the                                                             
  /// widget should be placed in a context that sets tight layout constraints.                                                          
  /// Otherwise, the image dimensions will change as the image is loaded, which                                                         
  /// will result in ugly layout changes.                                                                                               ```