Window Close Hook in Xmonad - xmonad

There's the manageHook which is called every time a new window is recognized by Xmonad.
Is there something similar for a window closing hook?

No, one does not exist.
However, you can use handleEventHook listening for DestroyWindowEvent events. (Note, by default, two DestroyWindowEvent hooks are produced, one will have ev_window == ev_event, the other will have ev_event = the parent.)

Related

Bind a single key in xmonad without using a ModMask

I would like to bind single key presses to certain actions in my xmonad.hs.
I'm setting up a security system and will have each workspace on xmonad running a camera view. I want to bind single keys, such as left or right, to the switching of the workspaces instead of requiring to also press a modmask along with the key.
Is this possible?
Found my answer,
Put a zero in place of the modkey:
Instead of this:
((modm ,xK_a), prevWS)
This:
((0 ,xK_a), prevWS)

Xmonad extension to cycle recent windows

I find it a bit awkward in xmonad to switch back and forth between two windows. Is there an extension (or a part of core xmonad) which allows this?
For example, I want to switch between firefox and emacs often, and they might not be in the same workspace. I currently do this using gotoMenu by typing M-g firefox<cr> and M-g emacs<cr> but this is awkward, especially if there's more than one instance of either app. Ideally I'd like a single shortcut to perform an action like give-focus-to-most-recently-used-unfocussed-window, which I could just press over and over to switch back and forth.
XMonad.Actions.GroupNavigation seems to be a perfect fit. To let the module track your window history, make sure that logHook invokes historyHook. For example:
import XMonad.Actions.GroupNavigation
...
main = xmonad $ defaultConfig {
...
, logHook = myLogHook xmobars >> historyHook
}
Then create a key binding for the following expression, which will toggle between the current and most recent window.
("M-x", nextMatch History (return True))

XMonad: SpawnOn workspace that had focus when spawn key was pressed

I would like to have my programs spawn on the screen that was in focus when its keybinding was pressed not on the screen thats currently in focus when it finishes loading.
Why:
My current setup is Arch Linux + XMonad and I have it running on 6 monitors. I have been using XMonad for about a year now and my only issue with it is for programs that take a little while to open. For example the very first time I start chromium it takes 3 odd seconds to load. I press my key binding for chrome and then go to a different screen to do something else. But when chrome loads it loads on the screen im currently focused on not on the screen that was focused at the time the spawn key binding was pressed.
My haskell skills are well... non existent. I have programmed in Lisp before and spend a lot of time in C, python and JavaScript so im sure I can pick it up if need be (so please be clear when it comes to haskell samples in answers).
Thanks in advance.
I found the answer to my own question.
First you must add to your imports:
import XMonad.Actions.SpawnOn
Then under your main function have something like:
main = do
xmonad $ defaultConfig
{
manageHook = myManageHooks <+> manageSpawn <+> manageDocks <+> manageHook defaultConfig
, startupHook = myStartupHook
, ETC.....
The key here was the addition of the manageSpawn in the manageHook line.
Then replace your spawns with spawnHere:
, ((modMask, xK_w), spawn "chromium")
Becomes:
, ((modMask, xK_w), spawnHere "chromium")

How do I create a X-windows window independent of the current window manager?

I am playing with X-windows, Xlib, etc. I want to create a X-window independent of the window-manager: meaning that I do not want the WM to put a frame, minimize-maximize, close, menu, title-bar, etc. in the window. I want to create a vanilla X window. How?
[edit]
Alternatively, how to I capture those events so my windowing app can at least die without an error?
[edit] ninjalj's answer led me to the following info:
ICCCM
Lots & lots of info :) cool!
Tutorial
I think what you want is an override-redirect window. Just set the override-redirect on your XSetWindowAttributes struct (and the corresponding bit on valuemask) when creating the window.

How do I make a window move to the top of other windows in Gnome when that window already has the focus?

I have an application that sends the focus to other windows but those windows then don't automatically display themselves in the foreground, i.e. on top of all the other windows. Where can I configure the preferences of my window manager so that this is the default behaviour?
In particular I'm using the Ctrl-0 and Ctrl-Shft-0 shortcuts in the MATLAB IDE to move between the command window and the editor window and although the focus seems to be transferred the new window doesn't automatically redraw itself in the foreground.
Not sure of a key binding off hand that does it, but if you alt-click on a window (which allows you to drag a window) it should come to the front.
As codeDr suggests, MATLAB is also kind of bad about repainting its windows. If you draw to a figure while code is executing, the figure does not update unless you execute drawnow or have some similar pause in the execution to allow the GUI to repaint. Since we're talking about MATLAB, the figure command will also cause the indicated figure to come to the front (in fact, it's harder to get it to not come to the front). So you could do figure(gcf) to bring the current figure to the front, or save the figure number with h = figure; and then later do figure(h). Incidentally, if you want to switch current figures without switching focus, set(0, 'CurrentFigure', h) should set h to the current figure.
Your window manager (probably Metacity?) implements focus-stealing prevention so that rogue apps don't pop up windows that would disturb your typing. Matlab needs to raise its window, and give it the input focus with the correct timestamp. If this is being done from a KeyPress event handler, the timestamp for setting the input focus would be the timestamp from the KeyPress event (i.e. the timestamp of the user-generated event that caused a window to be raised/focused).
To politely give the input focus to a window, google for _NET_ACTIVE_WINDOW.
Usually when the window doesn't repaint, it means that the application's main application loop isn't running to refresh the window. Could it be that Matlab is doing some computation or disk activity when you are switching between windows?

Resources