feat: add ability to remove padding in the right split for split slides

[GregoryConrad]

First off, thank you for this amazing library--it is super, super handy.

I'm currently trying to make a split slide with an interactive view in the right split:

The padding present around my widget in the right split is proving to be a bit problematic and I didn't find any API to disable it on a slide-by-slide basis.

For normal text, the current behavior is fine. However, for images/interactive content like I have here, it limits the usable real estate and can clip content you wouldn't expect (see the image above).

I came up with a workaround using a Stack/Positioned with a negative offset to "eliminate" the left/right padding, but the top/bottom padding depends on screen size and the title, which there is no easy way to workaround. Thus, it'd be nice if there was something at the library level to remove this.

I looked into this briefly, but this looks like it could be challenging based on the current FlutterDeckSlideBase:

    return Stack(
      children: [
        ConstrainedBox(
          constraints: const BoxConstraints.expand(),
          child: backgroundBuilder?.call(context) ?? background,
        ),
        Column(
          crossAxisAlignment: CrossAxisAlignment.start,
          children: [
            if (headerBuilder != null) headerBuilder!(context),
            Expanded(
              child: contentBuilder?.call(context) ?? const SizedBox.shrink(),
            ),
            if (footerBuilder != null) footerBuilder!(context),
          ],
        ),
      ],
    );

Any ideas on what I can do?

[GregoryConrad]

Well, I was able to modify my existing approach with a LayoutBuilder to calculate the header height:

      return LayoutBuilder(
        builder: (context, constraints) {
          const footerHeight = 80.0;
          const imposedSlidePadding = 16.0;
          final imposedTopPadding = MediaQuery.of(context).size.height -
              constraints.maxHeight -
              footerHeight;
          return Stack(
            clipBehavior: Clip.none,
            children: [
              Positioned(
                top: -imposedTopPadding,
                bottom: -footerHeight,
                left: -imposedSlidePadding,
                right: -imposedSlidePadding,
                child: YourWidgetHere(
// ...

But the header/footer are still absorbing input events. I can probably find another workaround for that too but it'd be nice to not need such an extravagant workaround regardless.

Edit: found another workaround with using Overlay.of and putting the widget there as an OverlayEntity, but that was really a hack and didn't play nicely with transitions and the marker. Still haven't found a way to get touch input from the header/footer regions.

[mkobuolys]

Hey @GregoryConrad, thanks for your feedback. Indeed, it would make more sense to make the padding configurable for the templates (all of them, by the way). Maybe there are any other parameters that you would like to have as configurable properties?

[GregoryConrad]

Thanks for the quick reply! Padding is the only thing that immediately comes to mind. Perhaps it can be set via the FlutterDeckConfiguration/FlutterDeckSlideConfiguration like other global and slide-specific properties?

I just wonder about the implementation since this isn't just "padding;" the header/footer take up some vertical space and cause the clipping that you can see in the image in the issue description. Perhaps a Stack could be used instead of the current Column, and then wrap each slide component (header, footer, content) in a Positioned to emulate the padding supplied from the configuration?

If we go the route I laid out in the preceding paragraph, another good configuration option would actually be to specify the layering/ordering of the header, footer, and content in the stack. Example: in my situation, I want the content (the graph in my picture) to be at the top of the stack so it receives input events. However, a more common situation may be placing images on the slide and the ideal behavior there may be to have the image laid out below the header and/or footer. (Edit: the header/footer may not actually absorb touch input in this stack layout, so a default of having the content be below the header/footer may be sensible. This could always be tested once/if we go the Stack route to layout slides.)