I'm using the XFCE4 desktop environment under Ubuntu 20.0.4.
I have several virtual desktops set up, each of which containing one or more applications which are running.
Is there any way I can run an X-Windows-based command from one desktop and have it manipulate a window in a different desktop, without switching desktops?
For example, suppose I have an xterm shell window running in virtual desktop 0, and that I currently am focused in virtual desktop 0.
And suppose I have a text editor window open in virtual desktop 1.
Is there any way for me to remain focused in desktop 0 and to run a command within the xterm shell window which will send text to the text editor window in desktop 1?
I don't want to see desktops shifting back and forth between desktop 0 and desktop 1 while this text is being sent to the text editor. I want to remain focused in desktop 0 for the entire duration of the running of this command.
I know I can use xdotool to send text to another X window, but xdotool only seems to function when the destination window is in the same virtual desktop which currently has the focus. For example, I can do the following with xdotool, but it won't work unless the destination window (referred to by $windowid in the following example) is in my currently viewed virtual desktop:
xdotool type --window $windowid Sample text
What I want is to send text and mouse clicks to windows in desktops that differ from the desktop that I'm currently viewing, and have the windows in those other desktops receive and respond to the text and mouse clicks without any switch to the other desktops taking place.
If necessary, I'm willing to write a program in C, C++, or pretty much any other language in order to implement this functionality.
But I'm wondering: is what I'm trying to do even possible in an X Windows environment?
Thank you very much in advance for any thoughts and suggestions.
Virtual Desktops:
Most X servers have only a single screen. The window manager may virtualize this resource and offer multiple so-called 'virtual desktops', of which only one can be shown on the screen at a time. There is some variation among the features of virtual desktop implementations. There may be a fixed number of desktops, or new ones may be created dynamically. The size of the desktops may be fixed or variable.
Implementation note
There are at least two options for implementing virtual desktops. The first is to use multiple virtual roots and change the current desktop by manipulating the stacking order of the virtual roots.
The second option is to keep all managed windows as children of the root window and unmap the frames of those which are not on the current desktop.
In any case, you should study the Extended Window Manager Hints.
These properties might be of interest to you:
Root Window Properties:
_NET_SUPPORTED - set by the Window Manager to indicate which hints it supports
_NET_CLIENT_LIST - all X Windows managed by the Window Manager
_NET_NUMBER_OF_DESKTOPS - indicate the number of virtual desktops
_NET_CURRENT_DESKTOP - the index of the current desktop
_NET_DESKTOP_NAMES - the names of all virtual desktops
_NET_VIRTUAL_ROOTS - a list of IDs for windows that are acting as virtual root windows
Application Window Properties:
_NET_WM_DESKTOP - determine the desktop the window is in (or wants to be)
_NET_WM_STATE - list of hints describing the window state
_NET_WM_ALLOWED_ACTIONS - list of atoms indicating user operations that the Window Manager supports for this window
Xlib:
Sending Events to Other Applications (XSendEvent)
Obtaining Window Properties (XGetWindowProperty)
Properties and Atoms (XInternAtom)
Obtaining Window Information (XQueryTree)
Related
I am very new to applescript, but was wondering if it is possible to open applications to different desktops "spaces" using applescript. I have found how to launch applications, but don't know how to assign them to different desktops. Basically I am looking to open;
Outlook - Desktop 1
Skype - Desktop 1
Safari - Desktop 2
Onenote - Desktop 3
Thanks for any help, I really appreciate it.
Last system versions do not include any scripting of spaces. the only thing you can now do is to assign, in system preferences, shortcut keys to switch to a space, and once done, launch applications you want to.
To simulate action keys in Applescript, use system event "keystroke" instruction.
Easy: start these applications, one by one, in your "chosen" space, click on and hold Dock's icon, move cursor to "Options" (below), select this one (of three) options:
– Current desktop (or: this desktop, or similar)
… which from now on will always open THIS application in THIS space.
There is no programmatic way in AppleScript to instruct your Mac to switch spaces/workspaces or even to return the identity (number) of the current desktop.
Switching may happen, though, if the relevant option in System Preferences, Mission Control, is set.
(Indirectly, comparing a desktop "picture" to a user-defined list empowers a script to get its "number".)
Look at the screen capture below - note how Windows groups taskbar icons of the same kind (VirtualBox + virtual machine on the left and two Explorer windows on the right). How would you go about doing this for your own application? Are the icons automatically grouped by process, or can you force Windows to group different processes too?
I've been Googling for this but I'm not quite sure what it is called. All links I've found so far only talk about Windows settings which group / stack / group when full etc.
After a quick Google search, this is what popped up:
Application User Model IDs (AppUserModelIDs) are used extensively by
the taskbar in Windows 7 and later systems to associate processes,
files, and windows with a particular application. In some cases, it is
sufficient to rely on the internal AppUserModelID assigned to a
process by the system. However, an application that owns multiple
processes or an application that is running in a host process might
need to explicitly identify itself so that it can group its otherwise
disparate windows under a single taskbar button and control the
contents of that application's Jump List.
Read more about the topic on msdn.
I need to do a pre-purchase evaluation of a Flash application that is intended for a touch screen.
Since I still don't have the touchscreen now, I need to run the application on my desktop computer and the application is unusable without a visible cursor.
I am using Windows.
Is there a way to unhide the cursor without asking the developers to change the application?
I've previously used remote access software (such as Windows Remote Desktop or TeamViewer) for this purpose. Another option is a virtual machine - in both cases you'll be able to see the cursor on the local/host machine.
If you happen to be on a Windows 8 machine, you might give a try to the Windows Simulator (http://blogs.msdn.com/b/visualstudio/archive/2011/09/29/first-look-at-windows-simulator.aspx, available for free with Visual Studio Express) that additionally simulates multitouch gestures such as pinch/rotate with only a mouse.
A few other ideas:
1) You can try using the "Show location of pointer when I press the CTRL key" mouse visibility property (Control Panel - Hardware and Sound - Devices and Printers - Mouse - Pointer options). Although not entirely convenient, it might help you if the application doesn't require quick response times.
2) If the application is distributed as a .swf file and the right button hasn't been disabled, sometimes right-clicking (anywhere in the application) to bring up the context menu will cause the cursor to show up and remain visible.
When I install a virtual desktop manager on Windows 7, and I switch to a different virtual desktop, all the current windows disappear, also disappearing from the Start Menu.
I want to hide some of a particular application's windows, but not all of them, in a similar manner. How can I hide a window like this?
In particular, I need to hide a VirtualBox Seamless mode window, so I'm not sure minimizing the window will work. It does, however, disappear when using virtual desktop managers.
The same window cannot appear on multiple desktops. If you need your application window to appear on multiple desktops you need to create a separate window for each desktop. The desktop a window appears on depends on the thread that creates the window. You can change the desktop thread assignment using the SetThreadDesktop function.
The answer is simply ShowWindow(SW_HIDE) and ShowWindow(SW_SHOW). I think "Virtual Desktop Managers" just hide windows and show them as necessary when the desktops change.
I have a hidden process that waits for non-standard hardware button messages and runs an application (with CreateProcess). No problem with the user disturbing, it's an action that the user approved himself. Everything is fine when it's usual layout with taskbar shown and multiply captioned and non captioned- windows. But the situation is different in XP and 7, when the current application is full-screen. Full-screen application in this case is window without borders having exactly the same dimension as the screen. Windows hides taskbar for such application even if it's always on.
In Xp, it's ok, the taskbar is being shown in this case and appication (for example calculator) also, the full-screen app is still visible in areas other than the launched app's and taskbar'. But in Windows 7 nothing visual happens, the full-screen app is still on and if I switch to taskbar, the executed application is there. I tried to solve it with SetForegroundWindow, BringWindowToTop, even AllowSetForegroundWindow(GetCurrentProcessId()) call for a window handle found with CreateProcess-WaitForIntputIdle-EnumThreadWindows, no change. So did something change since XP related to full-screen windows that officially documented?
Thanks,
Max
I would imagine that, if you have your own hardware device, that there is some API for generating "real" user input. Clearly the legacy keyboard and mouse, and now USB HID drivers (many of which are usermode I think?) have access to an API to do so.
Synergy+ for example can generate fake keyboard and mouse events on connected PCs, and the consequence of the faked input is windows switching activation normally.
So, my initial idea is for your usermode "Device" application to synthesize actual keyboard messages - SendInput seems a likely candidate for "the API that can "fake" real user input events.
Then, use an API like RegisterHotKey in your "UI" app to respond to the hotkey combination your device app generates.
Now, (assuming that SendInput IS generating user input events at the correct level), you should (from within the WM_HOTKEY handler in your UI app) have permission (because everything was "user initiated") to change the foreground window (to yourself).
Vista introduced the desktop composition feature. In short, all windows are drawing to a memory bitmaps and the Desktop Window Manager is then composing these bitmaps and drawing on a full-screen Direct3D surface. Full-screen windows do not participate in the desktop composition and get to draw directly on the screen (mostly because the majority of full-screen apps are games that need real-time screen updates).
In particular, this means that when a full screen app is up and running, it is covering the DWM composed image and the user needs to switch to a DWM-managed window for the DWM to start drawing on top of the full-screen app.
I don't have a good solution for your problem, unfortunately. One way to solve it would be to add the WS_CAPTION style to your app and then handle WM_NCPAINT/WM_NCCALCSIZE/WM_NCHITTEST yourself. This would allow you to lie to the DWM that you are a regular windowed application, but change visually your NC area to look like you have no title. However, this does require certain amount of additional code and might be a bit more effort you want to invest.
Another way you can try to solve your problem is to explicitly minimize your full-screen application window when launching the new process. However, you will then have to solve the problem of when to maximize it back again.
Btw, you might find the comments on this post from Raymond Chen interesting.
Windows supports multiple desktops and my guess would be that the full screen up is using a different desktop than the default one (where your application will be shown). A desktop object in Windows is "a logical display surface and contains user interface objects such as windows, menus, and hooks". For example, screen savers normally are started on a separate desktop.
You can find out which desktop an application is running on using Process Explorer:
Set Process Explorer to replace Task Manager and to run always on top.
When your full screen up is shown, launch Process Explorer by pressing Ctrl + Shift + Esc
Within Process Explorer, select the full screen process and press Ctrl + H to display the handles of this process
See the value of the Desktop item in the list. Usually this would be set to Default
If you know what desktop this app is running on you can start your process on the same desktop by first calling OpenDesktop to get a handle to this desktop and then pass it into the STARTUPINFO of your CreateProcess call.