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

Moving containers to a certain position sometimes difficult #1326

Open
i3bot opened this Issue Jul 20, 2014 · 12 comments

Comments

Projects
None yet
5 participants
@i3bot

i3bot commented Jul 20, 2014

[Originally reported by klausgy@…]
(Hi, I noticed that specific arrangments of windows are diffucult / counterintuitive to obtain using the i3 navigation. For example, I have this situation (I leave the leafs of the split containers out of the picture):

["Main" (tabbed)]
| | |["Split1" (vertically-split)]
| |
["Split2" (vertically-split)]
|_["Firefox" (leaf)]

And I want to get this:

["Main" (tabbed)]
| | |["Split1" (vertically-split)]
| |
["Firefox" (leaf)]
|_["Split2" (vertically-split)]

When moving Firefox to the right, it circles through the two split containers and ends up in the tabbed container on the right border. When moving it upwards while it circles through Splitx, i3 creates a horizontally-split out of main and places Firefox there. The only way I found to achieve the desired position is to select Split1 (via select-parent) and move it to the left. I think there should be an easier way provided for this (ideally, I imagine when moving Firefox to the right and after circling through Split1 it gets placed between Split1 and Split2 in Main, just as desired).

@i3bot

This comment has been minimized.

Show comment
Hide comment
@i3bot

i3bot Jul 20, 2014

[Original comment by klausgy@…]

Sorry, I didn't deal with the formatting rules in my ACSII art and it removed some information, so here again the two diagrams:

[Main (tabbed)]
| | |[Split1 (vertically-split)]
| |
[Split2 (vertically-split)]
|_[Firefox (leaf)]

[Main (tabbed)]
| | |[Split1 (vertically-split)]
| |
[Firefox (leaf)]
|_[Split2 (vertically-split)]

i3bot commented Jul 20, 2014

[Original comment by klausgy@…]

Sorry, I didn't deal with the formatting rules in my ACSII art and it removed some information, so here again the two diagrams:

[Main (tabbed)]
| | |[Split1 (vertically-split)]
| |
[Split2 (vertically-split)]
|_[Firefox (leaf)]

[Main (tabbed)]
| | |[Split1 (vertically-split)]
| |
[Firefox (leaf)]
|_[Split2 (vertically-split)]

@stapelberg

This comment has been minimized.

Show comment
Hide comment
@stapelberg

stapelberg Jul 20, 2014

Member

There is one more way:

While your focus is on split1, use “focus parent”, then create a new terminal. You’ll now be able to move firefox to the right (in direction of the terminal) and it’ll be where you want it to be (AIUI). You can then close the terminal. This can be automated.

In general, I’m not quite sure how you’d expect us to fix what you’re describing. Changing the behavior of how i3 handles window moves will inevitably upset some part of our users and we want to strongly avoid any backwards-incompatible changes. Adding another option for this sort of behavior however is not a good idea either since it has implications on other parts of the user experiences (e.g. “when using modeX + modeY, feature Z is not easy to use, so you need to add special case #n+1”) and makes reasoning about the code so much more complex.

I’d suggest you find a solution for your problem that works by combining existing commands and/or using an IPC script, see http://i3wm.org/docs/ipc.html

Member

stapelberg commented Jul 20, 2014

There is one more way:

While your focus is on split1, use “focus parent”, then create a new terminal. You’ll now be able to move firefox to the right (in direction of the terminal) and it’ll be where you want it to be (AIUI). You can then close the terminal. This can be automated.

In general, I’m not quite sure how you’d expect us to fix what you’re describing. Changing the behavior of how i3 handles window moves will inevitably upset some part of our users and we want to strongly avoid any backwards-incompatible changes. Adding another option for this sort of behavior however is not a good idea either since it has implications on other parts of the user experiences (e.g. “when using modeX + modeY, feature Z is not easy to use, so you need to add special case #n+1”) and makes reasoning about the code so much more complex.

I’d suggest you find a solution for your problem that works by combining existing commands and/or using an IPC script, see http://i3wm.org/docs/ipc.html

@i3bot

This comment has been minimized.

Show comment
Hide comment
@i3bot

i3bot Jul 20, 2014

[Original comment by klausgy@…]

I see your arguments. Just to answer on how I'd fix it, I'd say after moving a window out of one container, it does not immedeatly get placed in the next container but if possible between those two, Then the next motion command will place it in the second container.

This would indeed break backwards compatibility but not necessarily user habit, as you would in the worst case have to put one command twice instead of once to achieve the same result (like, when moving a window most of the time I don't count the moves but stop when the desired position is achieved, I wouldn't probably notice if one extra position sneaked into the sequence).

One possible further argument for my side: It'd be a cool (but maybe unrealizable, even with my suggestion) axiom that 'move to the right' after 'move to the left' equals 'do nothing', in the case I specified above, if Firefox already sits between those containers and I move it to the right, it gets placed in the right container but 'move to the left' does not restore the initial position.

Anyway, thanks for the answer and clarification and for creating a wonderful product!

i3bot commented Jul 20, 2014

[Original comment by klausgy@…]

I see your arguments. Just to answer on how I'd fix it, I'd say after moving a window out of one container, it does not immedeatly get placed in the next container but if possible between those two, Then the next motion command will place it in the second container.

This would indeed break backwards compatibility but not necessarily user habit, as you would in the worst case have to put one command twice instead of once to achieve the same result (like, when moving a window most of the time I don't count the moves but stop when the desired position is achieved, I wouldn't probably notice if one extra position sneaked into the sequence).

One possible further argument for my side: It'd be a cool (but maybe unrealizable, even with my suggestion) axiom that 'move to the right' after 'move to the left' equals 'do nothing', in the case I specified above, if Firefox already sits between those containers and I move it to the right, it gets placed in the right container but 'move to the left' does not restore the initial position.

Anyway, thanks for the answer and clarification and for creating a wonderful product!

@stapelberg

This comment has been minimized.

Show comment
Hide comment
@stapelberg

stapelberg Jul 22, 2014

Member

I think I agree, provided this can be realized without an overly complicated patch.

Member

stapelberg commented Jul 22, 2014

I think I agree, provided this can be realized without an overly complicated patch.

@i3bot

This comment has been minimized.

Show comment
Hide comment
@i3bot

i3bot Sep 19, 2014

[Original comment by icandothings@…]

Sorry for the poor description above, hit submit too quickly.

But that patch changes the container movement to work the way the ticket describes. Currently using it on my system without issues. Its a very simple patch, I basically just deleted an if.

i3bot commented Sep 19, 2014

[Original comment by icandothings@…]

Sorry for the poor description above, hit submit too quickly.

But that patch changes the container movement to work the way the ticket describes. Currently using it on my system without issues. Its a very simple patch, I basically just deleted an if.

@stapelberg

This comment has been minimized.

Show comment
Hide comment
@stapelberg

stapelberg Sep 29, 2014

Member

Can you submit this to http://cr.i3wm.org/ please?

Member

stapelberg commented Sep 29, 2014

Can you submit this to http://cr.i3wm.org/ please?

@ticalc-travis

This comment has been minimized.

Show comment
Hide comment
@ticalc-travis

ticalc-travis Dec 3, 2017

This remains a enormously frustrating problem. After the ways in which i3 helped my productivity, this particular flaw almost took it all back. All it takes is an accidental move of the wrong window in the case described in this issue, and then i3 goes out of its way to make it nearly impossible to put it back in its original location? I can't describe how frustrating (to say the least) it is to lose literally hours of time I could be working, fighting with i3 instead when this happens to me. The workarounds suggested here feel like overly convoluted circus acts, ones that are not the least bit obvious, and ones I can't manage to remember in an emergency situation when I need to get the window back right now—plus this ticket isn't exactly easy to find in a Google search, either.

Honestly, I'm amazed this wasn't the default behavior in the first place. It makes perfect sense for moving a window/container to always stop between elements when possible. I honestly thought i3 already did that. So hopefully you can understand my frustration here. I hope too much of it hasn't leaked through and made this comment sound too harsh.

ticalc-travis commented Dec 3, 2017

This remains a enormously frustrating problem. After the ways in which i3 helped my productivity, this particular flaw almost took it all back. All it takes is an accidental move of the wrong window in the case described in this issue, and then i3 goes out of its way to make it nearly impossible to put it back in its original location? I can't describe how frustrating (to say the least) it is to lose literally hours of time I could be working, fighting with i3 instead when this happens to me. The workarounds suggested here feel like overly convoluted circus acts, ones that are not the least bit obvious, and ones I can't manage to remember in an emergency situation when I need to get the window back right now—plus this ticket isn't exactly easy to find in a Google search, either.

Honestly, I'm amazed this wasn't the default behavior in the first place. It makes perfect sense for moving a window/container to always stop between elements when possible. I honestly thought i3 already did that. So hopefully you can understand my frustration here. I hope too much of it hasn't leaked through and made this comment sound too harsh.

@Airblader

This comment has been minimized.

Show comment
Hide comment
@Airblader

Airblader Dec 3, 2017

Member

I can't quite believe that it causes you to lose

literally hours of time

but if it does, another solution to quickly fix your layout would be to use move window to mark after marking the corresponding container. We're also open for PRs changing i3's behavior if we can agree on the change it provides. This ticket has seen no activity in something like three years, so it doesn't seem to be something that bothers a lot of users that greatly – a good indication for there not being a reason to drastically change i3's behavior in a compatibility-breaking way.

Member

Airblader commented Dec 3, 2017

I can't quite believe that it causes you to lose

literally hours of time

but if it does, another solution to quickly fix your layout would be to use move window to mark after marking the corresponding container. We're also open for PRs changing i3's behavior if we can agree on the change it provides. This ticket has seen no activity in something like three years, so it doesn't seem to be something that bothers a lot of users that greatly – a good indication for there not being a reason to drastically change i3's behavior in a compatibility-breaking way.

@ticalc-travis

This comment has been minimized.

Show comment
Hide comment
@ticalc-travis

ticalc-travis Dec 4, 2017

Well, the cumulative time getting distracted, trying to get what I wanted, researching it, trying to find a solution for the future, plus my stubborn tendency to want to do things the way I intended instead of something different has added up to at least a couple to a few hours… But nonetheless, things were going really roughly for me yesterday, and I admit to posting that comment too hastily.

I can imagine it not being a common issue: I actually used i3 for quite a long time before ever running into it. But when I finally did, it was a bit too much.

Before, I had tried moving the window to the scratchpad and then retrieving and unfloating it after focusing the parent container, but this did not work for me at all; the behavior of putting the window back was not the same as that of creating a new window. (I have a key binding that does “scratchpad show; floating toggle”, which I sometimes use to “cut and paste” a window to a different location without having to move it through every intermediate position.)

I have been able to get “move window to mark” to work for this situation (after some trial and error); thanks for that tip.

The thing that confused me about this ticket is that there appeared to be an agreement on a patch earlier, but nothing appeared to have happened.

If changing the behavior of the standard move commands is that much of a problem, it seems (if I'm not misunderstanding how this works) that having some sort of direct means to “move container to parent” would be a helpful alternative in situations like this. Then I would just be able to move the window upward in the tree hierarchy until it is back at the top level of the tab container in the desired position.

Thanks for the response!

ticalc-travis commented Dec 4, 2017

Well, the cumulative time getting distracted, trying to get what I wanted, researching it, trying to find a solution for the future, plus my stubborn tendency to want to do things the way I intended instead of something different has added up to at least a couple to a few hours… But nonetheless, things were going really roughly for me yesterday, and I admit to posting that comment too hastily.

I can imagine it not being a common issue: I actually used i3 for quite a long time before ever running into it. But when I finally did, it was a bit too much.

Before, I had tried moving the window to the scratchpad and then retrieving and unfloating it after focusing the parent container, but this did not work for me at all; the behavior of putting the window back was not the same as that of creating a new window. (I have a key binding that does “scratchpad show; floating toggle”, which I sometimes use to “cut and paste” a window to a different location without having to move it through every intermediate position.)

I have been able to get “move window to mark” to work for this situation (after some trial and error); thanks for that tip.

The thing that confused me about this ticket is that there appeared to be an agreement on a patch earlier, but nothing appeared to have happened.

If changing the behavior of the standard move commands is that much of a problem, it seems (if I'm not misunderstanding how this works) that having some sort of direct means to “move container to parent” would be a helpful alternative in situations like this. Then I would just be able to move the window upward in the tree hierarchy until it is back at the top level of the tab container in the desired position.

Thanks for the response!

@Airblader

This comment has been minimized.

Show comment
Hide comment
@Airblader

Airblader Dec 4, 2017

Member

The thing that confused me about this ticket is that there appeared to be an agreement on a patch earlier, but nothing appeared to have happened.

The discussed patch has never been submitted as a PR. :-) If someone can come up with the PR, go for it.

having some sort of direct means to “move container to parent” would be a helpful alternative

Are you looking for

mark _a, focus parent, focus parent, mark _b, [con_mark=_a] move window to mark _b

?

Member

Airblader commented Dec 4, 2017

The thing that confused me about this ticket is that there appeared to be an agreement on a patch earlier, but nothing appeared to have happened.

The discussed patch has never been submitted as a PR. :-) If someone can come up with the PR, go for it.

having some sort of direct means to “move container to parent” would be a helpful alternative

Are you looking for

mark _a, focus parent, focus parent, mark _b, [con_mark=_a] move window to mark _b

?

@ticalc-travis

This comment has been minimized.

Show comment
Hide comment
@ticalc-travis

ticalc-travis Dec 7, 2017

Yes, thanks! I had tried Googling for a way to do that before but never got anywhere. That definitely makes it a lot simpler to get what I want. That's kind of an embarrassingly obvious solution in retrospect, especially upon realizing that containers can be marked in addition to just windows (and that marks can be moved to, which I think was a concept I didn't fully understand originally). :-)

ticalc-travis commented Dec 7, 2017

Yes, thanks! I had tried Googling for a way to do that before but never got anywhere. That definitely makes it a lot simpler to get what I want. That's kind of an embarrassingly obvious solution in retrospect, especially upon realizing that containers can be marked in addition to just windows (and that marks can be moved to, which I think was a concept I didn't fully understand originally). :-)

@Airblader

This comment has been minimized.

Show comment
Hide comment
@Airblader

Airblader Dec 8, 2017

Member

No worries, just happy it works. :-)

Member

Airblader commented Dec 8, 2017

No worries, just happy it works. :-)

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