For my workflow, I like to have multiple desktops. One for a browser, another for some sort of editor and another for a full screen terminal.
When I connect an external monitor though. It doesn't work quite how I would like.
If I place a window on my external monitor (like my music player or something). Then I switch desktops to view my editor. My external monitor also changes desktops.
Also if I use expose, My external monitor also goes into expose mode.
Kinda annoying.
Is there anyway (possibly using 3rd party tools). To keep the two monitors seperate an have two dedicated work areas/desktops?
I have this same issue. I like to keep different IDE's open on each desktop and use my external monitor as a 'common' desktop to hold reference material, etc.
I have been able to simulate it by setting certain applications to 'All desktops' but it would be great if it was window based and automatic. That way one could drag a window to the external monitor and have it stick to all desktops and drag it back and have it stick to the current desktop.
Related
I'm wondering if there's a good way to automate changing my display configuration in Windows 10?
I have 3 monitors attached, and I find myself wanting to configure my system in one of 3 ways:
All monitors set up to extend the desktop.
Only my central (largest) monitor enabled, others both disabled.
Only my right-most monitor enabled, others both disabled (I think hook up a spare HDMI cable on my center monitor to my laptop, and the monitor automatically switches to that input).
Manually, this involves opening the Display Settings panel, selecting the monitors, and either marking them as "Disconnected" or "Extend desktop on this display".
Is there some nice, scripting-friendly way to do this? I'm more comfortable doing this sorta thing on Linux, where I'd whip up a quick shell script to call the xrandr command a few times, or something like that...
I'm basically in two different modes when I work on my macbook. In one mode, I have a few apps running in desktop 1, another in desktop 2, a few in desktop 3 etc. Then when I switch from work to school mode, I want to run an entirely different layout at the click of a button instead of closing applications, retiling them, making new workspaces, and re-organizing everything.
Anyone know how to accomplish this? Maybe two different user accounts and just log in and out of both? But then it won't 100% preserve the state of everything, like when you close the lid and re-login..
I have been working on windows automation and monitoring.
What exactly happens when I lock the screen of a windows machine?
I am working with Windows 7 at the moment, are there big differences to the behavior if I switch to Vista or the server versions?
Is there still a desktop that can be accessed via api's?
I know that i can still send key strokes and mouse clicks to specific windows (via ControlSend and ControlClick), but there seems to be no "desktop" itself.
Could someone shed some light on this whole thing or point me at a readable source where I could get an overview over the topic?
Basically what happens is that Windows switches to the secure desktop, makes it the current one, so input is now associated with it.
The old desktop remains where it was: all the HWNDs on the desktop are still there, and any thread attached to that desktop can still access those HWNDs, get their location, and so on. You can still send messages to windows on this desktop, so long as the thread sending the message is also on that desktop.
However, since the desktop is now inactive, it cannot receive input. GetForegroundWindow will return NULL (IIRC), and you can't use SendInput any longer, since input now belongs to [a thread on] a different desktop; no controls on that inactive desktop can receive focus.
Note that sending keypress messages to a control that doesn't have focus can sometimes cause unexpected behavior, since the app or control generally never expects to receive keyboard input without getting the focus first. (This can be problematic for controls that set up some sort of input context in WM_SETFOCUS and clear it up in WM_KILLFOCUS, for example.)
In short, the UI is still there: you can do certain queries against it, but you can no longer automate it as you could on a regular desktop by sending input, and some other functions that relate to focus or input may fail.
I'm not super familiar with AutoHotKey, but the name and description of functionality suggests that it's heavily reliant on the underlying Win32 SendInput API. This won't work at all for keyboard input when a desktop is inactive.
For a reasonable overview of how desktops work and how they relate to winstations, the locked desktop, and so on, check out the Desktop article on MSDN.
One issue that I've run into in the past with desktops and automation is: how to I leave a long-running test that's using some form of user input automation (mouse, keyboard simulation), but still lock my PC so that someone can't just walk by and interfere with it. Once you lock the PC, the desktop is inactive, and so the automation stops working. A similar issue happens if the screensaver kicks in: the desktop switches, and the automation fails.
One solution is to use two PCs: let's call them Main and Test: from Main, open a remote terminal services client onto the Test machine, and then run the automated test on the test machine, but from a terminal services client window on the Main machine. Now the cool part: you can minimize that TSC window, or even lock the Main machine (or let the screensaver kick in), and that virtual session will continue working, thinking that it is still active - it's just that nobody is paying it any attention. This is one way to create a "connected" session with an active desktop, but one that no-one can interfere with, because it's protected behind the locked desktop of the Main machine.
I don't know the details, but I believe the lock screen constitutes a separate "desktop" and maybe also a separate "window station" (as I understand it a window station is merely a container for desktops). The MSDN section on window stations should hopefully be useful: http://msdn.microsoft.com/en-us/library/windows/desktop/ms687098%28v=vs.85%29.aspx
In order to access a desktop, you will need to use the regular windows api's from a thread that is on that desktop. SetThreadDesktop would probably be the easiest way to do that in C, as long as the desktop isn't on a different window station.
Unfortunately, this is already difficult for a regular privileged application, and using AutoHotkey complicates it even more. Since you don't have control over threads or over process initialization, you will probably have to create a new process in the other desktop (you can do this using the CreateProcess API, which appears to have a wrapper available for AHK to which you can supply a desktop name: http://www.autohotkey.com/forum/topic1952.html). Your process will need special privileges to do this; I'm not sure that even running as Administrator is enough.
What does it mean by multiple monitor support for an application?
In the old days computers only ever had a single screen attached. Now they often have more than one attached and a desktop that spans those screens.
You need to make sure that your app:
Maximises to the monitor that it is most closely associated. A badly written app might always maximise a window to the primary monitor.
Remember which monitor it was displayed on when last run, and restore to that monitor when it starts up again.
Avoid displaying on a monitor that is no longer available. For example, consider a laptop with an attached screen. If you show the window at coordinates for a screen that has been disconnected (e.g. laptop user on the move) then they won't be able to see it.
It all depends on the application.
For some applications it just means that that you could open a very big window.
For others it might mean that you could open two windows, one for each monitor. For example, Lightroom, lets you view a collection of thumbnails on one window and a full-sized image on the other.
We have a Linux based system that does not use a Window manager. When we start certain applications (for instance Firefox) from a terminal window (e.g. Firefox &) we find that no matter what we do, we can't get the application to display full screen.
If we run xrandr, it shows the default resolution is 1280x1024, but when we try to maximize Firefox (by pressing F11) the application is only sized to 1203x650.
Another application that seems to have the same problem is the evince PDF reader.
Our application is not configured to run a window manager (and we don't want to add one), so I'm wondering if there is something else that we can do to get these applications to render full screen.
Thanks...
Although you don't want to use a window manager, you might need to use a window manager.
I haven't dug into the X server sources around this, so I can't definitively say X requires a window manager to run properly. But as somebody who writes X client code, and hacks the X server, on minimalist embedded devices with small screens, low CPU power and no GPU... let's just say, all the major players in that space use one, and have good reasons for it.
If you want to avoid chewing up a lot of disk space, RAM or CPU power doing window management, you should check out matchbox. It's a low-footprint window manager designed to meet those criteria, and it's what many folks in that minimalist embedded space are using. My employer uses it on cell phones, configured so that only one app at a time is visible to the user, and the foreground app takes up the whole screen with no window borders. But you can use it other ways, too - Nokia uses it for their Maemo-based network tablets.
You could use xwit(1) to forcibly resize and place the windows. But as as far as I know, X11 in itself does not have the concept of a "maximized" window; the very idea is only added by most window managers and/or applications (like Firefox).
Does passing the "-geometry=1280x1024+0+0" option to Firefox help?
Oh, also... if you don't explicitly set a window manager, you might be unexpectedly falling back to the default X11 window manager. If you're not absolutely positive there's no window manager, you should check into this possibility.