On 19-05-15 01:08, Avdi Grimm wrote:
Then the web started to take off,
throwing UI design back two decades ;),
and UX designers started rethinking the whole paradigm. They started keeping things in the same window, but adding back/forward buttons, and navigation histories, and sidebars, and address bars, and tabs, and other affordances to make it easier to switch between "things" without necessarily adding more windows.
We found that what works well for browsing and reading text not necessarily works for code. I regularly have 80 tabs open in 10 windows of more or less interesting stuff to read. Having a lot of edited buffers open at the same time is a problem, if only because "save all" might run into dependency issues. The current design stimulates working in short cycles, and keeping code well-organized. I'd like not to lose that aspect of the UI. And I also like a navigation history.
These days, most IDEs and editors have followed suit. I can't think of a single editor in common use among the programmers I know which encourages multiple windows.
Which seems like a mistake, as displays keep growing in size and the IDEs and editors in common use have no way to use the space a 4K display offers.
Whether it's Vim, Emacs, Sublime, IntelliJ, while you *can* open lots of windows if you really want to, they all focus on making it easy to manage lots of buffers in a single window rather than encouraging lots of windows.
That actually sounds like a really bad idea when you have a large display. I want to see all relevant code at the same time. Switching is slow.
Personally, I'm a fan of this trend. I'm much happier typing a few characters to auto-complete the buffer I want to return to in Emacs, than I am hunting around in an OS window list for it.
I would welcome an auto-complete based navigation to one of my open windows.
This is all a long-winded way of saying: just because this is currently a problem, doesn't mean it's the *right* problem. It would be interesting to see what a "fewer windows" approach to Smalltalk development might look like.
A simple first step is Hopscotch. https://youtu.be/d6tj6KQtD1s On a small-screen device like an iPad I like the approach taken by Cel: http://cel.inf.usi.ch/ And have you seen Gaucho? http://www.inf.usi.ch/faculty/lanza/Downloads/Oliv2013a.pdf Stephan