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

Feature Request: Lower, px-valued, or configurable minimum container height #3071

Closed
pevu opened this Issue Dec 8, 2017 · 9 comments

Comments

Projects
None yet
4 participants
@pevu

pevu commented Dec 8, 2017

Output of i3 --moreversion 2>&- || i3 --version:

Binary i3 version:  4.14.1 (2017-09-24) © 2009 Michael Stapelberg and contributors
(Getting version from running i3, press ctrl-c to abort…)
Running i3 version: 4.14.1 (2017-09-24) (pid 1898)
Loaded i3 config: /home/pao/.config/i3/config (Last modified: Do 30 Nov 2017 20:07:16 CET, 666190 seconds ago)

The i3 binary you just called: /usr/bin/i3
The i3 binary you are running: i3

The minimum container height is too large for monitors in portrait mode (its approx. twice as large as in landscape mode).

There's a bug related to this:

Steps to reproduce
1. create a vertical tiling container
2. open 2 terminals in it (I used urxvt)
3. make the height of the bottom terminal as small as possible
4. focus the top container and open new terminals until the bottom container
   has a height of approx. 16px or lower
5. try to resize any of the terminals vertically (this will fail)

Making the minimum height a fixed px-value (like 16px as an approximate height of one line of text) would probably include fixing above bug.

@i3bot i3bot added the enhancement label Dec 8, 2017

@Airblader Airblader added the bug label Dec 8, 2017

@Airblader

This comment has been minimized.

Show comment
Hide comment
@Airblader

Airblader Dec 8, 2017

Member

IIRC the minimum size is percentage-based, not an absolute value. Can you explain why you need windows that are even smaller? What are they useful for?

I'm hesitant to add an option for this because I don't see what it'd be useful for (yet).

Member

Airblader commented Dec 8, 2017

IIRC the minimum size is percentage-based, not an absolute value. Can you explain why you need windows that are even smaller? What are they useful for?

I'm hesitant to add an option for this because I don't see what it'd be useful for (yet).

@pevu

This comment has been minimized.

Show comment
Hide comment
@pevu

pevu Dec 8, 2017

For a 1080p screen, in portrait mode the absolute screen height is 1920px. 5% of 1920 are 96px or 6 lines of 16px each. 6 lines of text is too large for a minimum window size, people shouldn't reach that limit that easily. For reference, the Windows 10 taskbar has a height of 40px .

I put monitors in portrait mode, because I like the extra vertical space. It's a bit of a bummer to see i3 waste it.

edit
Sry, forgot my usecase: I have a browser window and some terminal windows (maybe chat, htop, or status log of some long running program (up/download, server status, etc)). You can't put the terminals horizontally next to the browser window, because website designers kind of expect the browser window be at least 1050px wide. So I have to put the terminals above or below the browser window, but would like the browser window to be as large as possible at the same time.

pevu commented Dec 8, 2017

For a 1080p screen, in portrait mode the absolute screen height is 1920px. 5% of 1920 are 96px or 6 lines of 16px each. 6 lines of text is too large for a minimum window size, people shouldn't reach that limit that easily. For reference, the Windows 10 taskbar has a height of 40px .

I put monitors in portrait mode, because I like the extra vertical space. It's a bit of a bummer to see i3 waste it.

edit
Sry, forgot my usecase: I have a browser window and some terminal windows (maybe chat, htop, or status log of some long running program (up/download, server status, etc)). You can't put the terminals horizontally next to the browser window, because website designers kind of expect the browser window be at least 1050px wide. So I have to put the terminals above or below the browser window, but would like the browser window to be as large as possible at the same time.

@Airblader

This comment has been minimized.

Show comment
Hide comment
@Airblader

Airblader Dec 9, 2017

Member

I see. I still don't think this requires an option, but instead we shouldn't have such an arbitrary size restriction. Perhaps it'd make sense to just reduce the restriction to zero. Do you want to submit a PR?

Member

Airblader commented Dec 9, 2017

I see. I still don't think this requires an option, but instead we shouldn't have such an arbitrary size restriction. Perhaps it'd make sense to just reduce the restriction to zero. Do you want to submit a PR?

@pevu

This comment has been minimized.

Show comment
Hide comment
@pevu

pevu Dec 9, 2017

I agree about removing the restriction altogether. There won't be a pull request from me for this though, at least not until I'm able to finish some ongoing personal projects.

pevu commented Dec 9, 2017

I agree about removing the restriction altogether. There won't be a pull request from me for this though, at least not until I'm able to finish some ongoing personal projects.

@Airblader Airblader added accepted 4.14 and removed bug labels Dec 9, 2017

@Airblader

This comment has been minimized.

Show comment
Hide comment
@Airblader

Airblader Dec 9, 2017

Member

No worries; PRs are of course welcome by anyone. I'm fairly certain the fix is trivial and only involves changing all the 0.05 in src/commands.c to 0.0s, but I haven't tested it.

