`imePadding` question. I have a simple layout (I t...

# compose

[Travis Griggs]

imePadding question. I have a simple layout (I think)

Surface
  Column
    Row (height fixed)
    LazyColumn (weight(1f) and imePadding())
    Box (height fixed)

It's shown on the left. When I activate the keyboard, I get what's on the right. I don't understand why I get this big gap between keyboard and bottom of lazy column. It's directly tied to the height of the last fixed box.

Perhaps I'm violating an assumption, that things like imePadding are only supposed to be used on edge adjacent components?

[Stylianos Gakis]

Right now, below the real lazy column content you got some padding equal to the IME height, and under that you got the box.
So yeah, the total space below the lazy column will be ime + box height.
Is there some part of this which feels surprising here?

[Stylianos Gakis]

If you put a background color on the box itself you will also better understand where that is placed and where the padding is. Which means here that the box background color simply won't show, it'll be under the IME as far as I understand from the height of the box I see here.

[Travis Griggs]

no, i don't think that's it. The distance between LzyClm and keyboard top is equal to the height of the dark gray box. If I make the dark gray box be 30.dp, it will be a much narrower gap, about 30.dp, but nothing draws in that gap

[Travis Griggs]

The box DOES have a background color of DarkGray. It is covered up (I believe) by the keyboard

[Stylianos Gakis]

> The box DOES have a background color of DarkGray. It is covered up (I believe) by the keyboard
Yeah that's what I said too.

> no, i don't think that's it. The distance between LzyClm and keyboard top is equal to the height of the dark gray box. If I make the dark gray box be 30.dp, it will be a much narrower gap, about 30.dp, but nothing draws in that gap
That's exactly what I said as well 😅


"...the total space below the lazy column will be ime + box height."
If you want, flip the order in which the padding and the box come in your column to make it make a bit more sense

[Travis Griggs]

I wondered if we were saying the same thing, just differently I apologize. IIUC, you're saying its doing exactly what its doing because that's the way I've coded it. Which I accept. But I don't understand why. I think my model of how the imePadding works might be flawed. If it just adds padding based on the keyboard size, it doesn't really make sense to use/add it on an element that is not edge adjacent, is that correct? If it just naively says "add padding equal to size" regardless of where it's at globally, then I don't see how it would ever be useful for non-adjacent elements

[Stylianos Gakis]

imePadding is just like saying Modifier.padding(bottom = x.dp) where X is the height of the keyboard atm, that's all it is indeed.

[Travis Griggs]

Sigh... that's disappointing. I guess I assumed it was super... something. It's just really primitive in some ways.

is there no way to force internal (not edge adjacent) components to stay in view when the kb opens then?

Maybe?

Box
  Footer (fixed height and tied to bottom)
  Column (full size)
    Header
    FlexibleList (ie LazyColumn)
    Box (imePadding when ime.isVisible and same height as footer when not)

[Stylianos Gakis]

I really would hate it if it were super something tbh. Having hard to understand magic is always something I regret using down the road.

If you want insets equal to the IME, but you already know that you have consumed X amount of insets at the bottom, you can say exactly that by doing something like

val boxHeight = 50.dp
Surface {
  Column {
    LazyColumn(Modifier.weight(1f).consumeWindowInsets(PaddingValues(bottom = boxHeight)).imePadding())
    Box(Modifier.fillMaxWidth().height(boxHeight))
  }
}

to see if this is what you were looking for in the first place.

Since the way that insets are passed down the tree is through modifier locals, if someone above you in the tree has already consumed some insets, this is recorded inside those locals so that the child composable won't also apply those insets, and get double the spacings there.
consumeWindowInsets allows you to manually inform the downstream modifiers that you know that you've already consumed 50.dp worth of insets towards the bottom, so if the IME is at height 40.dp, then you will not receive anything from imePadding(). If the IME is at 80.dp height, then since you've already consumed 50.dp from the box, it will only give you the rest 30.dp as paddings.

[Travis Griggs]

AHA!!! This is the piece of the puzzle I've been looking for. Thank you so much @Stylianos Gakis!

[Stylianos Gakis]

And no magic involved 😉