[TxMt] Ditch the drawer

[Gerd Knops]

On Wed, Nov 23, at 6:11 AM, Jack Baty wrote:

> On 11/23/05, Kevin Ballard <kevin at sb.org> wrote:
>> I'm not sure how ditching the drawer would give you more space, which
>> is what you seem to be indicating you need.
>
> I think it depends on how one relates a window to a workspace. I tend
> to think of each window as my entire workspace. When I need to see the
> project tree, I'd prefer that it was displayed "inside" the current
> window. Also, on a smaller monitor, the document window can easily
> fill the entire screen. In this case, when the drawer is opened, the
> document window size is reduced to make room. Then, when closing the
> drawer, it stays the reduced size, requiring a manual resize. Other
> than that, for me, (on a 20" iMac) it's simply a "feel" thing.

The way I see it a window should maximize the information visible  
while at the same time use as little space as possible. For a  
programmers editor that usually means I want my windows about 80 + a  
few columns wide, and fairly tall to see as many lines of code as  
possible. (Side note: this is why the Tabs actually bug me, they use  
up valuable vertical space but with more than a few files open become  
pretty useless). A window size like that allows me to see most of a  
second window containing some reference info (depending on screen  
size obviously).

We need to distinguish between 2 basic usage patterns:

1) I do NOT need the projects file browser most of the time, (eg I  
use the "go to File.." dialog most of the time).

Here the drawer is a good idea. Would the tree be in the window, I  
would have to resize the window to see the browser and my 80 columns  
of code. And when I hide the browser, I would have to resize the  
window again.

The concept of the drawer fits this usage pattern well: Information  
that is only needed part of the time, but still relates to that  
window only, is contained in 'appendages' to the window (versus  
'Inspector panels' of yesteryear that do not relate to the window as  
well).

One of the problems with drawers is that Apple did not think this all  
the way through. Let me give an example:

- I am on my iBook with it's small screen.
- Temporarily I need to see 'more', so I maximize the window.
- I need to see the drawer and bring it up. The window resizes to  
make room for the drawer, great.

But now it goes wrong:

- Hiding the drawer does not resize the window back to it's previous  
(full screen) size.
- The 'original' dimensions of the window are lost, and replaced with  
the 'maximized minus drawer size' dimensions, so clicking the  
maximize button now toggles between that size and the full size.

I think if bringing up the drawer automatically resizes the window,  
closing the drawer should restore the previous window size. The  
'manually resized' dimensions should almos never be overwritten by  
something the system does.


2) The project or the way I prefer to work makes it more convenient  
to see the file browser all of the time.

For this usage pattern the browser being integral part of the window  
makes more sense. It is information always required, so it should be  
part of the window rather than some appendage.


Clearly the problem here is that the requirements of these 2 usage  
patterns somewhat oppose each other. And which to pick depends on  
both project type and personal preference. I could even see myself  
using both types simultaneous, depending on project type.

So ideally TextMate would offer both, an it should be rather a  
project setting than a global preference. I think only that would  
appease all users. And there is sort of a preference with Xcode  
Layout preference (none of which I think are really useable though).

BTW there is a third usage pattern, and that is folks that want their  
applications to use up the entire screen. Kind of defeats the  
windowing system altogether though, and requires things like split  
views etc. However it is a more structured setup and avoids the chaos  
of multiple overlapping windows, which are very distracting for some  
users. Applications with a fairly narrow goal, like Mail and iPhoto,  
are suited for such an approach. An al-encompassing IDE might be as  
well. However a Text Editor like TextMate that leverages the power of  
other applications and may require various different views  
simultaneous (eg editor window, build window, preview, documentation,  
reference material) is in my opinion NOT suited for that.

Gerd