You are not logged in.
Manages 'drawer terminal' type windows, like a generalized version of guake or so. Intended for use with a hotkey utility like sxhkd.
Update: drawer has two major differences from other scripts of this type I've seen:
1. It takes the command to launch and positioning as arguments, making it easier to have multiple Quake-term utilites (I have a userspace term, a root term, and conky).
2. It identifies windows by X window id instead of window class, making it able to handle tools that don't let you pass the X window class on launch, making it possible to drawer-ify a browser window from your single-instance browser, etc, and making it robust in the face of tools that change their class/title after launch.
Usage:
drawer NAME [SIDE WIDTH HEIGHT COMMAND]NAME is a symbolic name for the drawer. It should be a valid POSIX filename.
SIDE is the side of the screen to attach the drawer to. Valid values are left, right, top, and bottom.
WIDTH and HEIGHT may be either a size in pixels or a percentage of screen size (`84%`) specifying the dimensions of the window to create.
COMMAND is the command with arguments which will actually create the window.
When run, drawer looks in /tmp/drawers.wids/ for a file called NAME containing an X window id. If found, that window's 'hidden' EWMH hint will be toggled. If the file is not found, COMMAND is executed and the resulting window is positioned according SIDE, WIDTH, and HEIGHT and then focused, and the windows X window id is written to /tmp/drawers.wids/$NAME to allow future toggling.
Drawer requires wmcrtl, my fork of xtoolwait (although I have a pull request pending to merge the changes), my version of cut(1), and, optionally, xdotool (to prod certain window managers into making the created window floating).
The script: https://github.com/lharding/lsh-bin/blob/master/drawer
I built this after getting frustrated with the way the AwesomeWM 'scratchpad' module forgets its windows after a WM restart, and tries to manage every new window if the command it tries to launch fails. This tool should survive WM restarts and isn't WM dependent (beyond needing a decent EWMH implementation).
Last edited by lharding (2014-11-13 20:06:04)
Offline
I like the idea of using window id instead of window class. I can't get the script working though. Firstly, I am confused about what scut is. Surely it's not scut in the aur " An app to cut your screen - make a screenshot and move it around easily"?
Also, testing xtoolwait, it doesn't seem to exit. For example:
xtoolwait -wid apvlvApvlv (or whatever application) will start successfully, but xtoolwait doesn't exit and says "warning: timeout launching apvlv".
Also, is `super+ctrl+space` a common binding to float a window among window managers or just for awesome? It doesn't seem like a very good idea to fake a keypress to float the window.
For reference, this is basically what I'm using for dropdown terms with bspwm. It's a better idea to be using wmctrl for sizing I think.
Last edited by angelic_sedition (2014-11-13 02:46:48)
Offline
Gah! I totally forgot that I was depending on my own custom cut command for this. It's here, basically a less crappy version of cut(1). Thanks for catching that.
That's weird with xtoolwait. Does apvlv take long to launch when run on its own? Maybe the default timeout is too short? I'll try and debug this later tonight, but I suspect xtoolwait is being too conservative about detecting window creations.
The key combo isn't any kind of standard, it's just a hack to kick Awesome in the head because it doesn't listen to the ewmh floating hint. I'm planning to switch to a different WM soon, so I was a bit half-assed on this part.
Offline
Gah! I totally forgot that I was depending on my own custom cut command for this. It's here, basically a less crappy version of cut(1). Thanks for catching that.
That's weird with xtoolwait. Does apvlv take long to launch when run on its own? Maybe the default timeout is too short? I'll try and debug this later tonight, but I suspect xtoolwait is being too conservative about detecting window creations.
The key combo isn't any kind of standard, it's just a hack to kick Awesome in the head because it doesn't listen to the ewmh floating hint. I'm planning to switch to a different WM soon, so I was a bit half-assed on this part.
Thank you for that link. apvlv launches pretty much immediately either way. The default timeout is 15 seconds, so that's not the problem (I have to wait for the timeout message). xtoolwait gives the timeout message for anything for me (xterm, urxvt, etc.). Could this be because of my window manager?
Offline
Thank you for that link. apvlv launches pretty much immediately either way. The default timeout is 15 seconds, so that's not the problem (I have to wait for the timeout message). xtoolwait gives the timeout message for anything for me (xterm, urxvt, etc.). Could this be because of my window manager?
I finally got a spare moment to dig into this and I think what's happening here is that xtoolwait is being too conservative about when it thinks a window has been created - it waits for a PropertyNotify event, assuming that the WM going to send a "normal state" event when the window is mapped and position and all. I'm guessing your WM isn't doing that so xtoolwait thinks apvlv never creates a window.
I've pushed a fix to my git xtoolwait Github that makes it print the window id (if given -wid) as soon the CreateNotify event comes in, and supports a new option '-noprop' that causes it to consider windows created once their CreateNotify has come in rather than waiting for a PropertyNotify. Can you give this a try? The invocation would be something like:
xtoolwait -wid -noprop xtermThanks! If it works, I'll update the drawer script and clean up my xtoolwait git repo.
Offline
That fixes the problem with xtoolwait. Thank you. I don't think bspwm supports hidden either though sadly ("wmctrl -r <window> -b toggle,hidden" doesn't work).
Last edited by angelic_sedition (2014-11-27 06:13:10)
Offline
I'm glad that worked. I'll fixup the git repo and such now.
Interesting about bspwm - it seems like quite a few tilling WM's don't implement EWMH really. It seems to me I've seen a tool than can directly map and unmap another client's windows. xdotool maybe? If so, it ought to be simple to modify the script to use xdotool instead of wmctrl for show/hide.
Offline
I'm glad that worked. I'll fixup the git repo and such now.
Interesting about bspwm - it seems like quite a few tilling WM's don't implement EWMH really. It seems to me I've seen a tool than can directly map and unmap another client's windows. xdotool maybe? If so, it ought to be simple to modify the script to use xdotool instead of wmctrl for show/hide.
Xdotool is what I've been using. It can't select a window by id though (only class, classname, pid, etc.).
Offline
Ah, right. It's obnoxious how xdotool and wmctrl don't *quite* have the same functionality around windows, but almost do. Maybe that will be my next hack...
Offline
Ah, right. It's obnoxious how xdotool and wmctrl don't *quite* have the same functionality around windows, but almost do. Maybe that will be my next hack...
Actually, I was wrong. You can't search for window id, because that what --search gives you back (*facepalm*). You actually have to use the window id with windowmap, so it's pretty easy to duplicate this functionality using xdotool. My bad. That's what I'm doing now. It also has resizing to a specific size (which I didn't realize before), so I'm going to start using that instead of what I was doing before (which was increasing size by an amount, which is program dependent). Xdotool is also nice in that it allows you to specify percent of screen size when sizing.
Thanks for the ideas. I hope your changes get merged into xtoolwait.
Edit: xdotool doesn't give the window id in the same format. For example, with xtoolwait, I get the following when using with apvlv:
0x06600001
0x06600003The same windows are represented for xdotool (and by $WINDOWID) by the following:
106954755
106954753It doesn't really matter as both work with xdotool commands. I've also found that you can get the window id using "xdo id" as well.
Last edited by angelic_sedition (2014-12-16 04:15:35)
Offline