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

client order not preserved by view arrangements #1

Closed
sunaku opened this issue Nov 14, 2009 · 2 comments
Closed

client order not preserved by view arrangements #1

sunaku opened this issue Nov 14, 2009 · 2 comments
Labels

Comments

@sunaku
Copy link
Owner

sunaku commented Nov 14, 2009

On Thu, Nov 5, 2009 at 9:47 AM, Nathan Neff wrote:

I would like a way place the windows back to their original positions.

Actually, I intended for these arranging methods to preserve the
relative (top-down) order of clients in a column. So ideally, you can
switch between arrangements and still have the same relative client
ordering.

I played around with arranging 10 terminals on an empty view:

  • Going from tiling mode to grid mode, the top two clients in the
    second column are swapped. Repeating this again, the same
    transformation is applied and the order fixes itself.
  • Going from tiling mode to diamond mode, the top two clients and the
    bottom client in the middle column are swapped. After repeating this
    four times, the same transformation is applied and the order fixes
    itself.

I'll try to fix this bug in Rumai itself. Thanks.

@sunaku
Copy link
Owner Author

sunaku commented Nov 14, 2009

I looked at the unshift(), push(), and insert() methods in Area and they seem fine. The culprit might be the creation of a new column (moving a client from the right-most column to the right).

@sunaku
Copy link
Owner Author

sunaku commented Mar 23, 2010

Fixed in version 3.1.1 (2009-11-16).

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

No branches or pull requests

1 participant