Implement resize by increment#2131
Conversation
|
cell width/cell height can change you have to account for that. And this need to be made optional, I for one hate resize by increments and it does not work well with say tiling window managers. |
|
|
||
| window->widthincr = widthincr; | ||
| window->heightincr = heightincr; | ||
| _glfwPlatformSetWindowSizeIncrements(window, window->numer, window->denom); |
There was a problem hiding this comment.
This should probably be
_glfwPlatformSetWindowSizeIncrements(window, window->widthincr, window->heightincr);
|
On Thu, 14 Nov 2019, 01:51 Kovid Goyal, ***@***.***> wrote:
cell width/cell height can change you have to account for that. And this
need
Yeah, there's a lot that's not in here, I don't have a mac, so that's just
a blind shot in the dark, for instance.
to be made optional, I for one hate resize by increments and it does not
Hah! Well, if we can figure out how to both get what we want, I'd say it's
a good thing we don't agree.
work well with say tiling window managers.
Ugh. Well, it's already going to be optional, so that takes care of that,
but perhaps it's an opportunity. What makes them not play well together?
cheers
Anders
|
|
Yes, looks like it. I went a bit cross-eyed after I got it to work well
enough for my purposes.
…On Thu, 14 Nov 2019, 13:19 Luflosi, ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In glfw/window.c
<#2131 (comment)>:
> @@ -690,6 +692,20 @@ GLFWAPI void glfwSetWindowAspectRatio(GLFWwindow* handle, int numer, int denom)
_glfwPlatformSetWindowAspectRatio(window, numer, denom);
}
+GLFWAPI void glfwSetWindowSizeIncrements(GLFWwindow* handle, int widthincr, int heightincr)
+{
+ _GLFWwindow* window = (_GLFWwindow*) handle;
+ assert(window != NULL);
+ assert(widthincr >= 0);
+ assert(heightincr >= 0);
+
+ _GLFW_REQUIRE_INIT();
+
+ window->widthincr = widthincr;
+ window->heightincr = heightincr;
+ _glfwPlatformSetWindowSizeIncrements(window, window->numer, window->denom);
This should probably be
_glfwPlatformSetWindowSizeIncrements(window, window->widthincr, window->heightincr);
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#2131?email_source=notifications&email_token=AACIW3672ZTAUWGXSMAZUILQTU63HA5CNFSM4JNBBJMKYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCLR255A#pullrequestreview-316911348>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACIW35JX5J5QSRVNK2ZB7TQTU63HANCNFSM4JNBBJMA>
.
|
|
On Thu, Nov 14, 2019 at 05:39:32AM -0800, Anders Eurenius wrote:
> to be made optional, I for one hate resize by increments and it does not
>
Hah! Well, if we can figure out how to both get what we want, I'd say it's
a good thing we don't agree.
I'm fine with having an option to control this behavior defaulting to
off.
work well with say tiling window managers.
>
Ugh. Well, it's already going to be optional, so that takes care of that,
but perhaps it's an opportunity. What makes them not play well together?
Most tiling window managers simply assign their own sizes, not respecting
increments at all.
|
| XFlush(_glfw.x11.display); | ||
| } | ||
|
|
||
| void _glfwPlatformSetWindowSizeIncrements(_GLFWwindow* window, int numer UNUSED, int denom UNUSED) |
There was a problem hiding this comment.
The parameters should be widthincr and heightincr.
|
What should happen when the window size is not a multiple of the cell width/height? This can happen when opening new OS windows or when changing the font size.
Not sure what the best solution is. Here are my changes to your PR so far, feel free to use them if you like: diff --git a/glfw/window.c b/glfw/window.c
index ec306846..20d9926a 100644
--- a/glfw/window.c
+++ b/glfw/window.c
@@ -703,7 +703,7 @@ GLFWAPI void glfwSetWindowSizeIncrements(GLFWwindow* handle, int widthincr, int
window->widthincr = widthincr;
window->heightincr = heightincr;
- _glfwPlatformSetWindowSizeIncrements(window, window->numer, window->denom);
+ _glfwPlatformSetWindowSizeIncrements(window, window->widthincr, window->heightincr);
}
GLFWAPI void glfwGetFramebufferSize(GLFWwindow* handle, int* width, int* height)
diff --git a/glfw/x11_window.c b/glfw/x11_window.c
index 87e66366..4e82a753 100644
--- a/glfw/x11_window.c
+++ b/glfw/x11_window.c
@@ -2042,7 +2042,7 @@ void _glfwPlatformSetWindowAspectRatio(_GLFWwindow* window, int numer UNUSED, in
XFlush(_glfw.x11.display);
}
-void _glfwPlatformSetWindowSizeIncrements(_GLFWwindow* window, int numer UNUSED, int denom UNUSED)
+void _glfwPlatformSetWindowSizeIncrements(_GLFWwindow* window, int widthincr UNUSED, int heightincr UNUSED)
{
int width, height;
_glfwPlatformGetWindowSize(window, &width, &height);
diff --git a/kitty/state.c b/kitty/state.c
index 251dd7c8..aec104e3 100644
--- a/kitty/state.c
+++ b/kitty/state.c
@@ -780,6 +780,7 @@ PYWRAP1(os_window_font_size) {
resize_screen(os_window, w->render_data.screen, true);
}
}
+ glfwSetWindowSizeIncrements(os_window->handle, os_window->fonts_data->cell_width, os_window->fonts_data->cell_height);
}
return Py_BuildValue("d", os_window->font_sz_in_pts);
END_WITH_OS_WINDOW |
|
Oh, nice!
Sorry for being unresponsive, I'll get back to this, hopefully those
evening.
Wrt to what happens if the wm doesn't agree, well, I think the fact that
it's called "hints" in the X nomenclature is all I need to know. (Also, one
side needs to admit defeat here, or we'll derp the window size around until
the user is convinced we're all idiots)
cheers
Anders
…On Fri, 15 Nov 2019, 20:58 Luflosi, ***@***.***> wrote:
What should happen when the window size is not a multiple of the cell
width/height? This can happen when opening new OS windows or when changing
the font size.
1. Live with practically random margin sizes? This somewhat defeats
the purpose of this feature IMO.
2. Should the next resize align to the cell grid again so that the
first resize "step" makes the margins go away/to the default again?
3. Should the OS window be resized in the two situations above so that
the size of the margins doesn't change?
Not sure what the best solution is.
At least on macOS (with the little fix above to make it work and a fix to
change the resize increments when the font size is changed), option 1 is
currently used. I think I would prefer option 2 but that seems a little
difficult or complicated to implement.
In iTerm2, the window is resized when changing the font size, so this
isn't really an issue there.
Here are my changes to your PR so far, feel free to use them if you like:
diff --git a/glfw/window.c b/glfw/window.c
index ec306846..20d9926a 100644--- a/glfw/window.c+++ b/glfw/window.c@@ -703,7 +703,7 @@ GLFWAPI void glfwSetWindowSizeIncrements(GLFWwindow* handle, int widthincr, int
window->widthincr = widthincr;
window->heightincr = heightincr;- _glfwPlatformSetWindowSizeIncrements(window, window->numer, window->denom);+ _glfwPlatformSetWindowSizeIncrements(window, window->widthincr, window->heightincr);
}
GLFWAPI void glfwGetFramebufferSize(GLFWwindow* handle, int* width, int* height)diff --git a/glfw/x11_window.c b/glfw/x11_window.c
index 87e66366..4e82a753 100644--- a/glfw/x11_window.c+++ b/glfw/x11_window.c@@ -2042,7 +2042,7 @@ void _glfwPlatformSetWindowAspectRatio(_GLFWwindow* window, int numer UNUSED, in
XFlush(_glfw.x11.display);
}
-void _glfwPlatformSetWindowSizeIncrements(_GLFWwindow* window, int numer UNUSED, int denom UNUSED)+void _glfwPlatformSetWindowSizeIncrements(_GLFWwindow* window, int widthincr UNUSED, int heightincr UNUSED)
{
int width, height;
_glfwPlatformGetWindowSize(window, &width, &height);diff --git a/kitty/state.c b/kitty/state.c
index 251dd7c8..aec104e3 100644--- a/kitty/state.c+++ b/kitty/state.c@@ -780,6 +780,7 @@ PYWRAP1(os_window_font_size) {
resize_screen(os_window, w->render_data.screen, true);
}
}+ glfwSetWindowSizeIncrements(os_window->handle, os_window->fonts_data->cell_width, os_window->fonts_data->cell_height);
}
return Py_BuildValue("d", os_window->font_sz_in_pts);
END_WITH_OS_WINDOW
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#2131?email_source=notifications&email_token=AACIW355O3EBJ37VC6HOFKTQT35MDA5CNFSM4JNBBJMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEGROBI#issuecomment-554505989>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACIW34C2LBLE52DTVCX4UDQT35MDANCNFSM4JNBBJMA>
.
|
|
Hmm, on second thought, I think that's a good observation. The feature I want is a terminal of a given size, @kovidgoyal wants (if I understood correctly) pixel-based resizing (because of window manager behaviors). I can imagine there being other ideas, like if I (like you pointed out) change the font size, do I want to resize the window, or change the terminal size? Are fixed terminal size vs. fixed window size the only sensible combinations, or are there others? |
|
@kovidgoyal What are your thoughts on my comment #2131 (comment)? |
|
With resize hints there is nothing kitty has to do on window resize. It's Then comes the font size change. There are two options, let the window resize itself when font size |
|
Oh and if you just want a window of fixed size use the initial_window_width/height options that allow you to specify a size on cells. And mark kitty windows non-resizable in the windowmanager. |
|
Ok, I'd say we just stick to the current behaviour when changing the font size. We can implement any special resize behaviour in a different PR, this PR doesn't need to be blocked by that, right? |
|
This PR is fine, once the behavior is made optional. |
|
@Luflosi Oh, thank you, that would be nice! I hope to get back to this this weekend, and start digging in to how the project is actually structured. (as opposed to just grepping) |
|
I came up with the name |
|
Sounds ok to me. |
|
This does not currently work on Wayland. The aspect ratio constraint is implemented by changing the window size after resizing. A similar hack would need to be implemented for this as well to make it work on Wayland. Should we instead just add a note to the option that this does not currently work on Wayland? |
|
Yeah. I was going looking at that and found that the corresponding
size-hints feature is intentionally left out of Wayland, so I left it
unimplemented. Pointing this out sounds like a good idea.
…On Sun, Nov 24, 2019 at 5:16 PM Luflosi ***@***.***> wrote:
This does not currently work on Wayland. The aspect ratio constraint is
implemented by changing the window size after resizing. A similar hack
would need to be implemented for this as well to make it work on Wayland.
Should we instead just add a note to the option that this does not
currently work on Wayland?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2131?email_source=notifications&email_token=AACIW32JIQYYHXMU4BITYZDQVKSGZA5CNFSM4JNBBJMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFAO4NI#issuecomment-557903413>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACIW3ZNAU5ZCVSUON5NB3TQVKSGZANCNFSM4JNBBJMA>
.
|
|
There is actually special code in Wayland to make the aspect ratio stuff work: Lines 553 to 561 in c140e17 |
|
But I can't be bothered trying to implement a similar hack for the resize in steps. |
|
Feel free to rebase onto the latest master if you like. |
|
Is there anything else we need to do, or is this ready? |
|
You accidentally added an extra newline in the changelog while rebasing my commit. You can try resetting by one commit and then merging again or let @kovidgoyal remove it while merging. Other than that nitpick, this should be ready to be merged. |
|
@kovidgoyal alright, please review, I don't want to wait any longer. You should consider removing the extra line in the change log. |
|
I will review and merge this when I have some time. |
|
Could you give a very rough estimate on when you will have some time to review this please? |
|
Sometime in the next couple of months. |
3 participants
This makes increments-based resize work for me (on X11).
(Let's discuss before merge, but it makes me a lot happier)