Member

Airblader commented Dec 9, 2017

No worries; PRs are of course welcome by anyone. I'm fairly certain the fix is trivial and only involves changing all the 0.05 in src/commands.c to 0.0s, but I haven't tested it.

@jolange

This comment has been minimized.

Show comment
Hide comment
@jolange

jolange Dec 25, 2017

Contributor

So your proposal is to allow any size >0% (not >=0%)?

Contributor

jolange commented Dec 25, 2017

So your proposal is to allow any size >0% (not >=0%)?

@Airblader

This comment has been minimized.

Show comment
Hide comment
@Airblader

Airblader Dec 25, 2017

Member

I think that would be reasonable, yes. If you think otherwise, please let me know. :-) Ultimately, a zero size is pointless independent of the screen size; but any positive value will come down to screen size and personal taste. There's no real good technical reason to impose any restriction here anyway. A one pixel tall window may be useless in terms of interaction, but there also isn't a reason why it cannot exist if the user so chooses.

Member

Airblader commented Dec 25, 2017

I think that would be reasonable, yes. If you think otherwise, please let me know. :-) Ultimately, a zero size is pointless independent of the screen size; but any positive value will come down to screen size and personal taste. There's no real good technical reason to impose any restriction here anyway. A one pixel tall window may be useless in terms of interaction, but there also isn't a reason why it cannot exist if the user so chooses.

@jolange

This comment has been minimized.

Show comment
Hide comment
@jolange

jolange Dec 26, 2017

Contributor

I completely agree with that, but I see a minor practical "issue". When using a resize mode, the effective minimum size depends on the current size before resizing and the step width (10% in the default config). E.g. if the current window takes 11%, you can resize it down to 1% (close to nothing), but if it was 9% you cannot get any smaller (staying at a sizable percentage). This is technically fine, but might feel a bit inconsistent in practice. It has been the same before, of course, but maybe not that noticeable due to the quite sizable minimum percentage that was enforced anyway.

An alternative would be to clip it at a minimum value, i.e. if the next step would go to a negative value the size would be set to MIN%. This could naturally be 0 (which does not make much sense, as you said) or a fixed minimal value again (which we wanted to get rid of in the first place).

This is a very subjective point, I guess, and - as I said - a minor one. I just realized this while implementing and wanted to collect opinions on it. It's probably an edge case anyway and people tend to use the mouse for finer resizings (at least I do).

Contributor

jolange commented Dec 26, 2017

I completely agree with that, but I see a minor practical "issue". When using a resize mode, the effective minimum size depends on the current size before resizing and the step width (10% in the default config). E.g. if the current window takes 11%, you can resize it down to 1% (close to nothing), but if it was 9% you cannot get any smaller (staying at a sizable percentage). This is technically fine, but might feel a bit inconsistent in practice. It has been the same before, of course, but maybe not that noticeable due to the quite sizable minimum percentage that was enforced anyway.

An alternative would be to clip it at a minimum value, i.e. if the next step would go to a negative value the size would be set to MIN%. This could naturally be 0 (which does not make much sense, as you said) or a fixed minimal value again (which we wanted to get rid of in the first place).

This is a very subjective point, I guess, and - as I said - a minor one. I just realized this while implementing and wanted to collect opinions on it. It's probably an edge case anyway and people tend to use the mouse for finer resizings (at least I do).

@Airblader

This comment has been minimized.

Show comment
Hide comment
@Airblader

Airblader Dec 26, 2017

Member

if the current window takes 11%, you can resize it down to 1% (close to nothing), but if it was 9% you cannot get any smaller (staying at a sizable percentage).

I think this is pretty sensible behavior, even in practice. If we clipped it to 0, we would make it easier to create useless windows which would probably raise issues sometimes (granted, if the window has 10% before resizing, this could still happen now). If we clipped to a fix size only if the resize would lead to a negative value, then we'd have pretty weird behavior: if your window is smaller to start with, resizing ends up with a bigger window than if the window had been a bit bigger beforehand.

So in summary, I think it's reasonable that if the user wants to make their 9% window a bit smaller, they need to use a more fine-grained resize control. :-)

Member

Airblader commented Dec 26, 2017

if the current window takes 11%, you can resize it down to 1% (close to nothing), but if it was 9% you cannot get any smaller (staying at a sizable percentage).

I think this is pretty sensible behavior, even in practice. If we clipped it to 0, we would make it easier to create useless windows which would probably raise issues sometimes (granted, if the window has 10% before resizing, this could still happen now). If we clipped to a fix size only if the resize would lead to a negative value, then we'd have pretty weird behavior: if your window is smaller to start with, resizing ends up with a bigger window than if the window had been a bit bigger beforehand.

So in summary, I think it's reasonable that if the user wants to make their 9% window a bit smaller, they need to use a more fine-grained resize control. :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment