When I am running firefox as my active application and do a [ctrl]+[shift]+T, firefox opens a new tab. Hoever when I do a [ctrl]+[alt]+T, linux opens a new terminal window. Just made me ponder over the possible internals of this operation.
I had assumed that the control over stdin lies with the active application and if it reads something that makes sense to it, it goes ahead and does it. Now I feel that before the input is even put into stdin, the kernel scans it for the shortcuts that are relevant to it, and only the ones leftover are passed onto stdin, and from there to the user space applications.
Is this view accurate?
You are correct about what is causing it, just not the details. It's not the kernel that is swallowing it in this case, it's the Window Manager.
Your keyboard shortcut for Ctrl+Alt+T is getting eaten by your window manager. If you go to your Window Manager keyboard shortcuts, find the one bound to Ctrl+Alt+T and un-define it, it will work in FF properly.
The WM is a "layer" if you will that receives all events and passes on the ones that it determines are relevant to the underlying application.
Related
I would like to create some windows on a linux desktop for simple layout purposes. I need to avoid user input going to these windows (and I suppose avoiding the windows from gaining focus should suffice for that to happen).
I think that I can do this with the xprop command, by setting the WM_HINTS property, but I haven't found specific documentation on how to do it.
By the way, for an mplayer window, I can do this by using the option -input nodefault-bindings:conf=/dev/null. I simply need a general solution which I can enforce at a low level on any application's window.
Thanks!
A window indicates whether it wants to receive keyboard input by setting the KeyPress and KeyRelease bits in its event mask. If you do not want your window to receive keyboard input, simply do not set those event in CreateWindow()'s event mask. See http://www.x.org/releases/X11R7.7/doc/xproto/x11protocol.html#requests:ChangeWindowAttributes for more information.
Additionally, you should also set the input focus hints for your window to "NoFocus", as described in section 4.1.7 of ICCCM: http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.7
If you want to fiddle with other applications' windows, you should be able to change their attributes and hints, although this may result in undesirable behavior and/or side effects.
I have a window, with several Gtk-2.0 widgets. One of them is a GtkEntry, with the corresponding GtkCompletion connected.
I need to debug the code called when a selection ('match' event) is made in the dropdown shown by the GtkCompletion. So I set a breakpoint, activate the selection, and the entire desktop hangs. The only form I found to get out is Ctl-Alt-Backspace, and delete the gdb instance.
When this happens, the entire windows manager remains as if the dropdown is still active - only responds to Ctl-Alt functions, like Ctl-Alt-F2.
I tried the --sync commandline option, but that didn't make any difference. Though there seem to be some (rather complicated) solutions such as running a nested Window server, or debug remotely, I can't imagine there isn't a more elegant solution.
Any suggestions?
I do this all the time.
You need to grab another laptop, or a console on another server, and ssh into your primary desktop/laptop. Start your GTK application on your main desktop/laptop, then attach gdb to it from your connection from your other laptop/machine.
Then, you will run your gtk application on your main screen, and debug it from a separate connection, without interfering with your primary display.
EDIT: I see that you already considered remote debugging, but in my experience it's really not that difficult. I just have another laptop on my desk, next to me, to debug my X applications.
I'm working on a I/O verification tool based on Linux in a game project. It is written in C++, and,since using the same I/O module as our game, it's based on OIS 1.2. Thus, though all I need is to print users' inputs on the console, I still need to create a window for OIS.
So here comes my question: How can I create a mapped window while it is still invisible and processes keyboard events?
I can't unmapped the window in that it won't process any keyboard event anymore. I also can't find function for show/hide a window.(maybe I search through a wrong diretion...)
My little tool works fine now except there is a stupid top-level empty window which needs to be focused for processing keyboard events...
Any advise is welcomed.
Thanks!!!
After reading this post: Linux/X11 input library without creating a window,
I realized my problem was that I misunderstood the philosophy of X11. All I need to do is simply pass the root window handle to OIS, and set the x11_grabkeyboard flag as true. The only drawback is maybe I can hardly debug my program with gdb since the keyboard is grabbed...
Though my situation is solved, there is one thing left.
Every article I read said an InputOnly window won't be visible and is capable for handling input events, while my InputOnly window is absolutely visible after mapped...
Maybe it's my Linux, or again, a misunderstanding...
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?
I am working on old Motif-based application for Linux. I want to be able to programmatically change the active window of our application. I can redirect the input by using XSetInputFocus() function and the keyboard input start to go there, but XReconfigureWMWindow() and XRaiseWindow() functions just don't work.
I've read that Window Managers try to stop this behaviour, so tried to disable configure redirection, but this doesn't work either. Any ideas how to make one of my own windows on top of the window stack?
There is a tiny program called wmctrl available (at least in Debian/Ubuntu it is in standard distribution) which is able to perform many operations on windows and desktops, and handles plenty of window managers. I'd suggest testing whether it works in your environment, and if so, peeking at its sources.
You may find the answer to this is dependent on the Window Manager the user is using, or even what settings they've given to the Window Manager. I like to set my Window Managers to do "focus follows mouse", which means you can't send the focus to a window that I haven't put my mouse on, unless you also warp the mouse there (is that function called XWarpMouse?).