I'm developing a 3D desktop application like this where I duplicate the desktop by creating planes in 3D space using each window's bitmap as texture and then passing mouse and keyboard input to them (background windows) via windows API.
This approach causes several issues and the main one is that some clicked windows generate new popup windows like menus that popup on top of 3D app and steal focus.
Is it possible to properly duplicate a desktop behavior inside another app like this - without losing focus and keeping 3D app on top?
Only workaround for this that I can think of is to have 3D app running on secondary monitor, let user work with regular desktop on primary monitor as usual and 3D app will just duplicate that and use windows hooks for any 3D app specific input.
Apparently IInspectable is right. No reliable way to do this without losing focus.
Related
I created a simple windows app that i want to pin to my desktop similar to a wallpaper widget. I am using a nodeJS module that is almost doing everything i want. Essentially from my limited understanding this module is utlizing windows libraries and its creating a progman worker and sending the 0x052C instruction to create a Window on the desktops wallpaper plane.
I think its defining the type of window and its position (wallpaper) based on this value? 0x052C
// Message to Progman to spawn a WorkerW
static int WM_SPAWN_WORKER = 0x052C;
The app is built with Electron which is NodeJS enviroment so im a bit ignorant in the world of C++ and C#. But i have 2 issues right now with my window.
Issue #1: My window doesnt allow any mouse interaction. I can not push any of the buttons in my app for example. I assume this is because its on the desktop wallpaper plane.
Issue #2: My window is allowing my desktop icons above it. Which makes sense. But I wanted to find a way to make them on the wallpaper but not behind the icons. But behind every other window.
Question 1: where can i learn about this value and possible other value's I can send to progman? 0x052C or am i misunderstanding?
Question 2: how can i draw above the desktops wallpaper but under all normal windows? Is there a tutorial i can follow to learn how to achieve this and solve Issue #1 and Issue #2?
A big reason i used this method was to avoid getting my window hidden from the "show desktop" feature in windows. Trying to get my window to behave like a desktop gadget.
I just need a starting point or a spark to find the correct library/instructions to use. Thanks for any insights!
I'm building a UI in Qt 5.9 that needs to run on an X11 display. I'm trying to add drop shadows to my dialog windows - but they don't work over X11.
The approach I'm taking is from zeFree's answer in This Question. (Put everything in the window in one widget, set the window translucent, and create a dropshadow effect on the widget).
setAttribute(Qt::WA_TranslucentBackground); //enable Window to be transparent
QGraphicsDropShadowEffect* effect = new QGraphicsDropShadowEffect();
effect->setBlurRadius(5);
ui->widget->setGraphicsEffect(effect);
It works great in my redhat vm:
RedHat Dropshadow
But when I send to the X11 display I, it looks like the transparency isn't supported, and I get the shadow on black instead:
X11 Dropshadow
My question is: Is there a way to make my Dialogs project a drop shadow onto my main window instead of onto their own (transparent) background? My application will be full screen on the X11 display so I don't need to worry about shadow effects outside of the window.
Any answer that gives me a clean way to get a drop shadow effect on this X11 display will be accepted.
If your window manage doesn't support transparency you are out of luck IMO. At least with your current approach.
There is theoretically a way to fake it, provided you can grab the pixel values from the underlying window manager composite that is under your application, then draw those pixels from your application, filling the black void, with the shadow composed over that, and finally your GUI stuff.
There is also the more viable course of giving up on native windowed dialogs and fake the dialog using a regular floating widget. This has the disadvantage that it will only be able to move within the confines of your main window, but this way you will have complete control over the drawing and not fall victim to platform limitations.
I am trying to draw on top of another process while it is in immersive full-screen mode.
I know this is possible using GDI and I have 2 questions:
Is it possible using a top-level transparent window ? (on top of the immersive process)
Is there a higher level API witch I can use instead of GDI?
Thank you :)
In Windows, you have two possibilities for creating a fullscreen window:
A full-screen application with exclusive drawing rights to the display.
A borderless window that extends to the full desktop resolution.
The first option allows you to change display properties like resolution, bit depth and refresh rate, while the second option is bound to use the same options here as a normal (windowed) desktop application.
Overlaying a fullscreen window with a top-level window is only possible if the fullscreen application is implemented with option 2. In that case however, any code that is able to create a transparent top-level window will do (be it pure WinAPI/GDI, or something more sophisticated, like Qt).
With option 1, as the description suggests, the fullscreen application has exclusive drawing rights to the display. Attempting to bring another window in front of it will either minimize the fullscreen application or force it into windowed mode.
There are some hacks how you can still get an overlay in this case, but they are rather invasive. For example, with a fullscreen application based on D3D, you can hook into D3D's Present routine and have D3D draw your overlay before displaying the back buffer. The important point here is that the code for drawing the overlay is executed from within the process of the fullscreen application, as that is the only process that is allowed draw to the screen at that point.
Note that some applications (in particular video games protected by anti-cheat software) do not like it very much if you inject code into the process this way.
Note that the Win API also provides an interface for so called hardware overlays, which allow drawing on top of exclusive fullscreen applications. Unfortunately, this mechanism is not widely supported on consumer hardware and might not work depending on which graphics card you are trying to run it on.
I'm writing a desktop. I already know the basics of Qt and GTK+ through Python but I don't understand how to display the finished Desktop. How do you make it the root window of a Window Manager, or is there a method for displaying the desktop I'm not familiar with?
You don't make it the root window. X has one root window which you can't change. There are a number of ways to do what you want
X Root window
The old way was that the desktop was just the standard X root window. Icons were just individual borderless windows.
Desktop Window
Now most systems open a large window, and mark it as being a desktop window. Most window managers then know never to raise it above any other windows. The X root window is still behind it, but it is hidden. This means you can do anything you want on this window, draw to it, include icons or widgets or anything else your toolkit can do.
If you are using Gtk+ then the relevant information is found in the GdkWindowTypeHint enum, specifically the GDK_WINDOW_TYPE_HINT_DESKTOP. The documentation can be found here: GdkWindow
Compositor
However, there is a newer way that desktops like Gnome3 or Unity use, which is called the Compositor Overlay Window. When a compositor is running there is an overlay window which covers all the windows on the system. It is then up to the compositor to draw the actual contents of the windows on this overlay. However, the overlay can draw whatever it wishes on this overlay window. For example, in Gnome3 when you enter the window selector and the windows arrange themselves into a grid the windows aren't really moving and shrinking, the compositor has just decided to draw them that way. In reality, the windows are still in the same position they were before, but hidden under this overlay.
This is a very advanced way to do things, and certainly not for the novice developer. You probably want to be focusing on the second method.
I've seen an application that simulates a fullscreen application by removing the title bar and the window borders. I've done some research and found getWindowLongPtr() for that.
Now my question: How can I find and identify the application and get the appropriate window handle? How can I distinguish multiple instances of the application (running from different locations on disc)?
Just to make "simulate" more precise. If you make an application go fullscreen and you click on a different monitor, it minimizes itself. If the application runs in a window and you click on a different monitor, the window is not changed. If you remove the borders of the window and position it on the left or right monitor, you can still work with the other monitor without minimizing the application. Still it looks like the application running fullscreen on one of the monitors.
As an example: you can set Eve (www.eveonline.com) to fullscreen and windowed mode. In fullscreenmode you can not click on a second monitor without Eve minimizing itself. In window mode you can. There are tools like evemover that allow you to setup your window on one monitor, looking like fullscreen, but being in window mode. That's what I want to archieve. Evemover actually provides some of it's source code, that's why I know that removing the border and setting the position is done using the Win32-API with setWindowLongPtr and setWindowPos.
Many applications use divergent and confusing applications of the phrase "fullscreen".
A fullscreen application simply - occupies the full screen area.
DirectX applications can request a fullscreen exclusive mode. The advantage of this mode to DirectX applications is, with exclusive access to the (full) screen they are then allowed to change the resolution, bit depth etc, as well as gain access to vertical sync synchronized hardware buffering where the screen surface is 'flipped' between display intervals so that 'tearing' does not occur.
Anyway, the windows desktop understands 'fullscreen windows' - windows that occupy the full area of a monitor and have no non client elements. When windows like this are created, things like desktop gadgets and task bars automatically hide themselves. Modern games have come to call this mode 'fullscreen windowed'.
Back to your question: 'FindWindow' is the API used to discover other applications windows. Getting the path to the application that created the window is much harder. GetWindowThreadProcessId can get you the process id of the owning process. OpenProcess will get you a handle that you can pass to QueryFullProcessImageName (implemented on Vista and above) to get the full path to the process.
I think you are refering to applications like window aggregators, that 'plug in' to the system and act from outside the application.
Look at the code for the freeware app PuttyCM (for aggregating Putty (SSH) shell windows as tabs). IIRC, it ensures that the Window pointer passed to the application has the flags already set.
On applications running from different places, you will probably need some way of identifying it - registry entries / install log etc.