-
Notifications
You must be signed in to change notification settings - Fork 43
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
Comments
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.
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. |
+1 Sent from my iPhone
|
Your addition worked fine here on mate/marco. Thanks a bunch, this is really great for the workflow. |
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...
The text was updated successfully, but these errors were encountered: