You are not logged in.
Sometimes I accidentally close an open window in DWM and want to reopen it again
Is there a way in DWM to reopen recently closed window, like how we do in browsers
Last edited by tejasn14 (2020-11-07 01:54:51)
Offline
I'm not sure what you are referring to in browsers, but the answer is no. You do not actually "close a window" you send a signal to the client program telling it to close the window which it (generally) interprets as a signal to shut down completely - then it (the client) closes it's own window.
Just restart whatever program was running.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
On the other hand, you could make a plugin/patch/wathever to the thing you use to launch stuff, so it haves history (or something that already haves history), but that’s totally unrelated to DWM since it’s a plain o’l WM.
Offline
That would make it easy to reopen the last opened program, but not the last closed program / window.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Depending on how configurable DWM is (…well… patchable ;-) you could override the close action and simply unmap the window, then wait five minutes and remap¹ and close it unless it was previously "restored".
[1] I'd be reluctant to simply close the unmapped window because the client might somehow incoporate the mapping state when creating the window on the run.
Though probably rare, I'd not easily bet on sanely implemented clients itr.
Online
Some client will behave poorly in response even to the window being unmapped (poorly here meaning for the present goals). If one were to take this general approach, simply moving them offscreen (similar to a non-existent tag) would be a better approach. This would actually assist in implementation to as dwm already has all the mechanisms for tags: just use a specific tag with no (other) key bindings associated with it as a window graveyard. Instead of binding a key to close a client, bind it to move the client to the graveyard tag. Then have a periodic process closing everything in the graveyard.
Or for more flexibility, have two "graveyards" so the user intent of closing a window moves it to the first graveyard tag, then a periodic process closes anything in the second graveyard and moves everything from the first to the second. This way every window "closed" would remain revivable for at least one cycle.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
I think we're trying to fix the "Y" problem here, not the "X": wouldn't it be better/easier(tm) if OP remapped the way a window is closed in the first place to a less error-prone one? Or implement an evil 'Are you sure?' nag every time a window is closed? I'm extrapolating, but I assume that the accidental close is a mouse action, not a keyboard shortcut, so maybe only nag if the close is due to a mouse action?
Offline
^ that would solve X, tho by the least resistance that is heavy, I haven’t seen thus far anything related to “annoying nag that prevents derps”.
I believe OP would have to implement from scratch...
...
iirc DWM removes most of the windows clutter, that including the typical X for closing windows.
It’s likely that the keyboard mapping for “kill window” is the culprit here so remapping is easier to do.
Last edited by GaKu999 (2020-11-07 18:45:55)
Offline
Some client will behave poorly in response even to the window being unmapped (poorly here meaning for the present goals). If one were to take this general approach, simply moving them offscreen (similar to a non-existent tag) would be a better approach. This would actually assist in implementation to as dwm already has all the mechanisms for tags: just use a specific tag with no (other) key bindings associated with it as a window graveyard. Instead of binding a key to close a client, bind it to move the client to the graveyard tag. Then have a periodic process closing everything in the graveyard.
Or for more flexibility, have two "graveyards" so the user intent of closing a window moves it to the first graveyard tag, then a periodic process closes anything in the second graveyard and moves everything from the first to the second. This way every window "closed" would remain revivable for at least one cycle.
Thank you, an excellent suggestion.
What I had in mind was. If there is a way I can get which application was closed and which file was open in it (Eg. zathura open with a.pdf; or mplayer open with movie.mp4)
I can push this into a stack and on the "revive" action reopen the same application with the same file, so that when I close an application it frees up memory and there won't be any time limit limiting the "revive" action.
Going even further, I could close all open applications, reboot my computer and after reboot call "revive" a number of times to get my computer back to the state in which it was prior to rebooting my computer
Last edited by tejasn14 (2020-11-08 10:43:09)
Offline
That's session management and vastly different from your original post.
It also cannot be achieved by the WM (alone) because relevant information might be (is) private to the client. Typically the clients store their session w/ the relevant data and the next session opens them with that data.
Eg. KDE provides an infrastructure that several clients implement.
What is possible from the outside is to fetch the PID attached to a window (if the client adds that property) and inspect it's commandline in /proc, then store that and re-run it.
This will obviously not work if you eg. opened a file with the file/open dialog, because this condition will be entirely private to the client.
Online