Description harrisn 2004-12-10 10:19:02 EST

I understand the topic is controversial. UI's always are, generally because 
humanity is multimodal in its genetic predispositions. Even the preferred way 
to provide directions for travelling is known to be split in a nearly even 
bimodal fashion. This is related. It is also a severe problem for me (and, 
presumably for others with a spatial/map rather than sequential/landmark style 
of providing and following directions). It is so severe that once my working 
set reaches 8 or 9 classes, my productivity drops by about 20%. It's so bad 
that I'm willing to offer 125 US$ or 100 Eu out of my own pocket to the 
developer for an Eclipse update with a fix or even to the first person 
describing (in detail for a novice) how to get the old behavior back into my 
3.0.1 (build 200409161125) environment. If you want to e-mail me first to ask 
if you'd be first, please do. I've never done this, but it illustrates how much 
this is not a minor complaint about a UI, but a real, serious, major 
productivity loss for me in moving from Eclipse 2 to Eclipse 3.

The problem area is how to present the set of currently active ("open") files, 
whether changed or not. For some people, this represents the working set of 
classes involved in a single functional task, often a large functional task 
involving up to a dozen classes (because of the need to modify affected 
subclasses when an interface changes).

The release 2 handling of the presentation was a set of "tabs" above the text 
window. The tab width shrank as the number of open files increased and when it 
reached a limit, the screen area presenting the tabs became a sliding 
horizontal window over a large virtual space of such tabs. For me, with a big 
sceen, that's around 9 or 10 files. I know it's not a great solution but for 
spatial people it had the cardinally important characteristics that a file's 
tab was always in the same "place" in the (virtual) space of tabs. One 
consequence was that the order of presentation was always the same. Another is 
that you knew where on your "desk" the file was.

The release 3 handling of tabs loses these characteristics. Instead, when the 
tab size reaches the limit, the screen area presents a changing collection of 
tabs and offers an icon by which one can look at a menu of the open files. I 
won't explicitly criticize the characteristics of this approach which, I am 
sure, appeals more to the temporal/directions people. But I will note that the 
constancy and the ability to work spatially have gone away.

Of course some see this as an improvement. And if it had been provided as a 
matter of choice it probably would have been an improvement. But for me, and 
probably others of us who use maps and work spatially on a large screen, it is 
an utter disaster. Really. Once I see that little ">>" icon, I'm dead. I wish I 
could even say what I do instead, but I don't have a way of working around it. 
Sometimes I spend a while trying to decide which of the classes I'm working on 
could be closed so that I forget what they are and have to rediscover it later. 
Sometimes I do that but keep a text file of their names (and if you think 
that's like the ">>" menue - it is, except it doesn't cause random shuffles of 
the placement of new files that come into my working space). Sometimes I just 
close all the files and start over. And sometimes I think about trying to find 
a fix - hence previous e-mails to various people and this new (actually old) 
feature request.

So please let me know if you know a solution or please find a way to bring back 
the spatial orientation. It's serious and I'm serious abouty my offer. Thanks.