peirce@claris.com (Michael Peirce) (12/12/89)
One question has been bothering me about System 7. That is, I understand the MultiFinder is always enabled, but what about certain types of applications that really don't seem to make sense with this setup. Most of these application fall into the "dedicated" category. Like point of sale terminals, information kiosks, certain servers, etc... These application really don't want to have users having the ability to switch over to something else. Will there be some way to run a "UniFinder-like" environment? Claris Corp. | Michael R. Peirce -------------+-------------------------------------- | 5201 Patrick Henry Drive MS-C4 | Box 58168 | Santa Clara, CA 95051-8168 | (408) 987-7319 | AppleLink: peirce1 | Internet: peirce@claris.com | uucp: {ames,decwrl,apple,sun}!claris!peirce
mkao@cory.Berkeley.EDU (Mike "Butterball" Kao) (12/13/89)
Speaking of future Apple system software, will Apple ever develop an interface akin to that of the NeXT's or even just X-windows? It would be just SWELL if Mac users could access all of the power of the Unix environment WITHOUT losing trace of their humanity due to the unfriendliness. It seems that NeXT has a pretty effective combination of user-friendliness and sheer POWER!!!! (...got carried away...) -------------------------------------------------------------------------- PLEASE reply via E-MAIL to insure my receipt of any replies. Thank you!!!! FINALLY! A permanent address........................mkao@cory.berkeley.edu ------------------------------Pi Kapp, Gamma------------------------------
dce@smsc.sony.com (David Elliott) (12/14/89)
In article <20626@pasteur.Berkeley.EDU> mkao@cory.Berkeley.EDU.UUCP (Mike "Butterball" Kao) writes: > >Speaking of future Apple system software, will Apple ever develop an >interface akin to that of the NeXT's or even just X-windows? Could you be more specific? What's missing from the Mac interface that's in NeXT or in some X specification (i.e., OpenLook or Motif -- X isn't really an interface specification)? Are you missing applications? Are you missing window management functions? If so, what specifically do you want to see? Apple doesn't supply a lot of things because they aren't an applications company. -- David Elliott dce@smsc.sony.com | ...!{uunet,mips}!sonyusa!dce | (408)944-4073 "As I never read this newsgroup or my email, please send replies via carrier pigeon."
kent@sunfs3.camex.uucp (Kent Borg) (12/16/89)
In article <10734@claris.com> peirce@claris.com (Michael Peirce) writes: >One question has been bothering me about System 7. That is, I understand >the MultiFinder is always enabled, but what about certain types of >applications that really don't seem to make sense with this setup. ... >Will there be some way to run a "UniFinder-like" environment? If you ask Apple, the answer is no. If you want the truth, the answer will be yes. There are just too many situations where some sort of "single user mode" will be needed for Apple to completely lock it out. One of the first and loudest hacks discussed here and elsewhere will be how to get into and use this single tasking mode. Apple themselves will be forced to use the single tasking mode for *some* utility or other and we all will be wondering how we can use it too (for chasing WDEF viruses and the such). I hazard to suggest that there is not a general purpose computer out there which does not have some sort of single tasking mode for diagnostic and maintenance purposes. Realize that what Apple says to developers about MultiFinder always being there is really going to be true. My Mom won't have any notion on how or why she might use a single tasking mode. Unix machines have single user mode, but no one *runs* them that way, and so it will be with the Macintosh: we hacker types will know to get into single tasking mode, but no one will use it on a regular basis. To many things will be missing to be tolerable. Even your examples of servers and point of sale terminals will often want MultiFinder. Servers these days start serving up more than just AppleShare, and more multitasking will be needed. Point of sale terminals could also easily want multitasking: 7.0 (eventually) is supposed to give us print spooling for all printers. P.O.S. terminals want printers. What about communications? P.O.S. terminals usually talk to something--often made easier by multitasking. Remember, no one buys Macintoshs because we think they are a cheap way to get lots of computing horse power on our desks. We buy Macintoshs for their user interface, and once 7.0 is out, MultiFinder will become more and more important to the user interface. -- Kent Borg lloyd!kent@husc6.harvard.edu or ...!husc6!lloyd!kent H:(617) 776-6899 W:(617)426-3577 "Progress is the root of all evil" -Al Capp (from the musical "Lil' Abner")
bradh@hpwarbe.hp.com (12/21/89)
When is Apple expecting to release system 7.0? I heard March from a friend, but I could be mistaken. Thanks, Brad email: bradh@hpwala.hp.com
dent@unocss..unl.edu (Local Submission) (12/21/89)
kent@sunfs3.camex.uucp (Kent Borg) writes: >Remember, no one buys Macintoshs because we think they are a cheap way >to get lots of computing horse power on our desks. We buy Macintoshs >for their user interface, and once 7.0 is out, MultiFinder will become >more and more important to the user interface. I complained about this a long time ago :-), but now it really hits me: /everyone/ is going to have to put up with the MultiFinder silliness, if they want to go System 7.0. Perhaps I should defend that obvious bias a little bit. First of all, I completely agree that Multitasking is nice stuff, regardless of the flavor (pre-emptive or not). In fact, "way back when", I thought Switcher was about the neatest thing on the Mac at that time. :-) However, the way in which Multitasking has been brought into the interface really worries me. The context-switching between different applications in MultiFinder is really not necessarily obvious all of the time. Sometimes, when you switch between applications (perhaps by accidentally clicking just a few pixels away from that scroll bar :-), your current window becomes inactive, and the title bar changes.. more-or-less. The standard "Apple, File, Edit" menus are nearly always there, and if the application you've just switched into doesn't happen to have any windows up at the time (like Stuffit), a user can easily be lead to believe that he's at the "Finder Layer" of "windows". Some of you may not think this is such a big deal, since it's pretty obvious what happened once you try to do something, but the point is that the frustration and confusion exist. Surely I'm not the only one that this type of thing has happened to? The Mac Interface, which we [nearly? partly?] all love, should /never/ be frustrating for a user, and the user should never have to guess where he "is"; whatever is going on should be obvious merely by looking. I don't yet have my own personal copy of the Apple Human Interface Guidelines book, so I don't know the "exact" specifications of The Macintosh Interface. Instead, I'm reaching blindly for what is "intuitive" (which is, after all, a word that is often used [wrongly] in describing the Mac interface). "Intuitiveness" is not exactly a goal that can really be reached, but nonetheless, it can be strived for. [was that a word? :-)] If nothing else, the Mac interface should be "easy" to use. Confusing the user by constantly changing the menubar is not "easy" in my personal opinion. In article (something_in_the_future), hypothetical_user@wherever says: > > Ok, fine, so you've complained enough already, how about some suggestions? > I'm glad you asked. :-) Quite frankly, it's my opinion that Switcher did a far better job of making context switching obvious, especially if you turned on animation. For those of you who may not have ever seen Switcher, it was a program, around the time of System Software 5.0 (I think? Perhaps even earlier.) that would let you run more than one application at once. You started Switcher up as a normal application, and from there, you launched other applications. You could then switch between them by pressing a key (which you defined), or by using small left and right arrows in the menu bar, where the MultiFinder Blob exists now. Switcher kept each application ignorant of the others; each one had an entire Mac screen to itself. Additionally, you could specify that Switcher "animate" the context switching between applications, which would make the next application's screen scroll in from the left or right (depending on which way through the "loop" you were moving. If this short description doesn't help, you might be able to find a copy of Switcher at Sumex or Simtel... Just be careful when you run it. Don't run it in MultiFinder :-). In fact, it may not even work at all with System 6.0.x. Well the whole point of that was that context-switches were never a mystery. It was always /very/ obvious when you were switching to the next application. MultiFinder did take a few hints from Switcher, and it's descendant, Servant (no, I'm not going to try to explain Servant here :-).. perhaps not enough though? So here's the suggestion: If we /really/ must keep MultiFinder around (it looks like we have no choice), then how about changing the way that windows are "deselected" when another is selected? Right now, they in fact get /brighter/ (i.e., they make themselves /more/ visible when they are /not/ active) when such a change occurs. Does that really make sense? So, how about if instead, a window that is deselected because of MultiFinder is "greyed out", by greying the scrollbars and perhaps titlebar area. This is, if nothing else, consistant with the way menus are handled; menu options that are not relevant at that time are "greyed". Certainly, scroll bars of inactive windows are not "relevent". :-) That's the realistic solution. What I would much rather see is this: (and this has no chance until the "Compact Mac" line is dead, so in other words, it will never happen.) Put the menubar for an application /in/ that application's window, and leave the menubar at the top of the screen for exclusive use by the "Finder". This eliminates a /very/ modal aspect of the MultiFinder interface (where the exact same menus and menu items do /very/ different things at different times, and what they do is not always obvious. (BTW: The ugly MultiFinder Blob in the menubar is not exactly "obvious" :-), often it's very difficult to figure out what it's supposed to be, and the act of clicking on it is pretty lame as well. There is no feedback to the user (like highlighting the thing, which is very easy) to tell him that he /did/ click on it, and once your click has been noted, you go to some application that you may or may not have known was "next" in the loop.) Perhaps the simplest way of doing this is to give each application it's own "virtual screen", similar to Switcher, but put that screen in a window, on the Finder's desktop. This brings up a /lot/ of Interface Design issues, like how do you scroll around in that window; what if the window contains a document window that also has scroll bars; is this too confusing? etc etc. Well, I think I've rambled far enough; I'd be quite interested to see if other people think that MultiFinder is a hack (see also "kludge"), and that there does exist the possibility that something better may be possible, yet still be "Mac-ish". PS: I should have said this earlier, but: Switcher and Servant were both written by Mac God Andy Hertzfield. I only hope I didn't mutilate the spelling of his last name :-). He no longer works for Apple. Go figure. -/ Dave Caplinger /--------------------------------------------------------- Microcomputer Specialist, Campus Computing, Univ. of Nebraska at Omaha mspecial@zeus.unl.edu ...!uunet!unocss!dent MSPECIAL@UNOMA1
mart@csri.toronto.edu (Mart Molle) (12/21/89)
In article <1353@unocss..unl.edu> dent@unocss..unl.edu (Local Submission) writes: >Quite frankly, it's my opinion that Switcher did a far better job of making >context switching obvious, especially if you turned on animation. >[description of switcher and animated context switching deleted] >Well the whole point of that was that context-switches were never a mystery. >It was always /very/ obvious when you were switching to the next application. >MultiFinder did take a few hints from Switcher, and it's descendant, Servant >(no, I'm not going to try to explain Servant here :-).. perhaps not enough >though? So here's the suggestion: If we /really/ must keep MultiFinder >around (it looks like we have no choice), then how about changing the way >that windows are "deselected" when another is selected? >[proposal to "grey out" scroll and/or title bars for inactive windows] > >That's the realistic solution. What I would much rather see is this: (and this >has no chance until the "Compact Mac" line is dead, so in other words, it will >never happen.) Put the menubar for an application /in/ that application's >window, and leave the menubar at the top of the screen for exclusive use by the >"Finder". This eliminates a /very/ modal aspect of the MultiFinder interface >(where the exact same menus and menu items do /very/ different things at >different times, and what they do is not always obvious. > . . . >Perhaps the simplest way of doing this is to give each application it's own >"virtual screen", similar to Switcher, but put that screen in a window, on >the Finder's desktop. This brings up a /lot/ of Interface Design issues, like >how do you scroll around in that window; what if the window contains a >document window that also has scroll bars; is this too confusing? etc etc. Having just upgraded from an "old rom" 512K "fat mac" to a IIci, I have just entered the mysterious world of multifinder. I agree that it is far more confusing than switcher, which was brilliantly obvious. However, I also recognize that that paradym isn't workable for [even?] Mac-style multi-tasking, because you can't see the status window for your background file download while you're doing something else in the foreground... Maybe everybody else on the net has used a "new rom" HFS system for so long that they've forgotten what a nice innovation the little "zoom box" on the right-hand end of the title line of a window is. Why not replace the funny multifinder "blob" on the menubar by a similar "zoom box" where the normal situation for an application in the foreground would be for its window to cover the whole screen, but clicking the "zoom box" would shrink the application's window to a smaller size (may not be possible on a toaster mac), perhaps "greyed" somehow to indicate that it is not part of the forground, or even reduce it to an icon size. I remember finding this "shrink a window into an icon" feature quite handy on a Sun running X windows -- you can even specify that the icon be "active" i.e., that it is a compact version of the contents of the real window instead of just a static bitmap, which was very handy if you were waiting for some event (e.g., output) to happen. Mart L. Molle Computer Systems Research Institute University of Toronto Toronto, Canada M5S 1A4 (416)978-4928 v
gdavis@primate.wisc.edu (Gary Davis) (12/22/89)
From article <589@hpwala.wal.hp.com>, by bradh@hpwarbe.hp.com: > When is Apple expecting to release system 7.0? > The latest from Apple is that it will be in users' hands by summer. Developers will probably get something fairly soon. Some of the promised features will have to wait for a later release (Layout manager, new print architecture, etc). Apple had a nice way of announcing the delay in some features. It went something like this: "Work is progressing well on the Layout Manager and the new print architecture." Gary Davis
stores@unix.SRI.COM (Matt Mora) (12/22/89)
In article <1353@unocss..unl.edu> dent@unocss..unl.edu (Local Submission) writes: >I complained about this a long time ago :-), but now it really hits me: >/everyone/ is going to have to put up with the MultiFinder silliness, if >they want to go System 7.0. I never use multi finder and didn't like the idea of 7.0 running only multifinder. But there is no law that says that you have to launch more that one application at a time. (though multifinder will still be active). [ nice long description deleted] >PS: I should have said this earlier, but: Switcher and Servant were both >written by Mac God Andy Hertzfield. I only hope I didn't mutilate the >spelling of his last name :-). He no longer works for Apple. Go figure. I really liked switcher too. I think multifinder will have an option to hide all other windows that are not active. >-/ Dave Caplinger /--------------------------------------------------------- > Microcomputer Specialist, Campus Computing, Univ. of Nebraska at Omaha > mspecial@zeus.unl.edu ...!uunet!unocss!dent MSPECIAL@UNOMA1 Thats to bad that apple lost Andy. What is he doing now? Is a shame if he's not working with Macs anymore :-( -- ___________________________________________________________ Matthew Mora SRI International stores@unix.sri.com ___________________________________________________________
mf12605@msi-s9 (Marek Behr [Aero Eng]) (12/22/89)
In article <1353@unocss..unl.edu> dent@unocss..unl.edu writes: > >The context-switching between different applications in MultiFinder is really >not necessarily obvious all of the time. Sometimes, when you switch between > > [ Suggestions to make application switching obvious to the user ] > >Well, I think I've rambled far enough; I'd be quite interested to see if >other people think that MultiFinder is a hack (see also "kludge"), and that >there does exist the possibility that something better may be possible, yet >still be "Mac-ish". > Here's another suggestion to make MultiFinder more Switcher-like. Maybe it would be nice to have the menu bar of the application which is going into background slide out one (left or right) end of the screen, while the new application's menu bar follows from the other side. Exactly like Switcher (I think - my memory is not so good) but applied only to the menu bar. I think this would alert the user better that some significant change in his environment took place. Of course Apple would expose itself this way to a lawsuit by inventors of Wall-Street-type stock price displays... | Marek Behr | mf12605@uc.msc.umn.edu (internet) | | University of Minnesota | AE01005@UMNACVX (BITNET) |
jb28+@andrew.cmu.edu (Jeffrey Joseph Barbose) (12/22/89)
I'm not exactly crazy about multifinder's context switching either, but I definitely DON'T like the way Windows handles its menus either. To put them inside each document's window not only takes up extra screen space (a valuable commodity on Compact Macs), but is confusing when there are multiple windows place in certain positions on the screen. What I DO like is Virex's method of doing something like this. It combines the ideas of each-window-gets-its-own-menus, and the hierDA-type ideas: in the upper lefthand corner of the window, below the titlebar, is a dog-ear (much like the Notepad's dogear, but smaller). Clicking on this shows a menu con-\ taining the items of the menubar, along with hierarchical menus at each one containing the menu items. This setup worked very well for me. Anyone else? Jeff
isr@rodan.acs.syr.edu ( ISR group account) (12/22/89)
In article <1353@unocss..unl.edu> dent@unocss..unl.edu (LocalSubmission)writes >That's the realistic solution. What I would much rather see is this: (and thi >has no chance until the "Compact Mac" line is dead, so in other words, it will >never happen.) Put the menubar for an application /in/ that application's >window, and leave the menubar at the top of the screen for exclusive use by the >"Finder". This eliminates a /very/ modal aspect of the MultiFinder interface > Yes! I think it's a great idea. It could be done so it woudn't take up any more room - instead of putting the menu IN the window, replace the Title Bar with a MenuBar, Perhaps in a format such as: AppName File Edit Menu Menu Menu ZoomBox The AppName Menu could be handled not by the App, but by Multifinder itself, and could provide the DA's, About MF, and perhaps a couple new choices which it should provide: Move Backwards,MoveToBack, and Stack. (MoveToFront is of course not needed) Stack would "stack up" the windows so they'd appear the way ResEdit opens things up- nicely lined up so you can see the TitleBar. (MenuBar is this case) The only problem I can think of now with it is small-width windows woudn't provide all the menus, but again, that can be handled by MF, just by providing "scrolling" of the last menu as you go off the edge of the menubar with the button held down. This would give instant id of which program is in front, and with the Stack option, where each program's window was for easy switching. Apple, Do It !!!! -- Mike Schechter, Institute for Sensory Research, Syracuse Univ. InterNet: isr@rodan.syr.edu msschech@rodan.syr.edu Bitnet: SENSORY@SUNRISE
mikek@hpvcfs1.HP.COM (Mike Kirkpatrick) (12/23/89)
>>Speaking of future Apple system software, will Apple ever develop an >>interface akin to that of the NeXT's or even just X-windows? >Could you be more specific? What's missing from the Mac interface >that's in NeXT or in some X specification (i.e., OpenLook or Motif -- X >isn't really an interface specification)? >Are you missing applications? >Are you missing window management functions? >If so, what specifically do you want to see? Apple doesn't supply >a lot of things because they aren't an applications company. How about pipes and i/o redirection for starters. There are some activities that are just better done with a text/command line interface. The power to set in motion a chain of commands. Multi-directory i/o operations(especially disjoint directories) are much easier done with a command line. For example, how would you do this under macOS (send a list of all files under current directory to the spooled printer)? find . -print | lp Also perhaps what he's refering to is the plethora of programs, scripts, and utilities that are available on just about any unix machine. Things like awk, grep, sed, find, etc. that can all be piped together in meaningful ways to do things that currently are very cumbersome on the mac. I don't know anything about AUX and I was wondering if somone could describe how well macOS applications can run under AUX. For example, if I have AUX running, can I run mac applications in their own windows(or in an X window)? Can I view and run applications on remote machines as easily as if they were on my own machine? Then there is the beautifully seamless networking capabilities of unix machines. Unix machines can access many files and run applications on remote machines from any number of X windows all simultaneously. Can macOS or AUX do this? Inquiring minds want to know? no sig file here!
yossie@lakesys.lakesys.com (Peter Thomas) (12/23/89)
Blast from the Past --- Hey, this will probably be old news to some, but there is TRUE multi-tasking on a Mac. Its called MultiMac and it will only run on a 128 or 512 machine. Its a pity, too, 'cause all the people complaining about MultiFinder would probably have been very happy if they had MultiMac! It was an application, just like Switcher, Servent, and MultiFinder. Once run it looks sort of like MultiFinder except that the Multifinder/Switcher ICON is replaced by an Apple. Clicking there pulled down a menu of applications. Now, the nice part was that MultiMac was "true" multi-tasking. I.e. it timesliced! You could assign priorities to each running application and MultiMac would give each his just dues. Window management was like the MultiFinder/Servant veriaty, not the Switcher single screen method. I remember with gr8 fondness doing compilation and download and finder work all at the same time, and I do mean the *SAME* time. I could see packets being registered in Kermit while the compilation was going on and the Finder window kept on showing less space. Mind you, NONE of these application had ANY idea that it was running under MultiMac. I heard say that the way it worked was by jumping directely into ROM for many things. So, it was a hack, but it was a VERY SEXY HACK! - Yossie
Adam.Frix@f200.n226.z1.FIDONET.ORG (Adam Frix) (12/23/89)
Matt Mora writes:
MM> Thats to bad that apple lost Andy. What is he doing now? Is
MM> a shame if he's not working with Macs anymore :-(
There was an article in Newsweek magazine within the last two months that
mentions what Mr. Hertzfeld is involved in. The picture showed him with
his latest invention, a $10,000 TV set that does everything for you. The
article, unfortunately, was not about Mr. Hertzfeld but about the up and
coming technology, for which he (among others) is at the forefront. I
forget just what this technology is, but it's definitely in the "gee-whiz"
realm.
FYI, he still looks like the Andy from Apple. I can appreciate that. :-)
--Adam--
+-- Export 3.0
--
Adam Frix via cmhGate - Net 226 fido<=>uucp gateway Col, OH
UUCP: ...!osu-cis!n8emr!cmhgate!200!Adam.Frix
INET: Adam.Frix@f200.n226.z1.FIDONET.ORGbarmar@Think.COM (12/28/89)
In article <780093@hpvcfs1.HP.COM> mikek@hpvcfs1.HP.COM (Mike Kirkpatrick) writes: >>>Speaking of future Apple system software, will Apple ever develop an >>>interface akin to that of the NeXT's or even just X-windows? >>Could you be more specific? What's missing from the Mac interface >>that's in NeXT or in some X specification (i.e., OpenLook or Motif -- X >>isn't really an interface specification)? Was the original question referring to the programming interface or the user interface? >How about pipes and i/o redirection for starters. How do you do pipes and I/O redirection in the NeXT or X window systems? This response seems to be intended for a different question (there's another chain regarding the merits of graphical vs command-line user interfaces). Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
dce@smsc.sony.com (David Elliott) (12/29/89)
In article <780093@hpvcfs1.HP.COM> mikek@hpvcfs1.HP.COM (Mike Kirkpatrick) writes: >>>Speaking of future Apple system software, will Apple ever develop an >>>interface akin to that of the NeXT's or even just X-windows? > >How about pipes and i/o redirection for starters. There are some activities >that are just better done with a text/command line interface. The power to This has little, if anything, to do with the question. Nothing in NeXTStep or X allows you to do pipes. The fact that both of these run on Unix does. >Then there is the beautifully seamless networking capabilities of unix >machines. Unix machines can access many files and run applications on remote >machines from any number of X windows all simultaneously. Can macOS or AUX >do this? > >Inquiring minds want to know? Yes, both can. In the first place, AUX is Apple's port of Unix, so obviously it can do anything Unix can do. MacOS can do quite a bit more than you might think. There are two command-line interfaces for the Mac, and there are network protocols for dealing with remote processes. These just aren't supplied by default with the Mac. I agree with you that Unix is more powerful for advanced users. Hell, I'm a Unix systems programmer. Still, it's not Mac vs. Unix that's being discussed here, it's Mac vs. other modern graphical user interfaces. -- David Elliott dce@smsc.sony.com | ...!{uunet,mips}!sonyusa!dce (408)944-4073 "But Pee Wee... I don't wanna be the baby!"
jln@acns.nwu.edu (John Norstad) (12/29/89)
In article <780093@hpvcfs1.HP.COM> mikek@hpvcfs1.HP.COM (Mike Kirkpatrick) writes: > How about pipes and i/o redirection for starters. There are some > activities that are just better done with a text/command line interface. Yes, there are some things like pipes and i/o redirection that UNIX-like command interfaces currently do much better than the Mac OS. You should check out Apple's MPW (Macintosh Programmer's Workshop). It's based on a UNIX-like shell that has pipes and i/o redirection, plus equivalents for the most popular UNIX filters. I use it all the time, and not just for programming. From what I saw of System 7.0 at last May's Developer Conference, the new Finder in 7.0 will include much more powerful facilities for doing this sort of thing, including selecting files by pattern matching on their names. John Norstad Northwestern University jln@acns.nwu.edu
rewing@Apple.COM (Richard Ewing) (12/30/89)
Mike Kirkpatrick at HP wrote the question, "How do you print all the files in the current directory to the spooled printer?" Simple. First, make sure that you have print spooling setup when you select the printer in the chooser (Multifinder is assumed here). Second, in the Finder, click drag to multiselect all the files you want to print. Third, select "Print" from the file menu, and watch the fun. Incidentally, your Unix command to print all current directory files to the printer works as advertised on any A/UX Macintosh. Remember: A/UX is an AT&T based UNIX! Nothing less! Anything that you woud expect to work in Unix plus networking is possible. -- __________________________________________________________________________ |Disclaimer: I run 125 INITs. Nothing I say can be seriously considered. | | | |Internet: REWING@APPLE.COM-----------------------Rick Ewing | |ApplelinkPE & MacNet Soon!------------------Apple Computer, Inc. | |Applelink: EWING--------------------100 Ashford Center North, Suite 100 | |Compu$erve: [76474,1732]--------------------Atlanta, GA 30338 | |GENIE: R.EWING1--------------------------TalkNet: (404) 393-9358 | |USENET: {amdahl,decwrl,sun,unisoft}!apple!rewing | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
sklein@cdp.UUCP (01/02/90)
Actually, the original question was: >... For example, >how would you do this under macOS (send a list of all files under current >directory to the spooled printer)? > > find . -print | lp Printing files and directories is VERY EASY on the mac. To print a list of the files in the current directory: Choose "Print Directory" from the File menu. To print the actual files in the current directory: Choose "Select All" from the Edit menu, then choose "Print..." from the File menu. Boy, that mac interface sure is tough! -shabtai (e-mail addresses/long sig follow) UUCP: uunet!pyramid!cdp!sklein | BitNet: cdp!sklein%labrea@stanford Internet: cdp!sklein@arisia.xerox.com | Phone: (301) 270-2250 "You can't always get what you wan't" -- Rolling Stones "You can get it if you really want" -- Jimmy Cliff
folta@tove.umd.edu (Wayne Folta) (01/03/90)
"Actually, the original question was: ""... For example, ""how would you do this under macOS (send a list of all files under current ""directory to the spooled printer)? "" "" find . -print | lp " "Printing files and directories is VERY EASY on the mac. " "To print a list of the files in the current directory: " Choose "Print Directory" from the File menu. Maybe you are not familiar with UNIX. In UNIX, the "find . -print" will *recursively* list all files in the current directory. Thus, it is printing the entire subtree rooted at the current directory, not just the current directory. (For example, "find . -print", if invoked in the root directory will print all files on the disk (well, actually the root and all mounted partitions, if you get picky...)) -- Wayne Folta (folta@cs.umd.edu 128.8.128.8)
baumgart@esquire.dpw.com (Steve Baumgarten) (01/03/90)
In article <780093@hpvcfs1.HP.COM>, mikek@hpvcfs1 (Mike Kirkpatrick) writes: >How about pipes and i/o redirection for starters. There are some activities >that are just better done with a text/command line interface. The power to >set in motion a chain of commands. Multi-directory i/o operations(especially >disjoint directories) are much easier done with a command line. For example, >how would you do this under macOS (send a list of all files under current >directory to the spooled printer)? > > find . -print | lp I disagree. Just because something has been done in a certain way for a long time doesn't mean that it's the "best" way to do it. Unix utilities are a case in point. Unix has been around for a while, and the command-line interface has had time to mature. Graphical user interfaces are relatively new, and were originally designed to be user-centered, rather than program-centered or I/O-stream-centered. Thus, I/O redirection on the Mac is difficult *now*. Likewise, Unix deals best with standard input and output streams, because that's what it was designed to do. In any case, a command-line for the Mac is most definitely not the answer. No one on earth can remember all the options to the various utilities (hence the existence of the "man" command under Unix); at least the Commando interface under MPW is a step in the right direction. But getting back to the case at hand, try DiskTop. The new version can do a complex find and then let you operate on the result. For example, I can easily have DiskTop find all the files that end in ".c", and then save the result to a file, print the file list, or copy all but one of the files to a subdirectory, regardless of which directories they reside in. To do that with "find", you'd have to do something bizarre like: find /source -name \*.c -print > cfiles { edit "cfiles" to remove the one file you *don't* want to copy } cp `cat cfiles` subdir Rather less than intuitive. My mother is certainly never going to learn how to do it, and why should she? But she'd have no problem filling in the DiskTop "find" dialog, including setting things up to find all files that haven't been modified in a week. Let's see, under Unix that would be: find / -mtime +7 -print Or is it: find / -mtime -7 -print Better go have a look at the man page... -- Steve Baumgarten | "New York... when civilization falls apart, Davis Polk & Wardwell | remember, we were way ahead of you." baumgart@esquire.dpw.com | cmcl2!esquire!baumgart | - David Letterman
davidl@leonardo.intel.com (David D. Levine) (01/03/90)
> >... For example, > >how would you do this under macOS (send a list of all files under current > >directory to the spooled printer)? > > > > find . -print | lp > > Printing files and directories is VERY EASY on the mac. > > Choose "Print Directory" from the File menu. This is one of several responses that misses the point of the original question. The tricky part here is the "find . -print", which recursively descends the directory hierarchy beginning at the current directory; it lists all files in the current directory AND IN ALL SUBDIRECTORIES and sub-subdirectories and... I don't believe that there is any way to do this on the Mac. I also don't think there's any way to do it on the PC (unless you use a UNIX emulator that includes "find" or some third-party product with equivalent functionality). Another query in the original article was: how do you do the equivalent of "rm *.bak"? The response was to do a View By Type, select a block of files, and drag them to the trash, which led to a tangent about how to select a block of files in View By Type mode. However, this response also missed the point of the original question; backup files (.bak) would presumably have the same types as the files they back up. For example, if you had a bunch of MacWrite files called foo, foo.bak, bar, bar.bak, baz, baz.bak, etc., there is no easy way to select all the .bak files and delete them. (Another response claimed that selecting files by filename patterns will be in System 7.0. We'll see.) My response to these points is that, yes, there are tasks that the Mac's point-and-click interface does not lend itself to. Selecting files according to their names (rm *.bak) is one of them. However, I maintain that if you are using filename extensions to differentiate your files, you are not using your Mac properly. I group related files physically in one part of the directory window, and can easily select them all with a sweep of the mouse. On a color Mac, you can also differentiate files with colored icons (and use View By Color to group them). Use your tools in a sensible way. Don't drive screws with a hammer: it works, but not well. - David D. Levine, Intel IMSO Tech Pubs davidl@leonardo.intel.com "Inconceivable!" "I don't think that word means what you think it means."
lsr@Apple.COM (Larry Rosenstein) (01/05/90)
In article <1618@rodan.acs.syr.edu> isr@rodan.acs.syr.edu ( ISR group account) writes: > Yes! I think it's a great idea. It could be done so it woudn't take up any > more room - instead of putting the menu IN the window, replace the Title Bar > with a MenuBar, Perhaps in a format such as: > AppName File Edit Menu Menu Menu ZoomBox Where would you put the title of the window? (Or should windows not have titles?) > The only problem I can think of now with it is small-width windows > woudn't provide all the menus, but again, that can be handled by MF, just > by providing "scrolling" of the last menu as you go off the edge of the > menubar with the button held down. People have enough trouble with hierarchical menus. I'm not sure if a scrolling menu bar is the best approach. The original complaint was that context switching isn't obvious in MultiFinder. One proposal was to use some kind of animation, which is a good idea, but it takes the user's time. The problem with Switcher is that you couldn't look at windows from 2 applications at the same time, which is very useful. Another comment is that you can switch into an application that has no active windows. I agree this is a real problem, especially for new MultiFinder users. It could be solved if MultiFinder disallowed switching into these applications (except perhaps with the Apple menu, which would make it explicit). Putting the application's menus in the window would also solve the immediate problem, but I think it introduces other problems. First, is the problem of not having a wide enough window. Applications are alrady running our of menu bar space, and this would just add to the problem, or force users to make windows wider than they need. Having the menu bar in each window also takes up more screen space overall. It also seems that it would be harder for the user to use the menus. With the menu bar at the top of the screen, you can (normally) overshoot the top of the menu bar and still activate the menu. With the menus in a window, you could overshoot and click the close box instead. One would have to do user test to see if this is a problem. Making the inactive application windows dimmer than the active application's windows is a good idea. If you do this to the structural parts of the window, users will still be able to read the contents. Perhaps applications should put up a modeless splash screen if all their windows are closed; that way the user would always know which application was active. Larry Rosenstein, Apple Computer, Inc. Object Specialist Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1
long@mcntsh.enet.dec.com (Richard C. Long) (01/05/90)
In article <6007@internal.Apple.COM>, lsr@Apple.COM (Larry Rosenstein) writes...
[about menus in windows]
I think the way McSink does it is excellent. It puts a horizonally scrolling
menu bar in the window, just under the title bar.
This way, provided the standard menu bar is eliminated, no more screen real
estate than is already used would be taken up.
For applications that don't normally keep a window open, a simple mechanism
like keeping the copyright window up (with the menu bar) would suffice.
What do you think?
-------------------------------------------------------------------------------
/'') /'' / | long@mcntsh.enet.dec.com | Hey! You're not
/''\ /__ /__ | ...!decwrl!mcntsh.enet.dec.com!long | Rockin' Ricky
Richard C. Long | long%mcntsh.dec@decwrl.enet.dec.com | fans! -- "Gremlins"frank@mnetor.UUCP (Frank Kolnick) (01/05/90)
In article <6007@internal.Apple.COM> lsr@Apple.COM (Larry Rosenstein) writes: >In article <1618@rodan.acs.syr.edu> isr@rodan.acs.syr.edu ( ISR group >account) writes: > >> Yes! I think it's a great idea. It could be done so it woudn't take up >any >> more room - instead of putting the menu IN the window, replace the Title >Bar >> with a MenuBar, Perhaps in a format such as: >> AppName File Edit Menu Menu Menu ZoomBox > >Where would you put the title of the window? (Or should windows not have >titles?) Much as I like the Mac (I use it heavily every day), and much as I think the current hoopla over X/Motif/Open Look/etc. is focusing on flash rather than substance (i.e., I think the fancy, multi-coloured, 3D windows distract the user from the application), I do think Open Look has done a couple of things right in this area: In the context of this discussion, any part of the window frame is potentially available for interaction. Naturally, this can be abused, but a well-designed application may place command buttons (which directly activate actions, like 'save'), menu buttons (to pop up a menu), exclusive lists (to set options), scrolling lists, etc. in any of the four bars. For example, the top bar generally contains a window button, a title and perhaps a message. Below this (separated by a line), may be a row or two of buttons. The bottom bar may contain buttons, or a message such as the current page number. Note that I said 'window button', not 'close' button. This button can be used to pop up a menu which lets you expand the window to full-screen size, iconify it, close it, etc. You can get the default action (usually 'close') in one click. >> The only problem I can think of now with it is small-width windows >> woudn't provide all the menus, but again, that can be handled by MF, just >> by providing "scrolling" of the last menu as you go off the edge of the >> menubar with the button held down. > >People have enough trouble with hierarchical menus. I'm not sure if a >scrolling menu bar is the best approach. While Open Look supports hierarchical menus, too, it also provides context sensitive menus. I.e., the menu you get in the frame is different than the one you get in the pane (there can be multiple panes, btw). A good application will pop-up object-specific dialogue (OL has pop-up 'command windows' in addition to menus) such as a list of fonts or type styles when the cursor is on text. >Having the menu bar in each window also takes up more screen space >overall. It also seems that it would be harder for the user to use the >menus. With the menu bar at the top of the screen, you can (normally) >overshoot the top of the menu bar and still activate the menu. With the >menus in a window, you could overshoot and click the close box instead. >One would have to do user test to see if this is a problem. >... I don't think I'm any more likely to overshoot a menu bar than I am a text string in the pane (generally a trickier target, in my experience). I do find it tiring to visually search out the menu I want when the window isn't at the top of the screen, and then move the cursor up there, drag, then move it back where I need it. (Open Look 'jumps' the cursor to the dialog window and then jumps it back to your pane when done.) Overall, the demands placed on windowing systems has increased since their introduction. The question (one question, anyway) is how to manage the additional complexity without placing too many demands on the poor user. IMHO, the single-application-at-a-time view of the current Mac interface is slipping a little behind the times. Personally, I like the idea of having the menus, etc., I need grouped close to the data I'm working on. The window frame seems to be a logical choice. If I move the window, the menu bar et al. moves with it. If I bring up another application's window, the previous one (menus and all) is hidden until I need it again. (I don't mean to sound like an Open Look salesman, and I could find lots of nits to pick, but it is a step in the right direction. It pays to study the competition :-) -- Frank Kolnick, consulting for, and therefore expressing opinions independent of, Computer X UUCP: {allegra, linus}!utzoo!mnetor!frank
cca@pur-phy (Charles C. Allen) (01/05/90)
>> ...instead of putting the menu IN the window, replace the Title Bar >> with a MenuBar, Perhaps in a format such as: >> AppName File Edit Menu Menu Menu ZoomBox >> The only problem I can think of now with it is small-width windows >> woudn't provide all the menus, but again, that can be handled by >> MF, just by providing "scrolling" of the last menu as you go off >> the edge of the menubar with the button held down. > People have enough trouble with hierarchical menus. I'm not sure if a > scrolling menu bar is the best approach. DECwindows handles this by wrapping the menubar around, as in File Edit View Special Color becoming File Edit View Special Color I have no difficulty using wrapped menubars. >Having the menu bar in each window also takes up more screen space >overall. It also seems that it would be harder for the user to use the >menus. Screen real estate is a problem. On the other hand, having the menus that apply to the window I'm in *right there* makes it much easier to understand what operations make sense & doesn't force me to move my head up to the upper left corner of a big screen all the time. A reasonable arrangement would be to have the screen menubar be reserved for operations affecting the entire application (open a new window, global preferences), while the window menubar has operations affecting the window contents. I would hope that the Apple HIG people have already been looking into these questions. Charles Allen cca@newton.physics.purdue.edu
dent@unocss..unl.edu (Local Submission) (01/07/90)
cca@pur-phy (Charles C. Allen) writes: > (DEC-windows wraps menubars...) >I have no difficulty using wrapped menubars. This is indeed one workaround but it's major disadvantage is that it takes even /more/ screen space. I'm not sure Plus and SE users (of which I am one :-) would appreciate that... Unless the Control Panel allowed us to specify our own system font, and we happened to pick one that is considerably smaller than Chicago? ("system font" in the menubar sense, that is) >Screen real estate is a problem. On the other hand, having the menus >that apply to the window I'm in *right there* makes it much easier to >understand what operations make sense & doesn't force me to move my >head up to the upper left corner of a big screen all the time. A >reasonable arrangement would be to have the screen menubar be reserved >for operations affecting the entire application (open a new window, >global preferences), while the window menubar has operations affecting >the window contents. On the extremely few occaisions that I get to use a large monitor, I have to agree that if your application's window is near the bottom of the screen, having to stop everything, go find the menus, use them, and come back, is counterproductive. The menubar works great for a smaller screen like the Plus and SE have, but it's not all that well suited for larger screens. We have two things competing here: Improved Usibility (through an improved interface), vs. Screen Real Estate. :-) One suggestion that I can think of for Plus/SE-type screens is to change the default WDEFs to make title bars smaller, like the "Shrinker WDEF" (Which I *love* on my SE, if only for this reason, since I hardly ever use the "shrinker" box), from WindChooser (available at better Mac FTP sites near you). If the menubar was shrunk to that size (user-selectable of course, via Chooser), then adding a menubar, even if 12-point Chicago was used (which might not be a necessity), would not increase the amount of "wasted" screen space drastically. One thing to consider (actually a lot of them), when considering splitting an application's menubar between it's windows and "global" menu items, as mentioned above, is: 1. How is the Mac going to /trasnparently/ figure out which menu items are "global" and which are "window-specific"? It really can't; and more importantly: it would /really/ confuse the users. Sure, you could force all of the Mac programmers in the world to suddenly rewrite their code to support "ImprovedFinder", but this would only serve to further alienate them, and would hurt the Mac's standing in the marketplace ("oh god, Apple came out with another version of the OS, now no one can get software until it is all re-written..."). This isn't to say that splitting up the menubar isn't a good idea, though! The Finder, for example, isn't really "just an application". Even before MultiFinder, the Finder was always presented as a sort of "Director", or "organizer". It's job is to help you use "real" applications (by launching them), and to manipulate files. When MultiFinder came along, "Finder" became "just another application", and given equal billing and status as any other application. My point is that Finder /isn't/ "just another application; it's purpose (now at least) seems to be to "manage" all of the stuff going on on the Mac. And if this is the case, it seems sensible that the Finder should inherit the menubar at the top of the screen, since menu items there are likely to affect any or all portions of the scren -- even the whole Mac --, and not just one window. So if the Menubar is to be split, it's my opinion that this is where the split should be. :-) Well now we've really opened a can of worms. Now the user is going to have a "File" and "Edit" (and possibly even others) menu in several windows, as well as at the top of the screen. If this transition is really to take place, then the "file" and "edit" menus in Finder really should be renamed, or again we risk user confusion. This comes at a pretty good time, though; are "file" and "edit" really the best names for those menus? Ex: I click once on my hard drive icon, and then pull down "Open" from the "File" menu. Does that mean that my hard drive is a file? Well "kinda..." if additional functionality to handle the windows that applications and such are going to live in in this HypotheticalFinder, then something more generic, like perhaps "Item" would be more appropriate. (and of course, the "Open" item in this menu could change names depending on what the user clicked on. For example, "Open Volume" if they clicked on a disk, "Open Document", "Open Application", "Open Folder", etc.) There are plenty of other issues related to a change this drastic, but I think that I've rambled enough for the moment.. :-). Comments, criticisms, suggestions, etc. are all quite welcome; I think this is a fascinating discussion (and a lot more interesting than "IBM sucks! Mac Sucks! IBM sucks! ... ad nauseum." :-) >I would hope that the Apple HIG people have already been looking into >these questions. So would I! In fact, is anyone in the HIG reading this stuff? And how does one go about getting a job with that group anyway? :-) :-) >Charles Allen cca@newton.physics.purdue.edu -/ Dave Caplinger /--------------------------------------------------------- Microcomputer Specialist, Campus Computing, Univ. of Nebraska at Omaha mspecial@zeus.unl.edu ...!uunet!unocss!dent MSPECIAL@UNOMA1
kent@sunfs3.camex.uucp (Kent Borg) (01/10/90)
In article <2964@pur-phy> cca@pur-phy (Charles C. Allen) writes: >DECwindows handles this [not always enough room at the top of a window for a menu bar] by wrapping the menubar around, as in > > File Edit View Special Color > >becoming > > File Edit View > Special Color > >I have no difficulty using wrapped menubars. But we would loose an important feature of the current menus. People can scan through the current menu bar by dragging left and right, and select from within a menu be dragging down and up. If you wrap the menu bar, you can't do this. It might sound trivial, but a lot of what makes the Mac so great sounds trival. I agree that the menu bar can get pretty far away (I wish I had more experiance with the problem--anyone want to send me a free big screen so I can be more authoratative?), and I agree that presto-chango nature of the current menu bar under MultiFinder is confusing. Menus in windows sounds good in general... Another problem: What if an application has more than one window open? Do they all have the same menu? Do different types of windows have different menus (making them look like different apps)? Is there a master window which has the single menu bar? For this last possibility, maybe this is not a window which has a variable width? The user interface designer would then have to work with the trade-offs, as is done now. Another problem: If the menu bar is no longer at the edge of the screen, the user can no longer use the top of the screen as a backstop. It becomes possible to overshoot. Sure, that is true all over the rest of the screen, but it should still be understood before things are changed. -- Kent Borg lloyd!kent@husc6.harvard.edu or ...!husc6!lloyd!kent MacNet: kentborg H:(617) 776-6899 W:(617)426-3577 "The wall has been opened. One of the most insurmountable borders in Europe has become a German dance floor." -Christoph Hein, NYT Magazine, 17 Dec 1989
CJENKINSR@admdev.cut.oz (Richard Jenkins) (01/12/90)
In article <6007@internal.Apple.COM>, lsr@Apple.COM (Larry Rosenstein) writes: > References:<10734@claris.com> <578@sunfs3.camex.uucp> <1353@unocss..unl.edu> <1989Dec21.105013.7047@jarvis.csri.toronto.edu> <1618@rodan.acs.syr.edu> > > In article <1618@rodan.acs.syr.edu> isr@rodan.acs.syr.edu ( ISR group > account) writes: > >> Yes! I think it's a great idea. It could be done so it woudn't take up (Stuff deleted) > Having the menu bar in each window also takes up more screen space > overall. It also seems that it would be harder for the user to use the > menus. With the menu bar at the top of the screen, you can (normally) > overshoot the top of the menu bar and still activate the menu. With the > menus in a window, you could overshoot and click the close box instead. > One would have to do user test to see if this is a problem. > (more stuff deleted) Ever tried Wrap INIT? A nifty utility that has been around in one form or another for years. It allows you to scroll the cursor of the edge of the screen and it appears on the other side, as if the screen wrapped right around. It also worked top and bottom, so that when you went to the menu bar, oops, you end up in the middle or the bottom of the screen! Every time. If you concentrate, you would get it right, but hey: I don't want to concentrate, I just want to DO IT! If you did manage to hit the menu bar, but on the wrong menu, you have to scroll horizontally in a corridor about 18 pixels high across the screen, with no top edge to lean on. Reflex goes out the window then, and you h a v e t o t a k e y o u r t i m e . . . . zzzzzzzz. My opinion: Like bobbing for goldfish. > > > Larry Rosenstein, Apple Computer, Inc. > Object Specialist > > Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr > AppleLink: Rosenstein1 Cheers _______________________________________________________________________________ Richard Jenkins Tel: (09) 351 7864 AppleLink:AUST0176 PC Support Group Fax: (09) 351 2673 ACSnet:cjenkinsr@mail.cut.oz Curtin University Perth, Western Australia psi%050529452300030::cjenkinsr