On Wed, Nov 23, at 6:11 AM, Jack Baty wrote:
On 11/23/05, Kevin Ballard kevin@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