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.

Sign up for GitHub

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

Jump to bottom

1.5-rc1: self-resizing floating window positioning problems #5490

Closed
luispabon opened this issue Jun 28, 2020 · 0 comments · Fixed by #5491
Closed

1.5-rc1: self-resizing floating window positioning problems #5490

luispabon opened this issue Jun 28, 2020 · 0 comments · Fixed by #5491

Comments

@luispabon
Copy link

  • Sway Version:
    Sway 1.5-rc1
    wlroots a7f48aab6968ad67ff7eef2828bd6f6e45c18ab5
  • Debug Log:
    The log covers triggering Ulauncher, one search until the window repositions weirdly, then closing it without launching an app

https://pastebin.com/wgDfMzck

  • Configuration File:

https://github.com/luispabon/sway-dotfiles/tree/master/configs/sway

The issue

I use Ulauncher as my app launcher. I have a window rule to make it float, and Sway naturally places it dead on the middle of the active workspace when I invoke it.

Ulauncher's window changes its size as it hits results on whatever you're searching. Up until Sway 1.4, ulauncher's top border would remain positioned at its initial position regardless of how the window would resize.

Upon upgrading to Sway 1.5-rc1 the positioning has gone a bit wonky. When you're searching, sometimes Sway will reposition the window lower. I can't find a pattern by which it happens. It's best seen on a vid:

https://www.youtube.com/watch?v=94RqjF9v7bE&feature=youtu.be
@luispabon luispabon changed the title 1.5-rc1: floating window positioning problems 1.5-rc1: self-resizing floating window positioning problems Jun 28, 2020
kennylevinsen added a commit to kennylevinsen/sway that referenced this issue Jun 28, 2020
@kennylevinsen
transaction: Mark client resize immediately ready
91d4f1f 
If a client commits a new size on its own, we create a transaction for
the resize like any other. However, this involves sending a configure
and waiting for the ack, and wlroots will not send configure events when
there has been no change. This leads to transactions timing out.

Instead, just mark the view ready immediately by size when the client
is already ready, so that we avoid waiting for an ack that will never
come.

Closes: swaywm#5490
@kennylevinsen kennylevinsen mentioned this issue Jun 28, 2020
Merged
emersion pushed a commit that referenced this issue Jun 30, 2020
@kennylevinsen @emersion
transaction: Mark client resize immediately ready
d0f7e0f 
If a client commits a new size on its own, we create a transaction for
the resize like any other. However, this involves sending a configure
and waiting for the ack, and wlroots will not send configure events when
there has been no change. This leads to transactions timing out.

Instead, just mark the view ready immediately by size when the client
is already ready, so that we avoid waiting for an ack that will never
come.

Closes: #5490
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

transaction: Mark client resize immediately ready kennylevinsen/sway
1 participant
@luispabon