How to manipulate application windows on linux with C/C++ - c++

I dont have a lot of experience with C so sorry if this is a dumb question.
I'm writing an application that will monitor and manipulate application windows and i need to figure out how to do the following:
Get a list of all application windows
Be notified when a window is resized
Be notified when the a user maximises/minimises a window
Set the size and position of an application window.
I spent quite a while searching google but did not find anything useful. The language is not to important as i could make this project work with C or C++ maybe even C#
Any help would be appreciated.

on linux windows are handled by X11 ( X Window System https://en.wikipedia.org/wiki/X_Window_System, https://en.wikipedia.org/wiki/X.Org_Server ) and X Window Managers like Enlightenment ( https://en.wikipedia.org/wiki/Comparison_of_X_window_managers ), and tools and libraries like xdotool or Xlib ( https://www.lemoda.net/c/xlib-resize/ ...).
X11 is low(est)-level application window handling on linux
on this X11 basis you normally write programs that contain windows using Qt or GTK+ framework, in both frameworks are implemented methods to do all your mentioned tasks ( What should I choose: GTK+ or Qt? )
important is the installed X windows manager ( https://en.wikipedia.org/wiki/Comparison_of_X_window_managers ). In the overlying Qt and GTK+ frameworks only functions can be used that are implemented by the underlying X window manager
resize window event capturing in Qt and GTK :
http://www.qtcentre.org/threads/54968-how-to-detect-window-resize-event
GTK detecting window resize from the user
A list of all open X windows can be queried with XQueryTree function from the Xlib library
( How to get the list of open windows from xserver )
xwininfo ( https://linux.die.net/man/1/xwininfo ) can be used to collect information about open windows

EDIT: I was just thinking of something else when I answered the question the first time. In fact what you are asking for is pretty simple.
Here is a potential solution.
Register for Create/Destroy/Resize window events (XCB_EVENT_MASK_STRUCTURE_NOTIFY) so you can keep up with newly added/destroyed/resized windows. Depending on your setup you may want to add the XCB_EVENT_MASK_PROPERTY_CHANGE so you can tell if the "minimized" or "maximized" property is set.
Query _NET_CLIENT_LIST (ie via xcb_ewmh_get_client_list) or use
XQueryTree to get all (application) windows. The former will give you a filtered list that will probably be a superset of "application windows". The latter will give you every single window which will probably be more than what you want.
Send configure request to resize the window. Like others have said, xdotool can be used to send these requests. Note that, in general, these requests are likely to be blocked/modified by the WM. If you don't own the window, there is no good way around this unless your WM allows it. If you do own the window, you could set the override redirect field on the window.
Below is a code sample on how you might listen for events (complied with -lxcb). Note that this is just a sample and you would probably want to filter events in the switch statement (ie you don't want all properties)
void main(){
//create connection using default display
xcb_connection_t* dis = xcb_connect(NULL, NULL);
if(xcb_connection_has_error(dis))
exit(1);
xcb_screen_t*screen=xcb_setup_roots_iterator(xcb_get_setup(dis)).data;
int root = screen->root;
int mask = XCB_EVENT_MASK_STRUCTURE_NOTIFY|XCB_EVENT_MASK_SUBSTRUCTURE_NOTIFY|XCB_EVENT_MASK_PROPERTY_CHANGE;
if(xcb_request_check(dis,xcb_change_window_attributes_checked(dis, root,XCB_CW_EVENT_MASK, &mask)))
exit(1);//an error occured
while(1){
xcb_generic_event_t *event;
event = xcb_wait_for_event(dis);
switch(event->response_type){
case XCB_CREATE_NOTIFY:
printf("New window\n");
break;
case XCB_DESTROY_NOTIFY:
printf("Window deleted\n");
break;
case XCB_PROPERTY_NOTIFY:
printf("Window property change\n");
break;
case XCB_CONFIGURE_NOTIFY:
printf("Window size has changed\n");
break;
}
}
}
If you are new to X11, I personally recommend xcb instead of Xlib because its easier to debug, but its just a personal preference. You could use either or both. Also keep in mind that X11 api has been ported to many languages like python so you are not stuck with C.
Looking through your comments, yes DE/WM can impact your code. Not sure of your use case or how deep you want to go but you can
switch WM (there are a lot to choose from)
Run in a sandbox where no WM is running
See if your WM can white list certain windows so you can modify them directly or see if you WM is scriptable/allows you to add hooks when certain events are run
Write your own WM. You can get notified of every event you care about but you'd have to do everything else you'd ever want so it would be a lot of work
I will admit that X programming can have a bit of a learning curve but it gets better.

Related

How should a Windows application with custom controls be drawn with Direct2D?

I would like to create a Windows application (for Windows 10) using the C++ and the Windows API. I already have some basic knowledge of using the built-in windows controls to create a basic application, but would now like to expand into custom controls . Since I have no need for my application to be compatible with anything but Windows 10, and would like to use a reliable API which supports transparency and anti-aliasing but is also fast enough to render a GUI, I have chosen to use Direct2D.
The MSDN documentation says:
'Your application should create render targets once'
Bearing this in mind, should each child window use one ID2D1HwndRenderTarget which renders only to the parent window (and doesn't respond to the child windows' WM_PAINT messages), or should there be a single ID2D1DCRenderTarget which would draw to each control using the device context from the WM_PAINT message (using bindDC() - although I would still like to be able to use transparency, and am not interested in GDI interoperability)? Should I even be using Direct2D at all?
I would like to use the Windows API, so a solution involving QT or MFC wouldn't work. I haven't got a specific application in mind, but would eventually like to create a simple library that would enable me to quickly produce GUI applications that have a custom look.
I have spent hours scouring the web for answers, but have found nothing conclusive. MSDN itself seems particularly unhelpful, it just teaches you to draw an ellipse and stops there. Please forgive me if I have accidentally broken the rules of asking questions - as you can probably tell I am new to Stack Overflow - and if any other information is needed, I will of course include it (I am using C++ with Visual Studio Community 2019).

Trying to write a c++ console program to change a setting controlled by a windows checkbox

Is it possible to create a keyboard shortcut to switch between the monitor and portion selection of this wacom preferences window, via a c++ console program?
Sorry if this is poorly worded, I've had trouble trying to find the right words to search for ways to do it.
I think it should be possible, although a bit tedious. You should be able to use the Windows API, and try to EnumWindows/EnumDesktopWindows to identify the respective application Window, and its respective controls (which are also Windows).
You should identify the window title, and class ids, for the app window, and the checkbox button controls, then when you enumerate through all the desktop windows, you can identify the ones you are interested in.
Then you can use the SendMessage() API to send messages to the controls (Windows) of interest to manipulate them.
It's a bit tedious, but sounds possible.
An example of use here to get an idea:
http://www.cplusplus.com/forum/windows/25280/

QT How to embed an application into QT widget

In our project we have three independent applications, and we have to develop a QT control application that controls these three applications. The main window will be seperated to three sub windows - each one display another one application.
I thought to use QX11EmbedWidget and QX11EmbedContainer widgets, but two problems with that:
The QX11Embed* is based on X11 protocol and I dont know if it's supported on non-x11 systems like Windows OS.
Since QT 5 these classes are not existing, and the QT documentation doesn't mention why.
So that I dont know whether to use it or not - I'll be happy to get an answers.
In addition, I see that the QT 5.1 contains QWidget::createWindowContainer(); function that in some posts it looks like this should be the replacement to the X11Embed. Can anyone please explian me more how can I use this function to create a QT widget that will run another application (a Calculator for example) inside its?
I have searched a lot in Google, and didn't find answers to my Qs.
Can anyone please help me? Am I on the right way?
Thanks!
If all three independent applications are written with Qt, and you have their source, you should be able to unify them just through the parenting of GUI objects in Qt.
http://qt-project.org/doc/qt-4.8/objecttrees.html
http://qt-project.org/doc/qt-4.8/widgets-and-layouts.html
http://qt-project.org/doc/qt-4.8/mainwindows-mdi.html
If you don't have access to them in that way, what you are talking about is like 3rd party window management. It is kind of like writing a shell, like Windows Explorer, that manipulates the state and the size of other window applications.
Use a program like Spy++ or AutoIt Spy for Windows and the similar ones for other OS's, and learn the identifying markings of your windows you want to control, like the class, the window title, etc. Or you can launch the exe yourself in a QProcess::startDetached() sort of thing.
http://qt-project.org/doc/qt-5.1/qtcore/qprocess.html#startDetached
Then using the OS dependent calls control the windows. The Qt library doesn't have this stuff built in for third party windows, only for ones under the QApplication that you launched. There are a lot of examples of doing things like this by AutoHotKey, or AHK. It is a scripting language that is made for automating a lot of things in the windows environment, and there is port for Mac as well (though I haven't tried the mac port myself).
So in the end you are looking at finding your window probably with a call like this:
#include <windows.h>
HWND hwnd_1 = ::FindWindow("Window_Class", "Window Name");
LONG retVal = GetWindowLongA(hwnd_1, GWL_STYLE); // to query the state of the window
Then manipulate the position and state of the window like so:
::MoveWindow(hwnd_1, x, y, width, height, TRUE);
::ShowWindow(hwnd_1, SW_SHOWMAXIMIZED);
You can even draw widgets on top of the windows you are controlling if you set your window flags correctly for the windows you are manipulating.
transparent QLabel with a pixmap
Cannot get QSystemTrayIcon to work correctly with activation reason
Some gotchas that come up in Windows when doing all of this, is finding out the quirks of the Windows UI when they set the Display scaling different from what you expect, and if you want to play nice with the Task bar, and handling all the modal windows of your programs you are manipulating.
So overall, it is do-able. Qt will make a nice interface for performing these commands, but in the end you are looking at a lot of work and debugging to get it in a beautiful, reliable, window manager.
Hope that helps.
I never tried it myself, but from the docs in Qt 5.1 I would try QWindow::fromId(WId id), which gives you a QWindow, which should be embeddable with createWindowContainer:
QWindow * QWindow::fromWinId(WId id) [static] Creates a local
representation of a window created by another process or by using
native libraries below Qt.
Given the handle id to a native window, this method creates a QWindow
object which can be used to represent the window when invoking methods
like setParent() and setTransientParent(). This can be used, on
platforms which support it, to embed a window inside a container or to
make a window stick on top of a window created by another process.
But no guarantee. :-)

Can C++ be used to interact with running applications?

I'm looking to mess around with C++ and build some kind of desktop application that can interact with other windows. Something like a window tiling manager (e.g. minimizing current windows, snapping windows into a grid etc). Is this possible to do in C++? I've only ever worked with command line stuff, so is there a good framework for this kind of work? Anything in the right direction or how I can accomplish something like this would be awesome.
In Windows
You can use EnumWindows to iterate through each of the windows. It starts from the topmost window and works its way down. The following code will loop through each visible window and print out the winow's text.
#include <windows.h>
#include <stdio.h>
BOOL CALLBACK EnumWindowsProc(HWND hWnd, long lParam) {
char buff[255];
if (IsWindowVisible(hWnd)) {
GetWindowText(hWnd, (LPSTR) buff, 254);
printf("%s\n", buff);
}
return TRUE;
}
int main() {
EnumWindows(EnumWindowsProc, 0);
return 0;
}
Since you have the handle of each window, you can do further manipulations by sending messages to them.
I created a tool to play with windows and shapes called Desktop Playground that uses this very method.
I spawn off a thread and store each window in a hash table with their coordinates and size. Then I iterate through and compare their current position and size with their previous one and execute callbacks to let my main thread know whether a window was Created, Moved, Reiszed, or Destroyed.
On Windows you can use the SendMessage function to active windows or processes.
This question is highly related on which OS, or GUI framework is used for such application you want to create.
If the OS supports interfaces for such interaction, it certainly can be used with C++ if there's a certain language binding to the GUI control API (C/C++) provided.
Usually it's not a good idea to use these API's natively from your code, but through a C++ library that abstracts the low level bits and operations out.
At a next level there are libraries available, that even support abstractions for diverse OS specific GUI and System Control APIs. If you're looking for OS portable code, check out the Qt framework for example.

How do I get the window handle of the desktop?

The Windows API provides an API GetDesktopWindow( ) which returns the window handle
But I tested with Spy++ and I find that the window handle of the desktop and the window handle of the "Windows Desktop" is not the same.
As the "Windows Desktop" is a list view, do I need to do the following
1) HANDLE hWnd = GetDesktopWindow() ;
2) FindWindow(hWnd, ..... ) with the SyslistView32 as the Window class.
Once I get the Window handle, I want to use SendMessage() for operations like getting selected file name, the number of files selected , etc.
Please give your opinions. I am doing this using the Windows SDk
In light of a recent discussion on Meta complaining that questions like this one have "not been properly answered", I'm going to try and give answering this one a whirl. Not to imply that I think meklarian's answer is bad—in fact, far from it. But it's clearly been deemed unsatisfactory, so perhaps I can fill in some of the additional details.
Your problem results from a fairly widespread confusion over what the desktop window actually is. The GetDesktopWindow function does precisely what it's documented to do: it returns a handle to the desktop window. This, however, is not the same window that contains the desktop icons. That's a completely different window that appeared for the first time in Windows 95. It's actually a ListView control set to the "Large Icons" view, with the actual desktop window as its parent.
Raymond Chen, a developer on the Windows Shell team provides some additional detail in the following Windows Confidential article: Leftovers from Windows 3.0
[ . . . ] While in Windows 3.0, icons on the desktop represented minimized windows, in Windows 95, the desktop acted as an icon container.
The Windows 95 desktop was actually a window created by Explorer that covered your screen (but sat beneath all the other windows on your desktop). That was the window that displayed your icons. There was still a window manager desktop window beneath that (the window you get if you call Get­Desktop­Window), but you never saw it because it was covered by the Windows 95 desktop—the same way that the wood paneling in the basement of my colleague’s house covered the original wall and the time capsule behind the wall.
[ . . . ]
This desktop design has remained largely unchanged since its introduction in Windows 95. On a typical machine, the original desktop is still there, but it’s completely covered by the Explorer desktop.
In summary, then, the window returned by the GetDesktopWindow function is the actual desktop window, the only one we had way back in Windows 3.0. The Explorer desktop (the one that contains all your icons) is merely another window sitting on top of the desktop window (although one that completely covers the original) that wasn't added until Windows 95.
If you want to get a handle to the Explorer desktop window, you need to do some additional work beyond simply calling the GetDesktopWindow function. In particular, you need to traverse the child windows of the actual desktop window to find the one that Explorer uses to display icons. Do this by calling the FindWindowEx function to get each window in the hierarchy until you get to the one that you want. It has a class name of SysListView32. You'll also probably want to use the GetShellWindow function, which returns a handle to the Shell's desktop window, to help get you started.
The code might look like this (warning: this code is untested, and I don't recommend using it anyway!):
HWND hShellWnd = GetShellWindow();
HWND hDefView = FindWindowEx(hShellWnd, NULL, _T("SHELLDLL_DefView"), NULL);
HWND folderView = FindWindowEx(hDefView, NULL, _T("SysListView32"), NULL);
return folderView;
I noted there that I don't actually recommend using that code. Why not? Because in almost every case that you want to get a handle to the desktop window (either the actual desktop window, or the Explorer desktop), you're doing something wrong.
This isn't how you're supposed to interact with the desktop window. In fact, you're not really supposed to interact with it at all! Remember how you learned when you were a child that you're not supposed to play with things that belong to other people without their permission? Well, the desktop belongs to Windows (more specifically, to the Shell), and it hasn't given you permission to play with its toys! And like any good child, the Shell is subject to throwing a fit when you try to play with its toys without asking.
The same Raymond Chen has published another article on his blog that details a very specific case, entitled What's so special about the desktop window?
Beyond the example he gives, this is fundamentally not the way to do UI automation. It's simply too fragile, too problematic, and too subject to breaking on future versions of Windows. Instead, define what it is that you're actually trying to accomplish, and then search for the function that enables you to do that.
If such a function does not exist, the lesson to be learned is not that Microsoft simply wants to make life harder for developers. But rather that you aren't supposed to be doing that in the first place.
If you want the Desktop window as defined in GetDesktopWindow(), use that window handle. This is the window handle you should use to look for top-level windows and other related activities.
What you're seeing in Spy++ is just the content drawn as the desktop in your session. If you use the auto-locate in Spy++, you'll see that the SysListView32-declared window is a child window of your explorer shell. It is quite infrequent for someone to need access to this window. Also, the existence of this window may be subject to changes between versions of windows.
Edit (additional info)
If you are looking to interact or place things on the actual shell desktop, you may be better served by other APIs. Here are two such APIs that can accomplish this, depending on the target version of windows.
Windows Sidebar # MSDN
This is available on Vista and Windows 7
Using the Active Desktop # MSDN
This is available on Windows 2000 and XP, although frequently disabled by users and sysadmins.