ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) (12/28/90)
From my brief looks at two pre-release versions, the MPW 3.2 Shell seems to have some nice new features--in its handling of markers, and other areas. The ability to split a window into multiple panes is nice, but I think it could be made nicer: there's no need for every pane to have its own set of scroll bars. All you've done is given the Mac "tiled" windows, a la Microsoft Windows 1.0x! I think it would actually be more useful to lock each row and column of panes so that they scrolled in unison, governed by a single scroll bar. This needn't be made an option: if you really wanted to view completely independent parts of the same text file, you could handle that by allowing the opening of multiple windows on the one file. Sound familiar? It's the way Excel handles its worksheet windows. It's one of the few things Microsoft got right, and I think it's worth emulating. Uhh, they don't have a copyright or a patent on it--do they...? Lawrence D'Oliveiro fone: +64-71-562-889 Computer Services Dept fax: +64-71-384-066 University of Waikato electric mail: ldo@waikato.ac.nz Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00
Lawrence.DOliveiro@f20.n226.z1.FIDONET.ORG (Lawrence DOliveiro) (12/28/90)
Reply-To: ldo@waikato.ac.nz
From my brief looks at two pre-release versions, the MPW 3.2 Shell
seems to have some nice new features--in its handling of markers,
and other areas.
The ability to split a window into multiple panes is nice, but I
think it could be made nicer: there's no need for every pane to
have its own set of scroll bars. All you've done is given the
Mac "tiled" windows, a la Microsoft Windows 1.0x! I think it
would actually be more useful to lock each row and column of panes
so that they scrolled in unison, governed by a single scroll
bar. This needn't be made an option: if you really wanted
to view completely independent parts of the same text file, you
could handle that by allowing the opening of multiple windows
on the one file.
Sound familiar? It's the way Excel handles its worksheet windows.
It's one of the few things Microsoft got right, and I think it's
worth emulating.
Uhh, they don't have a copyright or a patent on it--do they...?
Lawrence D'Oliveiro fone: +64-71-562-889
Computer Services Dept fax: +64-71-384-066
University of Waikato electric mail: ldo@waikato.ac.nz
Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00
+ Organization: University of Waikato, Hamilton, New Zealand
--
Lawrence DOliveiro - via FidoNet node 1:105/14
UUCP: ...!{uunet!glacier, ..reed.bitnet}!busker!226!20!Lawrence.DOliveiro
INTERNET: Lawrence.DOliveiro@f20.n226.z1.FIDONET.ORGleonardr@svc.portal.com (Leonard Rosenthol) (12/29/90)
In article <2577.277bac4f@waikato.ac.nz>, ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: > From my brief looks at two pre-release versions, the MPW 3.2 Shell > seems to have some nice new features--in its handling of markers, > and other areas. > > The ability to split a window into multiple panes is nice, but I > think it could be made nicer: there's no need for every pane to > have its own set of scroll bars. All you've done is given the > Mac "tiled" windows, a la Microsoft Windows 1.0x! I think it > would actually be more useful to lock each row and column of panes > so that they scrolled in unison, governed by a single scroll > bar. This needn't be made an option: if you really wanted > to view completely independent parts of the same text file, you > could handle that by allowing the opening of multiple windows > on the one file. > YUCH! I've been using the MPW 3.2 shell since the first Q release on ETO #1, and I make frequent use of the split window. My usage is exactly in line with the implementation that Apple has chosen - the ability to be looking at two (or more) different parts of a source file at the same time. This is quite useful for things such as viewing the initialization and the disposal parts of a subroutine at the same time to make sure you are disposing of everything you allocated (for example). It has also come in handy for copying sections of code from one place to another w/o having to continually jump around with marks. I do not argue the 'sync scrolling' is a useful feature, but I have yet to find a time where I really wanted it - and those few times were where I wanted TWO DIFFERENT files to be synced! All I have to say is a big THANKS to the MPW team!! Leonard Rosenthol -- ---------------------------------------------------------------------- + Leonard Rosenthol | Internet: leonardr@sv.portal.com + + Software Ventures | GEnie: MACgician + + MicroPhone II Development Team | AOL: MACgician1 + ----------------------------------------------------------------------
beard@ux5.lbl.gov (Patrick C Beard) (12/29/90)
To continue the thread of MPW 3.2 wishes, here are a few: C/C++ Compilers: up the limit of the number of directories allowed in the #include search list. 15 isn't enough when you are working on a project with lots of libraries and #includes in different directories. How abou 100? Standard I/O: have MPW shell act a lot more like a Unix shell by letting tools do character at a time i/o. This would make interactive tools a lot easier to write. Once in a while this is what you want. Linker: Stupid link mode, where you WOULDN'T strip code that isn't used to speed up the links. Overall, I like the environment, but these additions/modifications would make my life easier. -- ------------------------------------------------------------------------------- - Patrick Beard, Macintosh Programmer (beard@lbl.gov) - - Berkeley Systems, Inc. ".......<dead air>.......Good day!" - Paul Harvey - -------------------------------------------------------------------------------
eastman@csa2.lbl.gov (JACK EASTMAN) (01/03/91)
In article <8797@dog.ee.lbl.gov>, beard@ux5.lbl.gov (Patrick C Beard) writes... > >To continue the thread of MPW 3.2 wishes, here are a few: > >C/C++ Compilers: up the limit of the number of directories allowed in the >#include search list. 15 isn't enough when you are working on a project with >lots of libraries and #includes in different directories. How abou 100? > Let me echo and stress this point. Code in large software projects is more maintainable if it's divided among source directories and organized by function. The 15-directory search path limit puts a severe strain on our ability to organize source code directories and libraries the way we want. Please, please, can we have more? Jack Eastman Berkeley Systems, Inc. eastman@lbl.gov
ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) (01/05/91)
In <1990Dec28.174935.23515@svc.portal.com>, leonardr@svc.portal.com (Leonard Rosenthol) comments on my suggestions on the handling of windows in the MPW Shell as follows: "YUCH! I've been using the MPW 3.2 shell since the first Q release on ETO #1, and I make frequent use of the split window. My usage is exactly in line with the implementation that Apple has chosen - the ability to be looking at two (or more) different parts of a source file at the same time... "I do not argue the 'sync scrolling' is a useful feature, but I have yet to find a time where I really wanted it - and those few times were where I wanted TWO DIFFERENT files to be synced!" I think that, if you're viewing two (or more) completely independent parts of the same file, you're better off having multiple windows open. The Shell should support this by having a "New Window" function in its "Windows" menu, which would create a new window showing the same file as is being displayed in the currently-active window. Why do I think so? Because multiple windows can be arranged in a much more flexible fashion that multiple panes in the same window. As for syncing two different files, the 3.2 Shell already partially supports that. The new built-in command "ShowSelection" lets you, among other things, scroll the view in window so the specified line is at the top. You could use this from a script, together with the output from "Compare", to browse through two files, showing the differences side-by-side. I can't see that it would be very useful to have the ability to "lock" the scrolling in two windows, showing *different* files, to each other, so that they always showed the same line numbers. The contents of those lines aren't likely to correspond in any meaningful fashion, so what's the use? But what *would* be nice is to extend the control of panes from scripts, and to give access to that, and the ShowSelection functionality, to tools. Oh, I forgot to mention that the ability to extend the selection using shift with the cursor keys is *very* welcome (as well as being long overdue). There still seem to be a few limitations, at least in the 3.2b8 version of the Shell: extending the selection downwards doesn't autoscroll the window, and using shift with command left- or right-arrows (to jump to the beginning of the end of the line) doesn't extend the selection: it just seems to ignore the shift key. Finally, the new Shell seems distinctly slower entering text: I hope this will be fixed in the release version. Apart from that, I agree with Leonard: overall, the new Shell is a significant improvement! Lawrence D'Oliveiro fone: +64-71-562-889 Computer Services Dept fax: +64-71-384-066 University of Waikato electric mail: ldo@waikato.ac.nz Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00
laird@chinet.chi.il.us (Laird J. Heal) (01/06/91)
In article <8797@dog.ee.lbl.gov>, beard@ux5.lbl.gov (Patrick C Beard) writes: >To continue the thread of MPW 3.2 wishes, here are a few: >Standard I/O: have MPW shell act a lot more like a Unix shell by letting tools >do character at a time i/o. This would make interactive tools a lot easier >to write. Once in a while this is what you want. This is not possible with how MPW tools operate. That is, only one tool is ever executed at once, and the shell is quiescent during tool operation. This is probably due to the Macintosh Stack operation. Because the return address of routines is pushed onto the stack, when a routine that would be run out of order would return, the stack containing everything run after the interrupted routine would be popped and everything there would be lost. It would be possible during a context-switch to copy the stack relevant to the active routine and restore the stack pertaining to the activating one. It would also be possible to maintain separate stacks for each MPW tool, but this would be more wasteful because of the need to have a slop area for each process and more difficult because of the intrinsic nature of the ROM routines. No provision was ever made for dynamic resizing of stacks under the Macintosh OS (no need to discuss: where's my MMU?) and it truly is the best decision to run only one MPW tool at a time. I have given some thought to what it would take to run some kind of sh as a Macintosh application. Considering the need to run in 1024K or 512K or even less under MultiFinder, you would want to be prepared to copy memory to disk with feckless abandon, and while it is intellectually stimulating to consider, it would probably be an exercise in futility to implement. -- Laird J. Heal The Usenet is dead! Here: laird@chinet.chi.il.us Long Live the Usenet!
sw@nan.co.uk (Sak Wathanasin) (01/07/91)
In article <2614.278613ee@waikato.ac.nz>, ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: > As for syncing two different files, the 3.2 Shell already partially supports > that. The new built-in command "ShowSelection" lets you, among other things, > scroll the view in window so the specified line is at the top. You could > use this from a script, together with the output from "Compare", to > browse through two files, showing the differences side-by-side. There's already a script to do this called "CompareFiles" in the std MPW distribution, and very useful it is too. I rather like the new windows, but I wish that they had left the status panel where it was. It now takes up a whole line in the window. Or if they are going to leave it there, how about echoing the entire shell cmd-line instead of just the first word? Also, has anyone noticed that the "read-only" check box in the open file dialogue is now "sticky"? Having set it once, it stays set unless you turn it off; this is the case whether you use the command line or the file menu to open subsequent files. "Open -r" however works the way it used to in MPW 3.1. I like the mark browser too, and the alphabetic attribute in the "mark" menu. But it would be nice if this attribute lived with each file instead of being a global property. And while I'm on the soapbox, there's a problem with the 3.2b9 shell that was in the ETO #2 CD. It doesn't seem to like tags (the option-R meta-char) in selection expressions. Gives an error "Illegal @ expression" (read @ as option-R) whenever I try it. > Apart from that, I agree with Leonard: overall, the new Shell is > a significant improvement! Yes, well done. --- Sak Wathanasin Network Analysis Limited uucp: ...!ukc!nan!sw other: sw@network-analysis-ltd.co.uk phone: (+44) 203 419996 snail: 178 Wainbody Ave South, Coventry CV3 6BX, UK
Greg@AppleLink.apple.com (Greg Marriott) (01/07/91)
In article <0101000D.dgilq1@nan.co.uk> sw@nan.co.uk (Sak Wathanasin) writes: > Also, has anyone noticed that the "read-only" check box in the open file > dialogue is now "sticky"? Having set it once, it stays set unless you > turn it off; This makes it easier for those using standard file to open a lot of things read only without clicking the box each time. The bad part of this is they provided no way to "turn it off" in a script. I find this really annoying, since I have many scripts which open a window read only and I'd rather not have the state of the box in standard file affected by these scripts (i.e. be able to leave it the way it was). I'd rather give up the new "stickiness" and get the scriptability back. Greg Marriott Blue Meanie Apple Computer, Inc.
Chris.Gehlker@p12.f56.n114.z1.fidonet.org (Chris Gehlker) (01/07/91)
LDW> I think that, if you're viewing two (or more) completely independent
LDW> parts of the same file, you're better off having multiple windows
LDW> open. The Shell should support this by having a "New Window"
LDW> function in its "Windows" menu, which would create a new window
LDW> showing the same file as is being displayed in the currently-active
LDW> window. Why do I think so? Because multiple windows can be arranged
LDW> in a much more flexible fashion that multiple panes in the same
LDW> window
I dunno Lawrence. When I have multiple panes it's typically because I have
a pane open to an area where I'm writing code and a pane to an area where I'm
#defining constants or whatever. But I want both areas to be either that current
worksheet or the target. Seems to me that multiple windows would just make
things hard to arrange.
--
Uucp: ...{gatech,ames,rutgers}!ncar!asuvax!stjhmc!56.12!Chris.Gehlker
Internet: Chris.Gehlker@p12.f56.n114.z1.fidonet.orgpeirce@outpost.UUCP (Michael Peirce) (01/08/91)
My pet peeve is that there is no way to page left or right from the keyboard. Often I'm browsing some source code using the keyboard and the code extends off the right side of the windows. Something like command-right-arrow and command-left-arrow to page horizontally would be very helpful. Did they address this in 3.2? -- michael -- Michael Peirce -- outpost!peirce@claris.com -- Peirce Software -- Suite 301, 719 Hibiscus Place -- Macintosh Programming -- San Jose, California 95117 -- & Consulting -- (408) 244-6554, AppleLink: PEIRCE
anders@verity.com (Anders Wallgren) (01/09/91)
In article <0B010004.4702a1@outpost.UUCP>, peirce@outpost (Michael Peirce) writes: > >My pet peeve is that there is no way to page left or right from the >keyboard. > >Often I'm browsing some source code using the keyboard and the code >extends off the right side of the windows. Something like command-right-arrow >and command-left-arrow to page horizontally would be very helpful. > >Did they address this in 3.2? > >-- michael Yes. It also follows you as you type along, which is nice. anders