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

Move visible drop to other workspace #21

Closed
quite opened this issue Jul 5, 2016 · 3 comments
Closed

Move visible drop to other workspace #21

quite opened this issue Jul 5, 2016 · 3 comments

Comments

@quite
Copy link

quite commented Jul 5, 2016

I'm on mate/marco. When a tdrop:ed window is mapped on another workspace and I call tdrop while on another workspace, I would ideally have the window remapped to this current workspace. This does not happen. Neither does calling tdrop two times achieve this behaviour. Is this intended? The comment in the readme regarding awesome wm makes me think that this functionality should perhaps already be present...

noctuid added a commit that referenced this issue Jul 8, 2016
For most WMs (awesome is an exception), windows that are open on another
desktop are reported as unmapped which causes nothing to happen if a
tdrop command is run (unmapping/mapping don't work in this case). Moving
a dropdown to the current desktop is possible with xdotool though
(basically the same as wmctrl's -R). This is a temporary solution that
may be need to be refined in the future. A potential issue is whether
pre/post map hooks should be run in this case (e.g. rules should not be
added again for bspwm). This could be fixed later by actually unmapping
the window or by adding more specific hooks. Addresses #21.
@noctuid
Copy link
Owner

noctuid commented Jul 8, 2016

This isn't necessarily intentional. The reason that tdrop behaves differently for awesome is that most other WMs (every other one I've tried it with) report windows on other desktops/workspaces as unmapped. Furthermore, you can't unmap a window that is open on another desktop with xdotool.

I agree that the behavior you describe would be nicer, but I'm not sure the best way of achieving it. #18 could make this unecessary. Alternatively, xdotool has a command that allows moving a window to another desktop. I've implemented it this way, but there are a couple potential problems. I'm not sure if the command works consistently across WMs (but I think that it does), so please test it, and I'll try it on some other WMs when I get a chance.

@ibrokemypie
Copy link

+1

Sent from my iPhone

On 9 Jul 2016, at 4:36 AM, Fox Kiester notifications@github.com wrote:

This isn't necessarily intentional. The reason that tdrop behaves differently for awesome is that most other WMs (every other one I've tried it with) report windows on other desktops/workspaces as unmapped. Furthermore, you can't unmap a window that is open on another desktop with xdotool.

I agree that the behavior you describe would be nicer, but I'm not sure the best way of achieving it. #18 could make this unecessary. Alternatively, xdotool has a command that allows moving a window to another desktop. I've implemented it this way, but there are a couple potential problems. I'm not sure if the command works consistently across WMs (but I think that it does), so please test it, and I'll try it on some other WMs when I get a chance.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

@quite
Copy link
Author

quite commented Jul 11, 2016

Your addition worked fine here on mate/marco. Thanks a bunch, this is really great for the workflow.

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

No branches or pull requests

3 participants