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

Fix arrange windows #360

Merged
merged 2 commits into from
Dec 18, 2015
Merged

Fix arrange windows #360

merged 2 commits into from
Dec 18, 2015

Conversation

sce
Copy link
Contributor

@sce sce commented Dec 18, 2015

First patch fixes some of the debugging output and adds some debug output line for panels.

Second patch makes sure width and height are properly set which is actually used later on (after the switch statement). (And also fixes x/y for workspace for left/right panels.)

This should properly restore the behaviour of arrange_windows to what it used to be.

Ref #358 , @mikkeloscar please test/confirm...

@ddevault
Copy link
Contributor

LGTM, but holding off on merge pending @mikkeloscar's feedback.

@sce
Copy link
Contributor Author

sce commented Dec 18, 2015

I'm going to mention it here: I say that the second patch partially fixes swaybar irregularities because it restores the behaviour that my previous code changed. So far so good, however, what is actually happening is that the surface for swaybar has no size before it becomes visible for the first time (this is confirmed by the new debug output), and therefore the workspace will not "move out of the way". Once it becomes visible the surface correctly reports its size and the workspace adjusts accordingly.

So my theory is that it's only working correctly because gaps are being used. So if e.g. outer_gaps are in play then the swaybar will be immediately visible, swaybar will create a surface, and the workspace will move out of the way. (This has been the behaviour all along.)

@ddevault
Copy link
Contributor

I'm not sure I follow. Is there something wrong with that behaviour?

@sce
Copy link
Contributor Author

sce commented Dec 18, 2015

The surface from the swaybar is still covered by the window on the workspace, so no surface will be created, and nothing is shown, unless something triggers it to create it, like e.g. a part of the surface becomes visible (which happens automatically if gaps are in play). That's my theory at least. I didn't mention this at once because I believe this has been the behaviour all along.

@ddevault
Copy link
Contributor

I think I understand better now, thanks for pointing it out.

@mikkeloscar
Copy link
Collaborator

Except what you have explained above it LGTM. The behavior is as "expected" now.

ddevault added a commit that referenced this pull request Dec 18, 2015
@ddevault ddevault merged commit 2ab4e56 into swaywm:master Dec 18, 2015
@sce sce deleted the fix_arrange_windows branch December 18, 2015 23:40
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.

3 participants