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

Implement dragging and resizing of borderless window #7952

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

hborchardt
Copy link

Hi, I like using alacritty without decorations (on windows, that's the only alternative to full title bar), but I found it difficult to move and resize the window.

I saw that winit provides the drag_window and drag_resize_window functions for the use case of defining custom click target areas to move and resize a window.

So I implemented moving the window when dragging the top padding, and resizing it when dragging the bottom-right corner padding, as well as corresponding CursorIcon changes.

I hope you like it, I am happy about any criticism.

@hborchardt hborchardt force-pushed the drag_resize_borderless_window branch from 0967b05 to efc9899 Compare May 6, 2024 10:27
@hborchardt hborchardt force-pushed the drag_resize_borderless_window branch from efc9899 to 889cf7f Compare May 6, 2024 10:37
@nixpulvis
Copy link
Contributor

nixpulvis commented May 6, 2024

Upon first look at this PR a lot of things come to mind:

  1. The current state of window options on macOS are somewhat overly complicated, i.e. does anyone actually use "Transparent"?
  2. This begs for the ability to change window.padding.top without changing window.padding.bottom, which I know we've had requests for before, but have been rejected for some reason
  3. It's unclear to me if dragging in the left/right/bottom padding area should also allow moving the window, since we're going outside the standard UX a bit anyway. I might be inclined to say yes.
  4. It remains impossible to select text in the top row of a window with decoration = "Buttonless" unless the padding is large enough. It would be nice to change the cursor in these cases as well.

All that said, I don't expect all these points to necessarily be addressed in a single PR, I just view them as related.

As for this PR, I did notice some bugs with the cursor setting. The easiest to replicate is if you start a selection and drag into the top padding area. The cursor will flicker between a move cursor and the default, and depending on the state it's in when you release, it may be broken thereafter. I also don't know why the SE corner is special, I would expect to be able to resize from any corner, no?

@chrisduerr
Copy link
Member

does anyone actually use "Transparent"?

Yes

but have been rejected for some reason

No valid usecases.

It remains impossible to select text in the top row of a window with decoration = "Buttonless"

This is a separate issue.

@nixpulvis
Copy link
Contributor

does anyone actually use "Transparent"?

Yes

Really? Because without window.padding.top as an option, this is basically guaranteed to draw the traffic lights on top of text. Who would want that?

@hborchardt
Copy link
Author

  1. window options on macOS are somewhat overly complicated

I can't comment on macOS as I don't use it. I just try to make the decoration-less mode more usable.

  1. change window.padding.top

Personally I have no issue with the small padding I have to hit to move the window, and I like that it is slim and symmetric and configurable as it is.

  1. dragging in the left/right/bottom padding area should also allow moving the window

Moving the window using the other paddings is not quite intuitive to me, and is not necessary. I imagine it as a collapsed title bar, not the border gaining dragging powers.

  1. decoration = "Buttonless"

Can't comment on macOS.

... start a selection and drag into the top padding area. The cursor will flicker.

Will try to fix that, thanks.

I also don't know why the SE corner is special

I went for the minimalistic approach here (or call me lazy 😄), with my implementation you can already position and resize the window arbitrarily. There's also a precedent of things that are only resizable using the bottom-right corner, like this textarea field in the browser for example. But if people would require to resize from all corners, that can surely be done.

@nixpulvis
Copy link
Contributor

I would strongly push for resizing from both bottom corners at least.

@hborchardt hborchardt force-pushed the drag_resize_borderless_window branch 4 times, most recently from 7499be2 to 98cb89a Compare May 6, 2024 19:39
@hborchardt hborchardt force-pushed the drag_resize_borderless_window branch from 98cb89a to 4affc9f Compare May 6, 2024 19:46
@hborchardt
Copy link
Author

I addressed the flicker issue, enabled resizing on the south-east corner as well, and in general refactored my changes to put things in better places and make it easier to read and extend, I hope. Feel free to have a second try.

@nixpulvis
Copy link
Contributor

Sadly my Windows machine is currently broken and testing this on macOS seems to yield different results (all corners and edges allow resizing, as expected). I'll leave it to someone else to confirm this PR unless I get the time to put windows on an old laptop I've got lying around again.

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

Successfully merging this pull request may close these issues.

None yet

3 participants