Pressing +G in Windows 10 causes the Xbox Game Bar to open - it overlays the current application, regardless of if it's a game or not (though Windows maintains its own database of games as a hint to show the bar automatically on process startup or not)
I wondered how this is possible - I don't have any Windows 10 Xbox App-related processes running on my computer.
Process Explorer shows that when WinKey+G is pressed, the following happens:
An svchost.exe instance (which is hosting the BrokerInfrastructure, DcomLaunch, LSM, PlugPlay Power, and SystemEventsBroker services) invokes "%windir%\System32\bcastdvr.exe" -ServerName:Windows.Media.Capture.Internal.BroadcastDVRServer
bcastdvr.exe then invokes "C:\Windows\System32\GamePanel.exe {hexString} /eventType=8 (where {hexString} is a 16-hex digit (8 byte) string, presumably a window handle or equivalent).
GamePanel.exe then creates the window.
But the overlay window itself is special - it doesn't seem to be a normal hWnd - for example, I observe that my mouse cursor loses its drop-shadow and the "sonar pulse" effect (when I tap the Ctrl key to show my cursor location) stays in-place where my mouse cursor was when I opened the Game bar. I also noticed how smooth and fluid the game-bar's animations are - quite unlike a typical Win32 window. Is it using the XAML UI framework? If so, how is it doing it outside of the Windows UWP Sandbox?
Curiously, the game-bar is also able to target elevated windows too.
I tried - and failed - to inspect the windows using Spy++ because it disappears as soon as another window gets focus - but when I elected to start recording a window (so you get the recording overlay, which always remains on-screen), the overlay disappeared as soon as I used Spy++'s "Find Window" tool. How is the GameBar Recording Overlay doing this?
So it turns out that after some research, I found out that the gamebar is a .exe file located in C:\Program Files\WindowsApps\Microsoft.XboxGamingOverlay_5.120.4062.0_x64__8wekyb3d8bbwe that is opened with the Win-G shortcut (which can be changed). From what I've seen, when opened, you will not be able to see the gamebar in the apps page of task manager, but rather the background processes page where it is grouped with the runtime broker which makes me believe that it is a program that is loaded by default on boot and built in to the ram of the OS of the device. You can find the properties of the gamebar when you expand the gamebar section in the background processes section then right click the "Xbox Game Bar" and then clicking properties. I think that the transition into the gamebar are smooth because of it potentially being an app built in the RAM and offloaded as a background process by default. The SYSTEM account also has full control of the file which furthers supports the possibility that the Xbox Game Bar is a feature that is pinned on windows ram.
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 have Debian 2.6 running on a SBC that I plan on using in an embedded setup. What I need to do is configure it so that linux will start up and run just my Qt GUI application. Do I need a window manager to do this or can I just do it with X11. Also because it is going to be for an embedded system I do not want to load any desktop manager. Any info on how this can be done would be great!
Yes you can do this without a window manager.
first: You need to boot into a non X session, init level 1 or 3.
second: You need to start the X server, in a basic mode by just calling X or xinit.
third: Start your app. You may need to take a little more control over where your app is positioned on the screen and its dimensions in your code, as you will not have a window manager to help with this.
alternatively: you can launch one of the more basic window managers to see how they play with your system. Motif Window Manager (mwm) and Tab Window Manager (twm)
Note: While working without a window manager, you may get into a state where you cannot do some very basic operations (ex: close a window, move a window, resize a window). You may find that you cannot survive without at least some of the more basic window management functions. Until you close the loop on this, remember, Ctrl + Alt + Backspace will kill the XServer.
If you want to start your app just with X11, you need do:
copy file /etc/X11/xinit/xinitrc to ~/.xinitrc
write all you want to run to it
run command startx
It worked for me and I hope it will help you
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.
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?).