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.
Related
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.
I would like to share with you this post as I wasted a lot of time to understand why the WS_EX_LAYERED flag did not work on a fresh install of Windows (my test was on a Win7, I don't know if it can be reproduced on a Win8 o.s.).
This was my code:
...
hParentWindow=hWnd;
HWND myWnd=CreateWindowEx(WS_EX_LAYERED|WS_EX_PALETTEWINDOW,_T("STATIC"),_T(""), WS_POPUP|SS_BITMAP,position.left,position.top, position.right, position.bottom,hWnd,NULL,hInst,NULL);
Then I wanted to add a transparent layer:
CWnd::FromHandle(myWnd)->SetLayeredWindowAttributes(RGB(0,0,0), 255*0.6, LWA_ALPHA);
Running the code, the window never appeared! And this was not a child window (the WS_EX_LAYERED does not work for a child window), so the WS_EX_LAYERED flag should have worked.
Why?
After spending almost a day in searching for the solution, I found that the target PC (the one that hosts the executable) had the Aero Peek theme disabled because it had never run the "Performance Information and Tools"!
So, IMHO, a programmer that is going to use the WS_EX_LAYERED in his code, must determine if the Aero Peek is turned on or not (for example by looking into the \HKEY_CURRENT_USER\Software\Microsoft\Windows\DWM key registry and check the EnableAreoPeek registry value), otherwise some windows could not be shown correctly in any PCs.
Hope this makes you to save your time!
I have been through the same issues today (Rosario I feel your pain of 2 years ago!).
I couldn't work out why windows were disappearing completely. I'm sure others may end up at this page for the same reason.
As such I wanted to pick up on one point.
The key factor to this seems to be that "Desktop Window Manager Session Manager" service must be running for transparent layers to function.
That EnableAeroPeek registry value, which relates to whether you see a full-screen preview of the windows as you look through them (eg. with alt-TAB or hovering over task manager mini-previews), can remain off and it not connected to the availability of transparency in tests I have carried out on multiple machines.
Similarly, if that registry setting is on but the DWMSM service being off, it will not give you transparency.
Rosario I'm sorry to contradict your own answer to your own question, but I think it's an important distinction!
So far the only way to test for the availability of transparency on Windows 7 & later before making a call which fails (or turns a window invisible) seems to be by checking for a running dwm.exe process.
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 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?).
What would be the best approach to install a keyboard hook on Linux (X-windows) in order to trigger some application when some key-combo is pressed?? Is there a way to do this regardless of which window manager is running? The idea is to have an application being called ( or brought to foreground ) when some key is pressed in a way similar that Google Desktop does to Ctrl-Ctrl.
XGrabKey on the root window is how xbindkey does it. Be careful about having some alternative method of killing the grab though, it's very annoying to have to go somewhere to ssh into your own box just to kill that process... And that's why, if it was me, xbindkeys+"echo 'moo' > /tmp/moo-fifo" would be the way to do it. That way, you could also control it in any number of other ways you haven't thought of yet.