You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This commit was created on GitHub.com and signed with GitHub’s verified signature.
Feature additions:
Horizontally stretches to fit to terminal width, dynamically resizes
Limitations:
Can not resize terminal to less than 40 characters wide.
Does not handle vertical stretch/resizing, eg., does not stretch to fit entire terminal, and does not resize vertically upon vertical resizing (see "Future feature additions").
Known issues:
If terminal is less than 40 characters wide, there is a mechanism that enforces a minimum width limit of 40 anyways, so the user would need to scroll or make the terminal larger again to fit the window. This mechanism unfortunately makes the program indefinitely stuck (until restart) in a state where it will always be 40 characters wide. Using the program in such a small terminal is seen as such a minor edge case that it could be shipped anyways.
Future feature additions (for v0.2.2 release):
Add vertical stretch/resizing. This would mean the following:
Make the terminal fit to size vertically. All of the excess vertical space, should be padded with empty rows. The empty rows should be placed above the hotkey legend and its horizontal line.
When resizing, the padded rows should be removed dynamically.
If the terminal is not sufficiently large to fit all of the entries, a "push mode" scrolling mechanism should be implemented, so if the terminal fits 9 sources/sinks, when the cursor is at the 9th source/sink, then the program should scroll down so that the 1st source/sink disappears, and the 10th source/sink should be revealed. Potential issue with this protocol is how multiline-length source/sink descriptions should be handled, they be truncated by this approach (for example if the terminal is only large enough to display the first out of three lines of the last source/sink in the list). Could mitigate this by automatically scrolling down to reveal the last item in the list fully upon highlight, if it was truncated.
Should enforce some vertical limit. Would be ridiculous if the case needs to be handled, where one source/sink takes up 10 rows in the table, but the terminal is only large enough to display 9 rows for example.