== How I use virtual screens in my desktop environment Like many people, I use [[a (Unix) desktop environment MyDesktopTour]] that supports what gets called 'virtual screens' or 'virtual desktops' ([[my window manager ../unix/FvwmConstructionKit]] actually has both). One common approach for using them is to dedicate particular virtual screens to particular programs or groups of programs based on your purpose ([[this goes especially well with full screen apps https://twitter.com/Twirrim/status/608036253825695744]]). You might have one virtual screen more or less devoted to your mail client, one to your editor or IDE, one to status monitoring of your systems, and so on. (If you have multiple displays or a big enough display that filling all of it with eg your mail client is absurd, you might reserve the remaining space on your mail desktop as 'overflow' space for browser windows or whatever that you need in the course of dealing with your mail.) This is not how I've wound up using my virtual screens, at least most of the time. Instead (as you can tell from the nearly empty additional virtual screens on [[my desktop MyDesktopTour]]) I use them primarily as overflow space. Almost all of the time I'm using what I consider my primary virtual screen (the top left one) and everything goes in it. However, some of the time I'm trying to do too many space-consuming things at once, or I just want a cleaner place to do something (often something big), one without all of the usual clutter on my primary virtual screen. That's when I use my additional virtual screens; I switch to a new one, possibly drag some amount of existing windows over from the primary screen, and go for it. (I'm especially likely to do this if what I want to do is both going to last for a while and take up a bunch of screen space with its window or windows.) My virtual screens are arranged in a 3 wide by 2 deep grid. Since the easiest screens to use are the ones right by the top left primary screen, the virtual screens one down and one over from it are the usual overflow or temporary work targets. However space consuming long lived stuff tends to get put one screen further away (the screen one down *and* one over), because this way I keep the more convenient closer screens free for other stuff. (When we were chasing [[our OmniOS NFS overload problem ../solaris/OmniOSNFSOverloadProblem]], I wound up carpeting this virtual screen with _xterm_s that were constantly running _vmstat_ and so on. I wasn't paying any attention to them until the server locked up, but [[my use of an _xterm_ feature XtermZiconbeep]] meant that I couldn't just iconify them. Anyways, leaving them open made them easier to keep track of and tell apart, partly because [[I'm big on using spatial organization for things ../web/TabsVsWindowsII]].) I've found it quite handy to have [[a mouse binding MyFvwmButtonBindings]] that flips between the current virtual screen and the previous one. That way I can rapidly flip between my primary screen and whatever other virtual screen I'm doing things on. In practice this makes it a lot more convenient to use another virtual screen, because I wind up flipping back to the primary screen for a lot of stuff. (I often flip back even for stuff that I could do on the new virtual screen just because I 'know' that eg I read mail on the primary screen. I justify this as an anti-distraction measure in that the non-primary screen should not be used for things unrelated to its purpose.) I have a small amount of things that are permanently there but I don't interact with or look at regularly. These things get exiled off to the very furthest away virtual screen. Typical occupants of this screen are iconified 'master' Firefox and Chrome windows, used purely to keep the browsers running all the time so I have fast access to new Firefox and Chrome windows. === Sidebar: Me and 'dedicated purpose' virtual screens Although I've never tried to work in the 'dedicated purpose' style of virtual screen usage, I'm pretty sure that I would rapidly get angry at constantly flipping back and forth between eg the mail virtual screen and my working virtual screen. The reality of my computer usage is that I very rarely concentrate on a single thing for a significant time; it's much more common for me to be moving back and forth between any number of activities and fidgets. If I was a developer I could see this changing, and in fact that would probably be a good thing. Then it would be an advantage that I had to go through the effort to change to the mail screen to check my email, because I'd be that much less likely to interrupt my programming to do so.