Ability to adjust applied paddings/margins before applying them to a view

[MFlisar]

Desired feature

Whenever new insets are applied I want to be able to adjust them. That's especially useful if insets do depend on user settings, e.g. I may change paddings/margins of a view if the user changes a setting and in such cases, I can't use insetter.

Example

Consider a list that always expands behind the navigation bar and an optional "dock" above the navigation bar. If the dock is visible, the content list needs more bottom padding than if the dock is not visible to allow that all items can be scrolled up to the interactable region...

Currently I have to do everything fully manually like following:

Insetter.builder()
            .padding(windowInsetTypesOf(navigationBars = true))
            .setOnApplyInsetsListener { view, insets, initialState ->
                val extraPadding = if (Prefs.desktopDock.value) { 48.dpToPx } else 0
                view.updatePadding(bottom = insets.getInsets(WindowInsets.Type.navigationBars()).bottom + initialState.paddings.bottom + extraPadding)
                L.tag("DESKTOP").d { "LISTENER: Padding Bottom: ${view.paddingBottom}" }
            }
            .applyToView(binding.rvData)

Suggestion

Maybe you can add an optional hook that can adjust paddings/margins before applying them. Something that can adjust the values before applying them in following 2 places:

https://github.com/chrisbanes/insetter/blob/51cf4ab5ff3341506bcb97c57f51c476792930f5/library/src/main/java/dev/chrisbanes/insetter/Insetter.kt#L670

https://github.com/chrisbanes/insetter/blob/51cf4ab5ff3341506bcb97c57f51c476792930f5/library/src/main/java/dev/chrisbanes/insetter/Insetter.kt#L712

[chrisbanes]

Hi, Insetter isn't really designed for custom cases like that. It's designed to cover the 90% simple cases which most developers need. setOnApplyInsetsListener is the escape hatch which allows developers to write their own logic, so I think what you have is fine.

I'm going to close this as working as intended, as I can't think of a nice way to model what you're asking for, without making the API more complex.