GDAU100@BGUVM.BITNET (Jonathan B. Owen) (07/31/89)
I was very impressed reading about system 7.0 and await eagerly for
it's release.
I read the System 7.0 notes found in the MacArch archives (LISTSERV@RICE)
and saw little mention of the improvments scheduled for the Finder.
As any other Mac user, I too have my views on how to improve the finder.
I have not really orginized my thought in the matter, but the following
comes to mind:
o I would like to see a standard Control Device for setting the port
used for communication (read Modem) with all it's relative parameters,
such as speed, parity, etc. Maybe even a modem setup string sent to
the modem at boot. This would eliminate the need for each comm.
program to have it's own implementation.
o I think each application should have it's own menubar within it's
window (possibly scrolling the menubar, for small windows) instead
of todays menubar.
o Desk Accesseries should "float" like Hypercard's tools menu. How
many times did YOU have to bring back the Notepad each time
you switch to anoter application? I can't count that much :)
o The finder should include a tree structure view of an HFS volume.
o Having a pull down menu from a window's title bar of the enclousing
folders would be great (like in MacTools) for navigation (this is
one step futher of double clicking in the title bar in system 6.03 -
once enables with Layout 1.7).
o The ability of temporarly making a window into an icon ("iconization")
is a good solution for working with many applications/windows/DAs
at once.
Any thought?
JB
______________________________________________________________________________
(--) /--) /-(\ Email: gdau100@bguvm (bitnet)
\ / /--K | \|/\ /\/) /|-\ Snail: 55 Hovevei Zion
_/_/o /L__)_/o \/\__/ \X/ \_/ | |_/ Tel-Aviv, 63346 ISRAEL
(/ Jonathan B. Owen Voice: (03) 281-422
Point of view: A chicken is the means by which an egg reproduces an egg.
______________________________________________________________________________mjkobb@mit-amt.MEDIA.MIT.EDU (Michael J Kobb) (07/31/89)
In article <587GDAU100@BGUVM> GDAU100@BGUVM.BITNET (Jonathan B. Owen) writes: >As any other Mac user, I too have my views on how to improve the finder. >I have not really orginized my thought in the matter, but the following >comes to mind: > > o I would like to see a standard Control Device for setting the port > used for communication (read Modem) with all it's relative parameters, > such as speed, parity, etc. Maybe even a modem setup string sent to > the modem at boot. This would eliminate the need for each comm. > program to have it's own implementation. Nice idea, but I've not seen any mention of it anywhere. > > o I think each application should have it's own menubar within it's > window (possibly scrolling the menubar, for small windows) instead > of todays menubar. > It's a thought, but which menubar gets things like SuperClock, On Cue, etc? All of them would be a processor hog, but one of them, obscured, would be a hassle. If you go with a general one as well, then you're getting really redundant. I think scrolling the menubar would be a _big_ annoyance. (also, no mention from Apple) > o Desk Accesseries should "float" like Hypercard's tools menu. How > many times did YOU have to bring back the Notepad each time > you switch to anoter application? I can't count that much :) I don't use HyperCard (because I can't afford the disk/RAM space), so I don't know what its tool menu does. At least the DA's shouldn't shut down if you're running MultiFinder, just be obscured. (They get obscured because the DA's run within the DA Handler's partition, and it acts sort of like an application. When you bring up a new application, MultiFinder assumes that you want to have that application on top (not necessarily a valid assumption)). It would be nice if you could tell one to stay raised until you lower it, though. With System 7.0, MultiFinder is ON. Period. > > o The finder should include a tree structure view of an HFS volume. > Would be nice... > o Having a pull down menu from a window's title bar of the enclousing > folders would be great (like in MacTools) for navigation (this is > one step futher of double clicking in the title bar in system 6.03 - > once enables with Layout 1.7). > Try the init WindowList. It's shareware (I think) and it does just that, and not just for the Finder. (It doesn't give _every_ application's windows, just the active one's). > o The ability of temporarly making a window into an icon ("iconization") > is a good solution for working with many applications/windows/DAs > at once. > Apple comes close to this with MultiFinder 6.1. I've seen a copy of 6.1a2, and it has a nifty feature called "Set Aside" under the Apple menu. You invoke it and all of the selected application's windows are hidden. You bring it back by choosing it from the apple menu again. (They're at the top of the menu, by the way). > Any thought? > There you have it. --Mike
z8my@vax5.CIT.CORNELL.EDU (07/31/89)
In article <587GDAU100@BGUVM> GDAU100@BGUVM.BITNET (Jonathan B. Owen) writes: >I read the System 7.0 notes found in the MacArch archives (LISTSERV@RICE) >and saw little mention of the improvments scheduled for the Finder. > >As any other Mac user, I too have my views on how to improve the finder. >I have not really orginized my thought in the matter, but the following >comes to mind: Most of these seem to be user interface changes, not Finder changes in particular. > o I would like to see a standard Control Device for setting the port > used for communication (read Modem) with all it's relative parameters, > such as speed, parity, etc. Maybe even a modem setup string sent to > the modem at boot. This would eliminate the need for each comm. > program to have it's own implementation. This is probably possible today. The only thing is, most likely applications will override any settings... (maybe an init/cdev to patch the serial driver?) > o I think each application should have it's own menubar within it's > window (possibly scrolling the menubar, for small windows) instead > of todays menubar. I'm not sure this is a good idea for small screens. Scrolling menu bars aren't so hot either (to experience one, try getting a copy of McSink, a text editing DA which has scrolling menu bars inside it's windowss.) After using a NeXT, I get the feeling that a menu bar at the to of the screen is a good idea for small screens, and not so hot for bigger screens. > o Desk Accesseries should "float" like Hypercard's tools menu. How > many times did YOU have to bring back the Notepad each time > you switch to anoter application? I can't count that much :) Another idea which isn't so hot for small screens. Often, I'd like to put some window (DA or otherwise) temporarily out of sight. How about having planes of windows? Say, foreground and background. (this is a hack-- a generalization may be better). > o Having a pull down menu from a window's title bar of the enclousing > folders would be great (like in MacTools) for navigation (this is > one step futher of double clicking in the title bar in system 6.03 - > once enables with Layout 1.7). Not a bad idea. (I wonder how difficult to implement today?) > o The ability of temporarly making a window into an icon ("iconization") > is a good solution for working with many applications/windows/DAs > at once. The SADE Multifinder has something similar to this. Sam Paik d65y@vax5.cit.cornell.edu
paul@taniwha.UUCP (Paul Campbell) (07/31/89)
In article <587GDAU100@BGUVM> GDAU100@BGUVM.BITNET (Jonathan B. Owen) writes: > o I would like to see a standard Control Device for setting the port > used for communication (read Modem) with all it's relative parameters, > such as speed, parity, etc. Maybe even a modem setup string sent to > the modem at boot. This would eliminate the need for each comm. > program to have it's own implementation. Apple's Communication Toolbox will provide this and will be here before 7.0 Paul -- Paul Campbell UUCP: ..!mtxinu!taniwha!paul AppleLink: D3213 "Free Market": n. (colloq.) a primitive fertility goddess worshipped by an obscure cult in the late 20th C. It's chief priest 'Dow Jones' was eventually lynched by an enraged populace during an economic downturn (early 21st C).
ching@pepsi.amd.com (Mike Ching) (08/01/89)
Since wishlists are starting up again, I'll add my two cents: I'd like a way to select disjoint parts of a file name and have them behave as wildcards, eg., FILEname.EXT (where the caps are selected/highlighted) would select any file with 'name.' in it and fILENAME.ext would select any file starting with 'f' and ending with '.ext'. An extension to the standard file dialog to allow multiple selection would accomplish the same thing and eliminate the problem of applications not supporting multiple selection or using different mechanisms like shift-click, drag, cmmd-S, cmmd-A, etc. Please fix my pet peeve in system 7.0. mike ching
truel@silver.bacs.indiana.edu (Robert Truel) (08/01/89)
In article <26548@amdcad.AMD.COM> ching@pepsi.AMD.COM (Mike Ching) writes: > >Since wishlists are starting up again, I'll add my two cents: I agree. Since apple is creating a new outline font capability in the new system, I would like to encourage the inclusion of "fuzzy" fonts in system 7.0. Aliases fonts should have considerably better quality and much less eyestrain. Moreover the technology is available and simple. Especially simple if the macintosh is creating bitmap fonts on the fly. Bob Truel Robert N. Truel "Life sucks, of course, but it didn't have to suck quite like this" -- RJSJR truel@silver.bacs.indiana.edu truelr@iubacs.BITNET
david.dmytryshyn@f428.n250.z1.fidonet.org (david dmytryshyn) (08/01/89)
> o The finder should include a tree structure view of an HFS volume.
Should take this one a bit further... Flip up the tree click on the folder
you want, select some files, flip up the tree again, click on another folder
and copy/move those files. None of this, open 6 folders to get at the one you
want, close 5 of them because they're in the way, open a couple more folders to
get at the target folder, etc... Even with the windows imploding to an icon,
you still have to wade through the hierarchical swamp...
Need some sort of a wildcard selection scheme too.. I can't remember, does the
new Finder allow XCMDs? (I'm beginning to see XCMDs everywhere now) That
would truly allow some awesome customization.
David..
--- FD 2.00
* Origin: Synaptic Communications (1:250/428)jrk@sys.uea.ac.uk (Richard Kennaway) (08/01/89)
I havent seen it mentioned in this thread yet, but it's a long-standing gripe in the Mac community: why do Finder icons always lie behind all the windows of other applications? Kludges like the BLAST Fkey and the latest MultiFinder's Set Aside command are still pretty inconvenient. When an application (the Finder or any other) is in the foreground, all its graphic objects should be in the foreground. Obvious, yes? People have mentioned that it would be nice for applications to be able to iconise windows that the user currently doesnt want to look at. Isnt this exactly what Finder icons are? Why should a window vanish underneath all the other windows on the screen just because it's been collapsed to an icon? -- Richard Kennaway SYS, University of East Anglia, Norwich, U.K. uucp: ...mcvax!ukc!uea-sys!jrk Janet: kennaway@uk.ac.uea.sys
kent@lloyd.camex.uucp (Kent Borg) (08/03/89)
In article <656@sys.uea.ac.uk> jrk@uea-sys.UUCP (Richard Kennaway) writes: >I havent seen it mentioned in this thread yet, but it's a long-standing >gripe in the Mac community: why do Finder icons always lie behind all the >windows of other applications? Kludges like the BLAST Fkey and the latest >MultiFinder's Set Aside command are still pretty inconvenient. > >When an application (the Finder or any other) is in the foreground, all >its graphic objects should be in the foreground. Obvious, yes? Obvious, but obvious is not always a good idea. How would you tell the difference between an icon in a window, and a desktop icon which is floating above a window? If you can't keep your desktop clean enough to be seen, then don't put file icons there. I can't, so I don't. Getting to disk icons is clearly a problem. Should Apple turn them into some sort of window? Maybe, but you can already get them to be windows, yet people still close the windows into icons. Should Apple add an anti-zoom-box?, one which shrinks a window to its smallest size? Maybe, but that is a far cry from the floating of icons which you suggest. With user interfaces it is easy to spot problems. It is also easy to suggest changes. But it can be very hard to suggest changes which actually fix a problem without breaking something else. Kent Borg kent@lloyd.uucp or ...!husc6!lloyd!kent
sbchanin@hathor (Steve Chanin) (08/03/89)
My guess as to why MF doesn't bring icons to front is that all the people
at Apple who developed it were using Mac II's with large screens. In this
environment the icons are generally not covered by windows and this problem
doesn't arrise. For all the rest of us with small screens, it would be most
convenient if icons came to the front. Especially icons which represent
applications (i.e. icons created by "shrinking" an application window).
--------------------------------------------------------------------------------
DOMAIN: sbchanin@sj.ate.slb.com
UUCP: {amdahl,decwrl,uunet}!sjsca4!sbchanin INTERNET: sbchanin%sjs@sdr.slb.com
USMAIL: Steven Chanin, Schlumberger Technologies, 1601 Technology Drive,
San Jose, CA 95110 PHONE: 408-437-5144peter@aucs.uucp (Peter Steele) (08/03/89)
I would like to see an enhanced clipboard with standards developed
for using it (eg., if cmd-V is paste, cmd-shift-V is a logical
key sequence for append).
--
Peter Steele, Microcomputer Applications Analyst
Acadia University, Wolfville, NS, Canada B0P1X0 (902)542-2201x121
UUCP: {uunet|watmath|utai|garfield}!dalcs!aucs!Peter
BITNET: Peter@Acadia Internet: Peter%Acadia.BITNET@CUNYVM.CUNY.EDUcaptkidd@athena.mit.edu (Ivan Cavero Belaunde) (08/04/89)
Well, since everyone is talking about this, I might as well throw in my $.02. One thing I've noticed is that people are talking about how sluggish the new font scheme can become at times. The thing that Apple must recognize is that the vast majority of users use (most of the time) 10-18 point fonts in 4 or 5 font families. It seems to me that the thing to do would be to permit the new fonts to have references to pre-stored bitmaps in a few sizes. While this might add another layer of complexity to the font manager, I think it would significantly improve performance in 90% of use. The referenced bitmaps would store point *and* DPI information (ie "This bitmap is 12 pt Helvetica for 72 dpi display." Extending this a little, there could be a utility that takes the outline fonts and produces bitmaps for x-point size at y-dpi resolution, which would then allow the user to customize their system bitmaps and optimize their system performance (based upon which bitmaps they use the most). Given this streamlining, I don't think it would be unreasonable for users to expect slower performance on the font manager when inserting 72-point Times in a pagemaker document. If this is done, pre-stored bitmapped anti-aliased fonts would also be less of a drain on the CPU when system 8 (probably more like system 10) comes around, since common sizes would be stored in a manner similar to this. I do agree that Apple should reserve more than 2 color entries in the CLUT (4 sounds reasonable). Finally, to restate something I said a while ago, I hope the SE/30 is their last Macintosh with a 1-bit display. A 16-greys or even 256-greys wouldn't have added that much complexity (mostly memory), and standardize their product line on a minimum platform that supports multi-bit pixels. Flame as you will, but make sure you have your asbestos suit handy if you do. -Ivan "We live a contented life, as any fool can plainly see." "I can plainly see that!" -Groo the Wanderer Internet: captkidd@athena.mit.edu
roy@phri.UUCP (Roy Smith) (08/04/89)
What I would like to see is an option (perhaps in the control
panel?) which make the active window the one which the mouse is currently
in, instead of the last one you clicked on. To keep the system from
thrashing trying to shuffle windows when you sweep the mouse across the
screen, this probably means not requiring that the active window be the top
one. I guess what I mean is emulating the standard suntools behavior
(yeah, I can see it now, Sun sues Apple for look-and-feel violations!)
On the other hand, I can easily see how accomdating everybodies
favorite feature will quickly make for megabyte systems, with megabyte
finders on top of that. Pretty soon we'll need 4 Meg just to boot the damn
thing.
--
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
{att,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@alanine.phri.nyu.edu
"The connector is the network"mjkobb@mit-amt.MEDIA.MIT.EDU (Michael J Kobb) (08/05/89)
In article <459@lloyd.camex.uucp> kent@lloyd.UUCP (Kent Borg) writes: >In article <656@sys.uea.ac.uk> jrk@uea-sys.UUCP (Richard Kennaway) writes: >>I havent seen it mentioned in this thread yet, but it's a long-standing >>gripe in the Mac community: why do Finder icons always lie behind all the >>windows of other applications? [...] >How would you tell the difference between an icon in a window, and a >desktop icon which is floating above a window? Note: >>windows of other applications? ^^^^^ Sure, the finder icons shouldn't float above it's own windows... That would be confusing. But, it's awful when you have an application running under MultiFinder and you switch back to the Finder. You can't get at any of your desktop-level applications, nor any disks. >Getting to disk icons is clearly a problem. Should Apple turn them >into some sort of window? Maybe, but you can already get them to be >windows, yet people still close the windows into icons. Should Apple ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Sure. That's the whole point of icons: to eliminate clutter. I dunno. It's a tough call. I like the idea of Set Aside, myself. --Mike Standard disclaimers...
jrk@sys.uea.ac.uk (Richard Kennaway) (08/05/89)
In article <459@lloyd.camex.uucp> kent@lloyd.UUCP (Kent Borg) writes: >In article <656@sys.uea.ac.uk> jrk@uea-sys.UUCP (Richard Kennaway) writes: >>When an application (the Finder or any other) is in the foreground, all >>its graphic objects should be in the foreground. Obvious, yes? > >How would you tell the difference between an icon in a window, and a >desktop icon which is floating above a window? I'd regard that as a problem to be solved, rather than a refutation of the idea. (And one which I'll leave to the interface design experts, not being one myself.) >If you can't keep your desktop clean enough to be seen, then don't put >file icons there. I can't, so I don't. I use a Mac+. Small screen. As soon as you run an application, you cant see the desktop. In the Finder itself, I can arrange the Finder windows to not obscure the (er...switch to Finder, Set Aside Others...) twenty-one icons on my desktop. Most other applications, you need a full-screen window. However, Set Aside Others, which I just read about in another message here (manuals? but this is a Mac! :-) ) does make it easier. Perhaps easy enough to be a sufficient solution of the problem. >Kent Borg -- Richard Kennaway SYS, University of East Anglia, Norwich, U.K. uucp: ...mcvax!ukc!uea-sys!jrk Janet: kennaway@uk.ac.uea.sys
captkidd@athena.mit.edu (Ivan Cavero Belaunde) (08/06/89)
In article <672@sys.uea.ac.uk> jrk@uea-sys.UUCP (Richard Kennaway) writes: >In article <459@lloyd.camex.uucp> kent@lloyd.UUCP (Kent Borg) writes: >>If you can't keep your desktop clean enough to be seen, then don't put >>file icons there. I can't, so I don't. > >I use a Mac+. Small screen. As soon as you run an application, you cant >see the desktop. Yup. This is absolutely true (and one of the reasons I ended up going to a II in the first place. Apple needs to realize that one of the machine they're going to need in place, for the long term, is a "compact" line (one-piece transportable) fairly inexpensive Mac with a 640x480 13" screen. This would be a bit larger (mostly on the width dimension) but not unreasonably so).My AppleColor 13" is not *that* big, after all. It is ludicrous for people to have to pay $4K up (and this is at student prices) for a Mac with a decent size screen. At street prices, with a HD and just monochrone display, we're in the $6-7K range. Absolutely ridiculous if all you want is a larger screen (and there is a fair amount of those people out there, believe me). Witness the popularity of large screen displays (both FPDs and Portrait), even though you have to pay through the nose for them. There is a niche for an SE or SE/30 witha 13" display, guys. From the stories in MacUser about your labs, it looks like you've got lots of products in development - let them see the light! Otherwise, you might turn into Xerox, which because of the blinders worn by management wasted *astounding* amounts of technology developed by them at PARC (A PC in 1973? A Mac in 1979? Sheesh). -Ivan Internet: captkidd@athena.mit.edu
ck@voa3.UUCP (Chris Kern) (08/07/89)
In article <13300@bloom-beacon.MIT.EDU> captkidd@athena.mit.edu (Ivan Cavero Belaunde) writes: >. . . Witness >the popularity of large screen displays (both FPDs and Portrait), even though >you have to pay through the nose for them. There is a niche for an SE or >SE/30 witha 13" display, guys. From the stories in MacUser about your labs, >it looks like you've got lots of products in development - let them see the >light! Otherwise, you might turn into Xerox, which because of the blinders >worn by management wasted *astounding* amounts of technology developed by >them at PARC (A PC in 1973? A Mac in 1979? Sheesh). Indeed. Although a 13" inch monitor is still rather small. We use Xerox 6085s; they are outstanding office systems, despite their flaws. One of the reasons I haven't sprung for a Mac to use at home is that I am so spoiled by the 19" display on the Xerox 6085/ViewPoint machine I use at work. The Xerox/Apple desktop-style user agent really demands a big monitor. As the Mac software matures, the requirement is going to become even more urgent; once you have true multitasking, you really need to keep multiple windows open, and visible, at the same time. And the Mac II is out of my price range for a home computer. I am constantly twitting the Xerox folks about how much they have to learn (sic) from Apple. But the opposite is also astonishingly true. Apple has popularized a lot of fine ideas that originated at places like SRI and Xerox PARC, and has made itself a serious player in the market as a consequence. (After all, how many people even know Xerox sells comuters?) But what may have been reasonable limitations or design constraints when the Mac was introduced do not necessarily make sense today. -- Chris Kern Voice of America, Washington, D.C. ...uunet!voa3!ck +1 202-485-7020
Greg@AppleLink.Apple.Com (Greggy) (08/08/89)
In article <656@sys.uea.ac.uk> jrk@uea-sys.UUCP (Richard Kennaway) writes: > I havent seen it mentioned in this thread yet, but it's a long-standing > gripe in the Mac community: why do Finder icons always lie behind all the > windows of other applications? Kludges like the BLAST Fkey and the latest > MultiFinder's Set Aside command are still pretty inconvenient. Kludge? Kludge!?!?! My dear sir, Blast is one of the most elegant and entertaining FKEYs I've ever seen. It can provide hours of amusement as well as allowing easy access to obscured items. Then again, I could be biased... I wrote it. :) :) :) :) But "kludge"? Surely it's worthy of at least being called a "hack"... ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Greg Marriott + AppleLink: Greg + + Just Some Guy + + + "My phone is always busy" + Internet: Greg@AppleLink.Apple.Com + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Apple Computer, Inc. + + 20525 Mariani Ave, MS-46z, Cupertino, CA 95014 + + (408)974-busy + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
rcbaem@eutrc3.urc.tue.nl (Ernst Mulder) (08/08/89)
In article <587GDAU100@BGUVM> GDAU100@BGUVM.BITNET (Jonathan B. Owen) writes: > o I would like to see a standard Control Device for setting the port > used for communication (read Modem) with all it's relative parameters, > such as speed, parity, etc. Maybe even a modem setup string sent to > the modem at boot. This would eliminate the need for each comm. > program to have it's own implementation. Uh, what about Terminal Programs which save different Speed/Parity/etc. settings for different phonenumbers? What about my MIDI interface? It would be enough to set the standard Serial port. Generally I don't agree with you on this point. I use my serial port for MIDI, and communications, so I need different settings. Ernst. >
rcbaem@eutrc3.urc.tue.nl (Ernst Mulder) (08/08/89)
In article <656@sys.uea.ac.uk> jrk@uea-sys.UUCP (Richard Kennaway) writes: >I havent seen it mentioned in this thread yet, but it's a long-standing >gripe in the Mac community: why do Finder icons always lie behind all the >windows of other applications? Kludges like the BLAST Fkey and the latest >MultiFinder's Set Aside command are still pretty inconvenient. > >When an application (the Finder or any other) is in the foreground, all >its graphic objects should be in the foreground. Obvious, yes? Etc. Is this obvious? Yes. But all those Application's graphical objects are stored in Windows, and the Finder ICONs are in fact part of the DeskTop itself. It wouldn't be consistent when those would come in front of other Applications. (Would't even be convenient, how many times, you imagine, will you accidentally activate an Application instead of hitting a Disk ICON and miss it?) A more consistent solution would be to put the Disk and Trash ICONs in a special window, which switches to the Front together with all other Finder objects. This window could be graphical, with ICONs or could be a simple LIST item with names. (User selectable?) Users could even be allowed to turn the whole option on and off, to preserve the old well-known interface. How about that? Ernst. >
jrk@sys.uea.ac.uk (Richard Kennaway CMP RA) (08/09/89)
In article <3394@internal.Apple.COM> Greg@AppleLink.Apple.Com (Greggy) writes: >In article <656@sys.uea.ac.uk> jrk@uea-sys.UUCP (Richard Kennaway) writes: >> ...Kludges like the BLAST Fkey... >Kludge? Kludge!?!?! >My dear sir, Blast is one of the most elegant and entertaining FKEYs I've >ever seen. It can provide hours of amusement as well as allowing easy >access to obscured items. > >Then again, I could be biased... I wrote it. :) :) :) :) > >But "kludge"? Surely it's worthy of at least being called a "hack"... I stand corrected. It is indeed a hack (I must brush up my American :-) ). I'd use it myself if it werent incompatible with Kermit (which is probably Kermit's problem rather than Blast's - Kermit is incompatible with most window-hacking kl-, er, hacks). > + Greg Marriott + AppleLink: Greg + -- Richard Kennaway SYS, University of East Anglia, Norwich, U.K. uucp: ...mcvax!ukc!uea-sys!jrk Janet: kennaway@uk.ac.uea.sys
jrk@sys.uea.ac.uk (Richard Kennaway CMP RA) (08/09/89)
In article <824@eutrc3.urc.tue.nl> rcbaem@eutrc3.urc.tue.nl (Ernst Mulder) writes: >In article <656@sys.uea.ac.uk> jrk@uea-sys.UUCP (Richard Kennaway) writes: >>When an application (the Finder or any other) is in the foreground, all >>its graphic objects should be in the foreground. Obvious, yes? >Is this obvious? Yes. But all those Application's graphical objects are >stored in Windows, and the Finder ICONs are in fact part of the DeskTop >itself. It wouldn't be consistent when those would come in front of other >Applications. That statement about the Finder's ICONs is really about the implementation (which I dont care about), not the user interface. When I look at the screen, I interpret the Finder's ICONs as like closed books. When I close a book on a physical desk, it doesnt suddenly vanish underneath all the open books and papers. It only vanishes if I put something else on top of it. >Applications. (Would't even be convenient, how many times, you imagine, >will you accidentally activate an Application instead of hitting a Disk >ICON and miss it?) I dont understand the problem you're describing here. > A more consistent solution would be to put the Disk and Trash ICONs in >a special window, which switches to the Front together with all other >Finder objects. This window could be graphical, with ICONs or could be >a simple LIST item with names. (User selectable?) Users could even be >allowed to turn the whole option on and off, to preserve the old well-known >interface. And put all the other desktop icons there, and allow all the usual View options for this "desktop window". This is, I suppose, the easy solution (in terms of implementation), but I'm not very enthusiatic about it. When I turn on my Mac in the morning, I see a subdued grey desktop, with twenty-odd icons scattered around the edges, and no open windows. Looks tidier than having them all in an open window of their own, and makes a pleasing contrast with my physical desktop :-). But that's a matter of taste. Surely the real reason for the Finder icons being glued to the desktop is that before MultiFinder, it was reasonable to implement them that way - just draw them directly on the desktop, instead of having another sort of graphical object to manage. Since MultiFinder, this doesnt work so well, from the user's point of view, but might require a lot of work to change. (Anyone at Apple care to comment on these speculations, made from a position of total ignorance?) > How about that? Ernst. How about this: Someone posted a WDEF a while ago to give you a window which turns into an icon when it's shrunk below a certain size. As far as the Window Manager is concerned, it's still a window, but for the user it's an icon that floats in the same layer as all the application's un-iconised windows. I've got a little text editor that I might install this in, to see what it actually feels like to have floating icons. But I wouldnt expect any problems. -- Richard Kennaway SYS, University of East Anglia, Norwich, U.K. uucp: ...mcvax!ukc!uea-sys!jrk Janet: kennaway@uk.ac.uea.sys Mac tip no. 257 (swap them with your friends! collect the whole set!): If you use the default grey desktop pattern, try using the Control Panel to invert every pixel of the pattern. Result: when you click-drag on the desktop in the Finder, or drag a window of any application, the dotted outline appears in white instead of black. Much more visible.
peter@aucs.uucp (Peter Steele) (08/09/89)
> My dear sir, Blast is one of the most elegant and entertaining FKEYs I've > ever seen. It can provide hours of amusement as well as allowing easy > access to obscured items. I'd like Blast better if it made nice neat square holes. The ragged hole it now makes just slows things down and detracts from the potential usefulness of this "entertaining" fkey. -- Peter Steele, Microcomputer Applications Analyst Acadia University, Wolfville, NS, Canada B0P1X0 (902)542-2201x121 UUCP: {uunet|watmath|utai|garfield}!dalcs!aucs!Peter BITNET: Peter@Acadia Internet: Peter%Acadia.BITNET@CUNYVM.CUNY.EDU
jmunkki@kampi.hut.fi (Juri Munkki) (08/10/89)
In <1989Aug9.112635.9161@aucs.uucp> peter@aucs.uucp (Peter Steele) writes: >> My dear sir, Blast is one of the most elegant and entertaining FKEYs I've >> ever seen. It can provide hours of amusement as well as allowing easy >> access to obscured items. > >I'd like Blast better if it made nice neat square holes. The ragged >hole it now makes just slows things down and detracts from the potential >usefulness of this "entertaining" fkey. So? Just tell your local Mac guru to launch his/her Think/Lightspeed Pascal and type the program from the October 1987 MacTutor. The complete source code is about 1.5 pages long. You might also want to fix the problem I just described in comp.sys.mac.programmer. Most of the source code is to make the hole ragged and to generate the laser cannon sound. My version of Blast has a bug. It crashes inside PaintBehind after six or seven holes. (Even the Finder crashes.) Looking at the object code, I see that this is not exactly the same program that is printed in MacTutor. _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._ | Juri Munkki jmunkki@hut.fi jmunkki@fingate.bitnet I Want Ne | | Helsinki University of Technology Computing Centre My Own XT | ^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
han@Apple.COM (Byron Han) (08/10/89)
article <823@eutrc3.urc.tue.nl> rcbaem@eutrc3.urc.tue.nl (Ernst Mulder) writes: >article <587GDAU100@BGUVM> GDAU100@BGUVM.BITNET (Jonathan B. Owen) writes: >> o I would like to see a standard Control Device for setting the port >> used for communication (read Modem) with all it's relative parameters, >> such as speed, parity, etc. > > Uh, what about Terminal Programs which save different Speed/Parity/etc. >settings for different phonenumbers? What about my MIDI interface? It would >be enough to set the standard Serial port. It can be done... +-----------------------------------------------------------------------------+ | Disclaimer: Apple has no connection with my postings. | +-----------------------------------------------------------------------------+ Byron Han, Communications Scapegoat At Apple, we change the world everyday. Apple Computer, Inc. ----------------------------------------- 20525 Mariani Ave, MS27Y Internet: han@apple.COM Cupertino, CA 95014 UUCP:{sun,voder,nsc,decwrl}!apple!han ------------------------------------ GENIE:BYRONHAN CompuServe:72167,1664 ATTnet: 408-974-6450 Applelink:HAN1 HAN1@applelink.apple.COM -------------------------------------------------------------------------------
Greg@AppleLink.Apple.Com (Greggy) (08/11/89)
In article <24330@santra.UUCP> jmunkki@kampi.hut.fi (Juri Munkki) writes: > and type the program from the October 1987 MacTutor. The complete source Thanks for mentioning this. I forgot! > My version of Blast has a bug. It crashes inside PaintBehind after six > or seven holes. (Even the Finder crashes.) I'm unaware of any crashing bugs, but really complicated regions can crash the Mac. Six or seven holes shouldn't be enough to do that, though. There is one major mis-feature in the published version. It calls GetNextEvent. Well, before MultiFinder this wasn't a problem. Now, MF will switch to another layer from within Blast. Kind of confusing, to say the least. Also, Blast can be invoked from within Blast since FKEYs are invoked by the system from within code called by GetNextEvent. Also confusing, and potentially disastrous. > Looking at the object code, > I see that this is not exactly the same program that is printed in MacTutor. Could be. The one in MacTutor always makes the same shaped hole. Chris Derossi made me a routine that makes random jaggy holes, and that version probably got out. Anyone with access to the source (should I post?) can do whatever they want, it's pretty simple. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Greg Marriott + AppleLink: Greg + + Just Some Guy + + + "My phone is always busy" + Internet: Greg@AppleLink.Apple.Com + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Apple Computer, Inc. + + 20525 Mariani Ave, MS-46z, Cupertino, CA 95014 + + (408)974-busy + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
mithomas@bsu-cs.bsu.edu (Michael Thomas Niehaus) (08/11/89)
>> o I would like to see a standard Control Device for setting the port >> used for communication (read Modem) with all it's relative parameters, >> such as speed, parity, etc. > > It can be done... > >Byron Han, Communications Scapegoat At Apple, we change the world everyday. If anyone would know... (See the credits on the beta copies of the Communication Toolbox to see what I mean--Byron Han's name is all over them.) The CommToolbox provides many useful functions. I can't wait to see the final version. Imagine getting this new modem, terminal emulator, or file transfer utility. Just drop a file into a special folder, and any application written to use the CommToolbox can use it. This sure beat the terminal emulator shuffle (this one does Kermit, this one does Xmodem but its VT100 emulation sucks, etc.) I just hope that it catches on with the commercial market. It makes terminal emulation applications obsolete, but opens up a new market for tools (it would be nice if people would make these and pass them around, kind of like HyperCard stacks). One complaint about the CommToolbox: It makes my dieting hard. All of this talk about cookies. It makes me remember just how bad that healthy cereal really is :-) -Michael p.s. Well, maybe it won't make terminal emulation applications obsolete. Instead, they will be transformed into "fully-featured, extendable communcations environments." -- Michael Niehaus UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!mithomas Apple Student Rep ARPA: mithomas@bsu-cs.bsu.edu Ball State University AppleLink: ST0374 (from UUCP: st0374@applelink.apple.com)