Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support scaling the UI based on terminal size #10

Open
ristomatti opened this issue Aug 2, 2024 · 6 comments
Open

Support scaling the UI based on terminal size #10

ristomatti opened this issue Aug 2, 2024 · 6 comments
Labels
enhancement New feature or request visuals UI stuff
Milestone

Comments

@ristomatti
Copy link

Describe the solution you'd like

The position and width of the columns to scale based on terminal width.

Is your feature request related to a problem? Please describe.

I use a tiling window manager on an ultrawide monitor. I usually keep a column of relatively narrow (~80 character) terminals on one side of the monitor for secondary information. While hours is perfectly usable with 80 char width, it bugs me that the "worked on for" column isn't visible, even though there'd be plenty of room (with short task titles at least).

Currently the Task List View requires around 90 character wide window to fit. The Task Log Entry view requires 115 character wide terminal to fit in all columns. At this width, it unnecessarily cuts the description shorter than the available space. The third column on the other hand is unnecessarily far apart from the second one.

Describe alternatives you've considered

N/A

Additional context

In case relevant: I'm using Ubuntu with i3 window manager and kitty as the terminal.

Task List View on a 80 character wide terminal:

image

Task Log Entry View on a 115 character wide terminal:

image

@ristomatti ristomatti added the enhancement New feature or request label Aug 2, 2024
@ristomatti
Copy link
Author

Aside: I'm currently testing omm also. I noticed it also seems to have the same issue. I hope it's enought to report this here only as both make use UI component libraries and look very much alike. 🙂

@dhth dhth added this to the v0.4.0 milestone Aug 3, 2024
@dhth
Copy link
Owner

dhth commented Aug 3, 2024

I've been meaning to do that. Since you already tried out omm, could I ask you to take a quick look at https://github.com/dhth/prs, and see if its responsive layout is in line with what you described above?

@dhth dhth added the visuals UI stuff label Aug 3, 2024
@ristomatti
Copy link
Author

ristomatti commented Aug 3, 2024

Yup that would fill the need for hours or omm as they only have few columns.

I have a few ideas to consider in case you happen to be interested in experimenting. I'll use prs as an example since it has more information to display. Also because I realized I seem to have some pretty ancient open PR's that are perfect to higlight the issues/ideas. 🙂

I'll let my MS Paint style annotations speak for themselves....

image

@ristomatti
Copy link
Author

ristomatti commented Aug 3, 2024

Other suggestions that might be more work to implement:

  • Wrap long PR tittles instead of truncating
  • On small windows(*), display the fields as a list instead of columns

@ristomatti
Copy link
Author

ristomatti commented Aug 3, 2024

One more suggestion. It might be preferable to to just refuse to render at some point instead of trying to fit everything when the terminal size shrinks past a specified limit:

image

Here's a screenshot of btop doing just that:

image

Another example from ticker:

image

@dhth
Copy link
Owner

dhth commented Aug 4, 2024

Thanks for the great suggestions 🙂
I'll definitely incorporate the following:

  • refuse to render when width/height shrinks below a threshold
  • better use of spacing when the window size is large enough

I'll experiment a bit with the other ones.
I've also opened an issue for this for prs here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request visuals UI stuff
Projects
None yet
Development

No branches or pull requests

2 participants