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?).
Related
I have a few windows on my linux machine using the xfce4 desktop enviorment.
I wish to have a grid-like view where i can see only the part of each window im intrested in.
An example for the general vision:
see a script running without the window borders on terminal across the header
see work status of F#H client out of the advenced client view in the middle left
see only the turrents status list of qBittorrent at middle right
have another terminal at footer (again without header/borders)
My best way to describe it shortly is to generate a view from selective parts of windows.
Added a picture for illustration
Is there any way of doing such thing in a practical way? Am i missing out on a great software?
There are several tiling helpers for Xfce.
Perhaps try xpytile , which is a tiling add-on for Xfce. It offers
automatic tiling, manual tiling and can simulaneously resize side-by-side windows (like AeroSnap for MS-Windows).
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 want to implement a simple specialized window manager for presentations (not user-controllable) that supports only the following operations:
Moving and resizing of windows
Switching desktops
Starting applications not on current desktop (in background) without disrupting current image.
I don't need any user input, button/titles, ...
What existing window manager should I use as example? There are many little "hello world" window managers, but they usually does not support desktop switching.
You don't need to reimplement the wheel.
openbox will do everything you mention and more besides.
Simply edit the rc.xml to disable the root menu, and re-launch.
Openbox also allows per app setting so that certain applications can open on a particular desktop by default, or with a particular size, or open hidden.
It also supports wildcards in the window selection, so that settings can apply to all windows.
devilspie2 is a window matching utility that can perform actions whenever a window opens.
It is highly hackable and the code is available on github. It will match windows by name/class/etc when they open, and perform actions on them. (including matching all windows and moving them to a different desktop. It will work with most window managers.
Based on the original devilspie which does not have Lua scripting, but is configured using s-exprs instead.
xdotool will also allow you to perform complex actions on windows without hacking any code. It will even fake user input (mouse/kbd) if you need it.
There are a few window managers written in Python that could be good starting points. Qtile and whimsy both describe themselves as hackable.
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 a simple question,
i search the exact name of the window manager for Windows.
For Unix : X Window System
Mac : Quartz
Windows : ?
Thanks you.
In the sense of the linked article, Windows does not have a discrete window manager. The windowing system is responsible for drawing the windows, and "the shell" - typically explorer - is responsible for displaying a task bar and any icons on the desktop.
The appearance of a window manager however is an emergent property in Microsoft Windows: All windows have a WindowProc that handles messages - and all messages not handled by the application code must get passed to a function called DefWindowProc. DefWindowProc handles the clicks in the non client areas of the windows to perform the tasks typical of window managers - sizing, moving, maximizing and so on.
Because all window's WindowProcs get to choose how to handle messages, they can choose to not implement the typical window manager behaviors by handling the message them self and not calling DefWindowProc.
The taskbar - provided by explorer - provides buttons to manipulate windows but ultimately (a) Its just a regular window itself, and (b) It sends messages to the windows to get them to maximize, minimize, restore etc. themselves, so again, any particular window could choose to not act like the other windows.
DefWindowProc is implemented in user32.dll - so really that is the window manager.
It's got a really original name - It's called the "Desktop Window Manager". You can see they thought long and hard about how to get that one exactly right.
(This obviously had absolutely nothing to do with the Microsoft marketing department, otherwise it would have been called something crazy and unrelated like silverstuff or aero.)
Its called "Windows Explorer"
See http://en.wikipedia.org/wiki/Window_manager
The thing that does the drawing of lines and pixels on the screen has traditionally been GDI (gdi32.dll), or now WDDM (for Win7) - Windows Display Driver Model, which has another layert on top of that, DWM - Desktop Window Manager.
On top of all that, you have Aero and then Windows Explorer that display and manipulates windows.
Oh yes, I nearly forgot about Direct2D which is another rendering layer that fits in there somewhere. I suppose they'll come up with a final technology one day that'll form the basis of graphics and windowing for the next 25 years.