starred/termdash
1
0
Fork 0
mirror of https://github.com/mum4k/termdash.git synced 2026-04-26 19:05:52 +03:00
Code Issues 47 Projects Releases 5 Packages Wiki Activity

[GH-ISSUE #292] Allow SplitFixed to set the size of the second container #147

New issue
Open
opened 2026-03-03 16:22:51 +03:00 by kerem · 11 comments
kerem commented 2026-03-03 16:22:51 +03:00
Owner
Copy link

Originally created by @pavel-lexyr on GitHub (Feb 5, 2021).
Original GitHub issue: https://github.com/mum4k/termdash/issues/292

Originally assigned to: @spacez320 on GitHub.

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.

Originally created by @pavel-lexyr on GitHub (Feb 5, 2021). Original GitHub issue: https://github.com/mum4k/termdash/issues/292 Originally assigned to: @spacez320 on GitHub. ## 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.
kerem commented 2026-03-03 16:22:52 +03:00
Author
Owner
Copy link

@mum4k commented on GitHub (Feb 6, 2021):

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.

<!-- gh-comment-id:774417028 --> @mum4k commented on GitHub (Feb 6, 2021): 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.
kerem commented 2026-03-03 16:22:52 +03:00
Author
Owner
Copy link

@pavel-lexyr commented on GitHub (Feb 10, 2021):

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

<!-- gh-comment-id:776885908 --> @pavel-lexyr commented on GitHub (Feb 10, 2021): (a) is definitely the goal here - it's hard to imagine how (b) would work with the current way layout is set up.
kerem commented 2026-03-03 16:22:52 +03:00
Author
Owner
Copy link

@mum4k commented on GitHub (Feb 12, 2021):

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?

<!-- gh-comment-id:777948472 --> @mum4k commented on GitHub (Feb 12, 2021): 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?
kerem commented 2026-03-03 16:22:52 +03:00
Author
Owner
Copy link

@pavel-lexyr commented on GitHub (Feb 12, 2021):

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

<!-- gh-comment-id:778312641 --> @pavel-lexyr commented on GitHub (Feb 12, 2021): I imagine you doing it would incur less overhead - not very versed in Go myself. Do wish you all the best in implementation, though!
kerem commented 2026-03-03 16:22:52 +03:00
Author
Owner
Copy link

@mum4k commented on GitHub (Feb 15, 2021):

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

<!-- gh-comment-id:778928196 --> @mum4k commented on GitHub (Feb 15, 2021): Thank you @Ludar-Pavel, I will update here once it gets implemented.
kerem commented 2026-03-03 16:22:52 +03:00
Author
Owner
Copy link

@spacez320 commented on GitHub (Feb 26, 2024):

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?

<!-- gh-comment-id:1965511582 --> @spacez320 commented on GitHub (Feb 26, 2024): 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?
kerem commented 2026-03-03 16:22:52 +03:00
Author
Owner
Copy link

@mum4k commented on GitHub (Feb 27, 2024):

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.

<!-- gh-comment-id:1966502718 --> @mum4k commented on GitHub (Feb 27, 2024): 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.
kerem commented 2026-03-03 16:22:52 +03:00
Author
Owner
Copy link

@spacez320 commented on GitHub (Feb 27, 2024):

@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.

<!-- gh-comment-id:1966653418 --> @spacez320 commented on GitHub (Feb 27, 2024): @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.
kerem commented 2026-03-03 16:22:53 +03:00
Author
Owner
Copy link

@mum4k commented on GitHub (Feb 27, 2024):

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.

<!-- gh-comment-id:1966861412 --> @mum4k commented on GitHub (Feb 27, 2024): 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.
kerem commented 2026-03-03 16:22:53 +03:00
Author
Owner
Copy link

@spacez320 commented on GitHub (Mar 5, 2024):

@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: https://github.com/mum4k/termdash/pull/373

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

<!-- gh-comment-id:1979212921 --> @spacez320 commented on GitHub (Mar 5, 2024): @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: https://github.com/mum4k/termdash/pull/373 Let me know if that's not ok and we should leave the entire interface alone.
kerem commented 2026-03-03 16:22:53 +03:00
Author
Owner
Copy link

@spacez320 commented on GitHub (Mar 8, 2024):

@mum4k #373 is ready to be looked at.

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

<!-- gh-comment-id:1986192616 --> @spacez320 commented on GitHub (Mar 8, 2024): @mum4k #373 is ready to be looked at. For anyone who might be following, the above change preserves the entire API and only augments.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
devel
lc_reset_example
dependabot/go_modules/devel/github.com/mattn/go-runewidth-0.0.16
release-0-20-0
grid_example
table
v0.20.0
v0.19.0
v0.18.0
v0.17.0
v0.16.1
v0.16.0
v0.15.0
v0.14.0
v0.13.0
v0.12.2
v0.12.1
v0.12.0
v0.11.0
v0.10.0
v0.9.1
v0.9.0
v0.8.0
v0.7.2
v0.7.1
v0.7.0
v0.6.1
v0.6.0
v0.5.0
v0.4.0
v0.3.0
v0.2.0
v0.1.0
Labels
Clear labels   
bug

   
cleanup

   
enhancement

   
enhancement

   
enhancement

   
good first issue

   
help wanted

   
help wanted

   
pull-request

Mirrored from GitHub Pull Request

  
question

   
wontfix
No labels
bug
cleanup
enhancement
enhancement
enhancement
good first issue
help wanted
help wanted
pull-request
question
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/termdash#147
No description provided.