Avdi,

I wrote a series of articles on th etopic back in 2009: you can find the first article here: https://joachimtuchel.wordpress.com/2009/07/02/whats-in-a-smalltalk-browser-anyway-part-1/

Back then, I tried to share my thoughts on what I think A Smalltalk IDE should look like these days (well, those days ;-) ). I've seen some of the ideas presented and taken further at ESUG/IWST talks over the years, some of which I really liked, but - as far as I can tell - none of these projects went anywhere. None of the commercial vendors made any attempts to work on window clutter or streamlining their IDEs. Smalltalk Browsers are still the same as they were in 1981, all that's been added is a little bit of colourful button bars here and there and tabbing (most implementations even managed to get that wrong).

I think the conclusion I came to was that a Smalltalk IDE has two main tasks: navgating code and editing code
Actually three: debugging which adds some stuff on top of the other two.

I think we all can agree on that Smalltalk's editing facilities mostly sucked for decades. The lame excuse was that real Smalltalkers write methods of no more than 6 lines. Fortnunately, we seem to have accepted that either the assumption about real Smalltalkers was wrong or that even 6 lines of code are worth syntax highlighting, code completion and all kinds of assistance for the developer.

I also think that navigating code is extremely important. The fact that each browser comes with its own navigation area that takes up about 50 percent of the real estate of the browser, however, is just plain wrong.
��
We are missing clever navigation facilities in Smalltalk. I think the GT Tools are a great start in improving things and they are much better than anything we have had for 40 years now, but it is just a step on a long stairway. Other Smalltalk implementations literally have nothing in this area that wasn't there in the 80ies.

On the other hand, what Smalltalk has offered for code navigation and retrieval in the 80ies, was about 25-30 years ahead of the mainstream. So I am not saying Smalltalk's environment is bad per se. It could just be a lot better if more research or experimentation was done in the area. The GT tools show that it is worth it and can boost Smalltalk developers' productivity a lot.

Joachim


Am 19.05.15 um 01:08 schrieb Avdi Grimm:

On Sat, May 16, 2015 at 4:23 PM, jtuchel@objektfabrik.de <jtuchel@objektfabrik.de> wrote:
I mostly work in other Smalltalk environments than Pharo, like VA Smalltalk. It has native windows and so the ability to switch between windows using alt-tab is there. I must admit that there is a certain threshold in the number of open windows when this is not really helpful any more. I tend to hit that number pretty fast in a typical Smalltalk coding/debugging sessions.

Things have changed in Win 7, because there I can use the window manager to close the windows right in the window switcher. That makes perfect sense if you have 15 inspectors open, none of which shows current data or instances any more. Or if one of them does, I can't decide which one ;-)

So sometimes I wish for features like "close all windows of this kind" to kill all inspectors, for example.

What I want to say with this that I am not really using alt-tab to switch between windows, but rather to kill a few to come down to a sensible number ;-) But I understand why you miss it. For Pharo, there is a special problem: it is its own windowing environment, so it should probably better not use the O/S' key combination to switch its windows, right?

Just as some food for thought for anyone contemplating this problem:

Sometimes problems like this are indicative of deeper usability issues. Decades ago, it was just sort of assumed that the "right" way to deal with windows was to have a dedicated window for every "thing" in your system. To some degree, Mac OS, Wind95, and OS/2 all took this point of view. For instance, every folder you double-clicked on would open up a new file manager window, and this got to be such a mess that some OSes included "secret" shortcuts for killing them all at once.

Then the web started to take off, 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.

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. 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.

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.

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.

--
Avdi Grimm
http://avdi.org



-- 
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel          mailto:jtuchel@objektfabrik.de
Fliederweg 1�� �� �� �� �� �� �� �� �� �� �� �� ��http://www.objektfabrik.de
D-71640 Ludwigsburg                  http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0�� �� �� �� ��Fax: +49 7141 56 10 86 1