Is it possible for XMonad to behave like many window managers with regard to switching active window using Alt-Tab keys? After some looking I've tried:
((mod1Mask, xK_Tab), cycleRecentWindows [xK_Alt_L] xK_Tab xK_Tab)
from XMonad.Actions.CycleWindows module. This configuration "almost" works. One issue is that I must execute the sequence slowly (just under 1 second I think). Other WMs I have do not suffer from this kind of input lag. The other issue is that it shuffles windows around, I would love to have alt-tab just switch focus to previous window.
I am using GroupNavigation for similar thing
Following example does cycle through windows on all workspaces:
import XMonad.Actions.GroupNavigation
...
((modm , xK_Tab), nextMatch Backward (return True))
...
You can use standalone application: https://github.com/sagb/alttab .
It pulls selected window to the top instead of shuffle and has special xmonad readme.
Just use:
…
-- Move focus to the next window.
, ((mod1Mask, xK_Tab), windows W.focusDown)
-- Move focus to the previous window.
, ((mod1Mask .|. shiftMask, xK_Tab), windows W.focusUp )
…
To cycle throw windows in the same desktop as indicated by Neil Forrester
Related
So I just installed Pop OS to my system, but notice, that neither of JetBrains apps has a top toolbar. Firstly, it's just a dark line, but after some time it just disappears.
Tried to install the software in a different ways, but got the same results. I cannot move the window, exit or minimize (since there is no options, of course), only resize it. Any ideas?
If anyone is wondering, the problem was, that "Show Window Titles" was disabled by default for me. You can turn it on on Extensions -> Pop Shell -> Show Window Titles.
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))
I have run into this freaky thing in two places now, on a Windows 7 and an XP machine.
I have a laptop with an extra monitor connected. I start up cygwin's x-server, using the start menu shortcut (Cygwin-X/XWin Server). I then start an xterm by right-click the X icon in the icon tray at the bottom right, and selecting Applications/xterm.
I get an xterm. In it I can type text, but depending on which monitor the xterm window resides, all characters that require two keypresses on my swedish keyboard (example: "~" requires me to first press alt+the key marked "^ ¨ ~" and then press space, rendering a single ~ on the screen) result in a space being printed.
If I move the xterm to the other monitor, I am suddenly able to type a ~ in the xterm. Move it back to the previous monitor, and I can't type ~ anymore.
Weird or what? This is the problem I have now, on my XP laptop. On my Windows7 laptop (same basic setup) I had the problem that I could only type stuff like åäö (not indirect/combined characters - I have keys marked å, ä and ö respectively on my keyboard) on one monitor, not the other.
I have messed around with different ways to start up the X Server, I think I am doing it the right way as I describe here.
My cygwin installation is maybe a year old on both machines. I would like to be able to find whatever setting causes this behaviour, so I can handle it should I come across similar problems in the future.
Any ideas?
Edit: some stuff that looked like html tags got mangled.
Since this seems to be a problem only with xterm, as a simple workaround I would suggest using some other terminal emulator instead of xterm. On Cygwin, a really nice substitute is mintty (available as a Cygwin package from within Cygwin setup). I stopped using xterm in favor of mintty some time ago because I found it to simply be an all-around more useful terminal emulator.
As a possible side benefit of using mintty, if xterm is the only X application you typically use, then you don't even need to run an X server any more because mintty is not an X application.
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.
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?