I’m curious if those who do are using single monitors or low resolution?
I use a single monitor.
Why use virtual desktops versus a single desktop? Because I generally want to have a fullscreen window making use of all of the pixels on my monitor. I don’t have a visible taskbar unless I have the Super key down. I don’t have anything onscreen other than the application that I’m using.
Why use virtual desktops versus some sort of huge monitor? You have a relatively-small portion of your visual arc that you can actually read — even on a small monitor. A laptop at a reasonable distance already covers that. I did, at one point, use a netbook as a bit of a challenge. I stuck that on a stand near my face, used an external keyboard. It took up more of my visual arc than did a typical very large monitor.
Why use virtual desktops versus multiple physical monitors?
If your workflow needs a multiple physical monitors, you’re limited when you can’t lug those around (or at least, you’re required to lug around a lot more physical hardware). I can pop open a laptop wherever and work as readily as if I’m at my desktop. Same sort of issue applies with a very large monitor.
For the same reason, I do everything possible to keep my workflow in the terminal. Using graphical systems remotely over anything but the fastest, lowest-latency networks is disappointing. But because my workflow is heavily terminal-based, I can use a system remotely about as comfortably as if I’m sitting in front of it.
I think that a lot of problem that people using multiple physical monitors are trying to work around is software using screen space inefficiently, putting stuff like toolbars, panes and tabs onscreen where people aren’t actually using the information, because their software isn’t using that screen space efficiently or don’t have functionality to efficiently switch. Like, let’s say that you have Visual Studio open. grabs a random screenshot off GitHub
Ignore the red outlines. Like, you’re looking at the actual core stuff there through a little tiny portal there. Most of the stuff onscreen there is material that isn’t being used, just tying up pixels.
I don’t have “tabs” in emacs. I can have a hundred buffers open, and it doesn’t use up more screen space. Every “tab” is eating up pixels without providing much utility. Yeah, I have software packages in emacs to rapidly switch to other files in a project — but they don’t consume screen space other than when I’m actually actively using them. I don’t have a toolbar showing a bunch of buttons that I’m not clicking on. I don’t have a list of open (and maybe closed) files always onscreen. I don’t even have a menubar.
I can switch virtual desktops more-quickly than I can move my eyes and recenter on a different desktop, though that’s really a secondary issue.
I suppose that it’s cheaper and more power-efficient, but that’s not really my main concern.
EDIT: Note that I’m not specifically trying to beat up on Visual Studio. It may be that in 2025, there’s some way to strip down what screen space it uses — I haven’t used it for many moons, so I’m long out of date on it. Just using it as an example of a software package that I often see screenshots of with a lot of “mostly-dead space” consumed onscreen.
I use a single monitor.
Why use virtual desktops versus a single desktop? Because I generally want to have a fullscreen window making use of all of the pixels on my monitor. I don’t have a visible taskbar unless I have the Super key down. I don’t have anything onscreen other than the application that I’m using.
Why use virtual desktops versus some sort of huge monitor? You have a relatively-small portion of your visual arc that you can actually read — even on a small monitor. A laptop at a reasonable distance already covers that. I did, at one point, use a netbook as a bit of a challenge. I stuck that on a stand near my face, used an external keyboard. It took up more of my visual arc than did a typical very large monitor.
Why use virtual desktops versus multiple physical monitors?
If your workflow needs a multiple physical monitors, you’re limited when you can’t lug those around (or at least, you’re required to lug around a lot more physical hardware). I can pop open a laptop wherever and work as readily as if I’m at my desktop. Same sort of issue applies with a very large monitor.
For the same reason, I do everything possible to keep my workflow in the terminal. Using graphical systems remotely over anything but the fastest, lowest-latency networks is disappointing. But because my workflow is heavily terminal-based, I can use a system remotely about as comfortably as if I’m sitting in front of it.
I think that a lot of problem that people using multiple physical monitors are trying to work around is software using screen space inefficiently, putting stuff like toolbars, panes and tabs onscreen where people aren’t actually using the information, because their software isn’t using that screen space efficiently or don’t have functionality to efficiently switch. Like, let’s say that you have Visual Studio open. grabs a random screenshot off GitHub
Ignore the red outlines. Like, you’re looking at the actual core stuff there through a little tiny portal there. Most of the stuff onscreen there is material that isn’t being used, just tying up pixels.
I don’t have “tabs” in emacs. I can have a hundred buffers open, and it doesn’t use up more screen space. Every “tab” is eating up pixels without providing much utility. Yeah, I have software packages in emacs to rapidly switch to other files in a project — but they don’t consume screen space other than when I’m actually actively using them. I don’t have a toolbar showing a bunch of buttons that I’m not clicking on. I don’t have a list of open (and maybe closed) files always onscreen. I don’t even have a menubar.
I can switch virtual desktops more-quickly than I can move my eyes and recenter on a different desktop, though that’s really a secondary issue.
I suppose that it’s cheaper and more power-efficient, but that’s not really my main concern.
EDIT: Note that I’m not specifically trying to beat up on Visual Studio. It may be that in 2025, there’s some way to strip down what screen space it uses — I haven’t used it for many moons, so I’m long out of date on it. Just using it as an example of a software package that I often see screenshots of with a lot of “mostly-dead space” consumed onscreen.