Allow SplitFixed to set the size of the second container

[pavel-lexyr]

Issue

As per the documentation,

// SplitFixed sets the size of the first container to be a fixed value
// and makes the second container take up the remaining space.
// When using SplitVertical, the provided size is applied to the new left
// container, the new right container gets the reminder of the size.
// When using SplitHorizontal, the provided size is applied to the new top
// container, the new bottom container gets the reminder of the size.

This allows for simple adaptive design if one wants to fix widgets on the left side or on top of the screen. Fixing a widget on the bottom is comparatively complex, (or entirely simple, but not documented).

It would be a helpful change to allow fixing the second container in splits.

Proposed API change:

container.SplitFixed is to allow numbers from 1-cells to -1 as its argument. Providing it with a number like this fixes the second container to the absolute value of the argument. Values of 0 and cells are preserved as is to maintain backwards compatibility.

[mum4k]

Hi @Ludar-Pavel, I think you raise a very good point here.

Can you help me understand which of the following you are proposing?

a) Allow the split functions to take one or the other size as a fixed number, but continue adjusting the other size dynamically according to the available space. I.e. the user can either set the left/top side to a fixed size and the size right/bottom part gets the remaining space as its size, or vice versa.

or

b) Allow the split functions to take both sizes as a fixed number, allowing the user to set both the left/top and right/bottom parts ti a fixed size.

I think (a) is something very workable in the current architecture and we just need to discuss how to change the API. (b) would be harder due to assumptions made by the infrastructure. We can discuss these and try to find solutions if (b) is the goal.

[pavel-lexyr]

(a) is definitely the goal here - it's hard to imagine how (b) would work with the current way layout is set up.

[mum4k]

Thank you for confirming that @Ludar-Pavel, (a) is definitely workable and we just need to agree on how we make the API change.

Before we do that, can you please indicate if this is something you would be interested in implementing, or if you would prefer I do the implementation?

[pavel-lexyr]

I imagine you doing it would incur less overhead - not very versed in Go myself. Do wish you all the best in implementation, though!

[mum4k]

Thank you @Ludar-Pavel, I will update here once it gets implemented.

[spacez320]

Hey @mum4k , any updates on a potential implementation? Would you still be interested in changing the API to allow for this, or interested in possible contributions for it?

[mum4k]

Thank you for expressing interest in this @spacez320. As far as I know, this isn't currently worked on, you are more than welcome to pick it up if interested.

From the API perspective, I would recommend we implement a new option instead of giving negative numbers special meaning when SplitFixed is called. Here is one suggestion, but I am open to other ideas.

1. Keep the meaning of the SplitFixed option as it is today for backwards compatibility.
2. Add a new SplitOption, something like SplitFixedFromEnd that allows to specify the size of the split from right/bottom.

Please feel free to suggest a cleaner way.

[spacez320]

@mum4k I like SplitFixedFromEnd, great suggestion. We'll go with that.

Let me know if there is a timeline I should work against, otherwise I should be able to approach this soon.

[mum4k]

Thank you for offering to help, I will assign this issue to you.

No particular timeline, please work at your convenience. I am happy to tag a new release whenever this will be available.

[spacez320]

@mum4k I'm planning on still adding the SplitFixedFromEnd function and leaving the existing public API alone, but I am proposing an API change under private/.

See: #373

Let me know if that's not ok and we should leave the entire interface alone.

[spacez320]

@mum4k #373 is ready to be looked at.

For anyone who might be following, the above change preserves the entire API and only augments.