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, jtuc...@objektfabrik.de
<mailto:jtuc...@objektfabrik.de> <jtuc...@objektfabrik.de
<mailto:jtuc...@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:jtuc...@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
