peter@sugar.hackercorp.com (Peter da Silva) (06/16/91)
In article <1991Jun10.071908.8353@neon.Stanford.EDU> torrie@cs.stanford.edu (Evan Torrie) writes: > jerry@polygen.uucp (Jerry Shekhel) writes: > >The only real Apple innovation is the idea to steal the ideas of others. > Show me the pull-down menus on the Xerox Star. Oh, that's right. Apple did add some negative value to the Star concept, like double-clicking instead of drag-and-drop, the one-button mouse, and pull-down menus. One thing I was hoping that 2.0 would support was a de-Macification of the workbench: pop-up menus and drag-and-drop application launching would be a vast improvement. I guess you could add popup menus with a SetFunction, but how about Drag-and-drop? -- Peter da Silva. `-_-' <peter@sugar.neosoft.com>. 'U` "Have you hugged your wolf today?"
torrie@cs.stanford.edu (Evan Torrie) (06/16/91)
peter@sugar.hackercorp.com (Peter da Silva) writes: >de-Macification of the workbench: pop-up menus and drag-and-drop application >launching would be a vast improvement. Drag-and-drop seems to work fine on my Mac. Yep, here I go, just drag my application onto that ResEdit alias, and ResEdit opens up the application. -- ------------------------------------------------------------------------------ Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu Where can a nation lie when it hides its organic minds in a cellar dark and grim? They must be ... very dim.
peter@sugar.hackercorp.com (Peter da Silva) (06/17/91)
In article <1991Jun16.161917.13703@neon.Stanford.EDU> torrie@cs.stanford.edu (Evan Torrie) writes: > peter@sugar.hackercorp.com (Peter da Silva) writes: > >de-Macification of the workbench: pop-up menus and drag-and-drop application > >launching would be a vast improvement. > Drag-and-drop seems to work fine on my Mac. Yep, here I go, just drag > my application onto that ResEdit alias, and ResEdit opens up the application. You'll have to explain what a "ResEdit Alias" is. Do you have to set it up for each application? Is it the application's normal Desktop icon? You could easily set up a program on the Amiga that implemented drag-and-drop in a separate window. -- Peter da Silva. `-_-' <peter@sugar.neosoft.com>. 'U` "Have you hugged your wolf today?"
torrie@cs.stanford.edu (Evan Torrie) (06/17/91)
peter@sugar.hackercorp.com (Peter da Silva) writes: >> Drag-and-drop seems to work fine on my Mac. Yep, here I go, just drag >> my application onto that ResEdit alias, and ResEdit opens up the application. >You'll have to explain what a "ResEdit Alias" is. Take a peek at System 7. [It doesn't have to be an alias, but I like having ResEdit on my desktop, without actually storing the file there] >Do you have to set it up >for each application? No. It's automatically set up from the application's FREF resource, so it works even for non-System 7-aware applications. Normally, you can only drag and drop documents on top of the applications which created them, but ResEdit has a special '****' file type, which allows you to drag and drop absolutely any file. >Is it the application's normal Desktop icon? Yup. -- ------------------------------------------------------------------------------ Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu Fame, fame, fame... What's it good for? Ab-so-lute-ly nothing
taab5@isuvax.iastate.edu (Marc Barrett) (06/17/91)
In article <1991Jun15.180607.10502@sugar.hackercorp.com>, peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <1991Jun10.071908.8353@neon.Stanford.EDU> torrie@cs.stanford.edu (Evan Torrie) writes: >> jerry@polygen.uucp (Jerry Shekhel) writes: >> >The only real Apple innovation is the idea to steal the ideas of others. > >> Show me the pull-down menus on the Xerox Star. > >Oh, that's right. Apple did add some negative value to the Star concept, >like double-clicking instead of drag-and-drop, the one-button mouse, and >pull-down menus. One thing I was hoping that 2.0 would support was a >de-Macification of the workbench: pop-up menus and drag-and-drop application >launching would be a vast improvement. I guess you could add popup menus >with a SetFunction, but how about Drag-and-drop? I don't really understand the value of "drag-and-drop". Amiga users often complain about how, on the MAC, you have to drag the disk icon to the trashcan in order to get your disk out of the drive. It would seem to me that drag-and-drop would be the same hinderance, but with respect to launching applications. >-- >Peter da Silva. `-_-' <peter@sugar.neosoft.com>. > 'U` "Have you hugged your wolf today?" ------------------------------------------------------------- / Marc Barrett -MB- | BITNET: XGR39@ISUVAX.BITNET / / ISU COM S Student | Internet: XGR39@CCVAX.IASTATE.EDU / ------------------------------------------------------------ \ The great thing about standards is that / \ there are so many of them to choose from. / -------------------------------------------------------
peter@sugar.hackercorp.com (Peter da Silva) (06/17/91)
In article <1991Jun16.214309.18102@news.iastate.edu> taab5@isuvax.iastate.edu writes: > I don't really understand the value of "drag-and-drop". It reduces the number of operations that are dependent on the reaction time of the user. It also allows you to pass file names to an application more easily than by opening the app then reading the file, or by going through the shift-double-click mess that Commodore uses. And it could be implemented on the Amiga without having to let any apps know about it, simply by treating it as a shift-double-click launch. > Amiga users > often complain about how, on the MAC, you have to drag the disk icon to > the trashcan in order to get your disk out of the drive. You're mixing up an interface tool with the inappropriate use of a metaphor. A properly implemented "drag and drop" interface here would have an "eject" icon that you dropped the disk onto. Dropping it in the trash would instead format the disk. The Mac System 7 appears to have finally caught up with the 10 year old Xerox Star here, and implemented drag-and-drop. There is some sort of gotcha in the way it's implemented, apparently, based on Evan's description... apparently you can only drop a file on the app that created it unless you do something with ResEdit. -- Peter da Silva. `-_-' <peter@sugar.neosoft.com>. 'U` "Have you hugged your wolf today?"
dant@ryptyde.UUCP (Daniel Tracy) (06/17/91)
Responding to the following: "> >de-Macification of the workbench: pop-up menus and drag-and-drop application > >launching would be a vast improvement. > Drag-and-drop seems to work fine on my Mac. Yep, here I go, just drag > my application onto that ResEdit alias, and ResEdit opens up the application. You'll have to explain what a "ResEdit Alias" is. Do you have to set it up for each application? Is it the application's normal Desktop icon? You could easily set up a program on the Amiga that implemented drag-and-drop in a separate window." ResEdit has nothing to do with this. It's just a program that is being told to run the application he's dragging on it. Yes, pop-up menus and drag-and- drop is built in. Open anything with anything else by dragging one thing on another. Isn't the Mac great? :-)
awessels@ccwf.cc.utexas.edu (Allen Wessels) (06/17/91)
In article <1991Jun17.123525.1485@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >The Mac System 7 appears to have finally caught up with the 10 year old >Xerox Star here, and implemented drag-and-drop. There is some sort of gotcha >in the way it's implemented, apparently, based on Evan's description... >apparently you can only drop a file on the app that created it unless you >do something with ResEdit. There is no gotcha. Drag and drop works with any file and its creator (if the file has its creator set.) ResEdit is only needed if you want to add resources to a program to allow it to accept files that it can translate but did not create. I just dragged a text file created by an automated comm program to Word and it was opened normally.
awessels@ccwf.cc.utexas.edu (Allen Wessels) (06/18/91)
In article <61@ryptyde.UUCP> dant@ryptyde.UUCP (Daniel Tracy) writes: >ResEdit has nothing to do with this. It's just a program that is being told >to run the application he's dragging on it. Yes, pop-up menus and drag-and- ResEdit is being used to EDIT the application being dragged to its alias's icon. In effect, applications are the documents of ResEdit. >drop is built in. Open anything with anything else by dragging one thing >on another. Isn't the Mac great? :-) This is where ResEdit can also come in. You cannot drag just any document to any arbitrary application to open the doc. You can use ResEdit to add resources to the application to tell it what ADDITIONAL document types you want the program to open. In general, the application will come with those resources pre-set, but ResEdit lets you extend that functionality.
peter@sugar.hackercorp.com (Peter da Silva) (06/18/91)
In article <50645@ut-emx.uucp> awessels@ccwf.cc.utexas.edu (Allen Wessels) writes: > ResEdit is only needed if you want to add > resources to a program to allow it to accept files that it can translate but > did not create. I don't get it. Why would this not be the default? -- Peter da Silva. `-_-' <peter@sugar.neosoft.com>. 'U` "Have you hugged your wolf today?"
mykes@amiga0.SF-Bay.ORG (Mike Schwartz) (06/18/91)
In article <1991Jun16.161917.13703@neon.Stanford.EDU> torrie@cs.stanford.edu (Evan Torrie) writes: >peter@sugar.hackercorp.com (Peter da Silva) writes: > > >>de-Macification of the workbench: pop-up menus and drag-and-drop application >>launching would be a vast improvement. > > Drag-and-drop seems to work fine on my Mac. Yep, here I go, just drag >my application onto that ResEdit alias, and ResEdit opens up the application. > Except your application must inform system 7 that it is capable of doing it. -- **************************************************** * I want games that look like Shadow of the Beast * * but play like Leisure Suit Larry. * ****************************************************
dant@ryptyde.UUCP (Daniel Tracy) (06/18/91)
Responding to the following: "The Mac System 7 appears to have finally caught up with the 10 year old Xerox Star here, and implemented drag-and-drop. There is some sort of gotcha in the way it's implemented, apparently, based on Evan's description... apparently you can only drop a file on the app that created it unless you do something with ResEdit." That's bull. Maybe if you would've read it properly. What he was LAUNCHING was ResEdit. You can drop a file on any file that can open it. The OS knows what kind of files another file can open by its FREF resources. This is impossible on the Amiga, of course, as they don't HAVE resources and have to store even icons in seperate files. This feature is VERY useful for ResEdit in particular because it can open any type of file, and you can drop any kind of file on it. There are also FREF types that tell the OS that you can drag volumes and folders (directories) on them as well.
jbickers@templar.actrix.gen.nz (John Bickers) (06/18/91)
Quoted from <61@ryptyde.UUCP> by dant@ryptyde.UUCP (Daniel Tracy): > Responding to the following: ... > drop is built in. Open anything with anything else by dragging one thing > on another. Isn't the Mac great? :-) Say, what are you generating your terrible quoting scheme with? -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Endless variations, make it all seem new" - Devo. ***
davewt@NCoast.ORG (David Wright) (06/18/91)
In article <61@ryptyde.UUCP> dant@ryptyde.UUCP (Daniel Tracy) writes: >ResEdit has nothing to do with this. It's just a program that is being told >to run the application he's dragging on it. Yes, pop-up menus and drag-and- >drop is built in. Open anything with anything else by dragging one thing >on another. Isn't the Mac great? :-) Sounds just like the Amiga to me. I can drag an icon onto the icon editor's window and it will know to load the icon up. And the "icon alias" sounds just like the "Leave Out" option of WorkBench too. Dave
awessels@ccwf.cc.utexas.edu (Allen Wessels) (06/18/91)
In article <1991Jun17.224713.10156@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <50645@ut-emx.uucp> awessels@ccwf.cc.utexas.edu (Allen Wessels) writes: >> ResEdit is only needed if you want to add >> resources to a program to allow it to accept files that it can translate but >> did not create. > >I don't get it. Why would this not be the default? In most cases it is the default, but there are lots of exceptions. Word knows about text files, but unless the file type of the document is TEXT, it won't match the TEXT FREF resource in Word that tells the OS what Word can open. Word also knows about MacPaint files, but unless "Fred's Paint"'s document type has an analogue in Word's FREF resource list, Word can't open it. If you have ResEdit, you can simply add (for example) the FPNT document type to Word's FREF list and you can drag and drop Fred's Paint docs to Word. It sounds kludgey maybe, but the vast majority of users never have to worry about what docs a program will open or even what ResEdit is. ResEdit is sort of the doorway to the other side of the interface.
matija@amiga.ifi.unizh.ch (Matija Milostnik) (06/18/91)
In article <1991Jun16.214309.18102@news.iastate.edu> taab5@isuvax.iastate.edu writes: >In article <1991Jun15.180607.10502@sugar.hackercorp.com>, peter@sugar.hackercorp.com (Peter da Silva) writes: >>In article <1991Jun10.071908.8353@neon.Stanford.EDU> torrie@cs.stanford.edu (Evan Torrie) writes: [deleted] >>Oh, that's right. Apple did add some negative value to the Star concept, >>like double-clicking instead of drag-and-drop, the one-button mouse, and >>pull-down menus. One thing I was hoping that 2.0 would support was a >>de-Macification of the workbench: pop-up menus and drag-and-drop application >>launching would be a vast improvement. I guess you could add popup menus >>with a SetFunction, but how about Drag-and-drop? > > I don't really understand the value of "drag-and-drop". Amiga users >often complain about how, on the MAC, you have to drag the disk icon to >the trashcan in order to get your disk out of the drive. It would seem >to me that drag-and-drop would be the same hinderance, but with respect >to launching applications. To Peter: You are stating that doubleclick is a loss of the original idea of drag-and-drop. I am of the oppinion tha this was an elegant NEW approach of 'how to start an application' and the pull-down menu was a so _good_ approach, that almost evry new computer implements it. (Never heard of PopUpMenu for pop-up meuns on the WB) To Marc: I will summarize the basic ideas of Drag-and-drop: The idea of the icons and workbench is replacing the 'desk you are working on': On the desk you can pick whatever is there and start working. You _see_ a sheet of paper and you can use it for writing, painting, etc.. In real life if you wish to write a letter you just pick the paper and drop it in the printer, or take your favorite cd and put it in the drive, etc.. Now immagine a situation where you see an icon of a document and you start editing it. After you did this you spot another icon (with another document) on your open drawer and you wish to work on it. Usually you get your file requester, get a list of 'strange' names and wonder where the document is you just saw. Wouldn't it be nice you could drop it directly on your application (open or closed). The point is: why have to change your taughts finding out where the file is, if you just have it under your nose? No, if you can drag an icon and drop it on another icon you think is appropriate is the really big improvement. To both: As for the strting an application, you have now two ways - doubleclick on your project - shift click on the project and your application With drag-and-drop you have a new method - drag your project on your application Free choise for evrybody... >>Peter da Silva. `-_-' <peter@sugar.neosoft.com>. > / Marc Barrett -MB- | BITNET: XGR39@ISUVAX.BITNET / Bye Matija +-------------------------------------------------------+ | Q: What's the best way to catch a rabbit? | | A: Hide into a bush and mimic the voice of a carrot. | +-------------------------------------------------------+
matija@amiga.ifi.unizh.ch (Matija Milostnik) (06/18/91)
In article <1991Jun17.123525.1485@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <1991Jun16.214309.18102@news.iastate.edu> taab5@isuvax.iastate.edu writes: >And it could be implemented on the Amiga without having to let any apps know >about it, simply by treating it as a shift-double-click launch. So you dont have to change a line of your code, its all a matter of WB and intuition. Figure this out: somebody calls the filerequester of the asl.libray. For the application this is a black box, and you get a string in response of this call. Now it is up to you if you -typed you filename in the string gadget -clicked you trough the directory, untill you found your file -or dropped you icon on the file requester window >> Amiga users >> often complain about how, on the MAC, you have to drag the disk icon to >> the trashcan in order to get your disk out of the drive. > >You're mixing up an interface tool with the inappropriate use of a metaphor. >A properly implemented "drag and drop" interface here would have an "eject" >icon that you dropped the disk onto. Dropping it in the trash would instead >format the disk. The 'eject' icon is really missing on a mac. It was always unclear why you have to trash your disk and could not find it, the next day:-) >apparently you can only drop a file on the app that created it unless you >do something with ResEdit. It is useless to drop a document on a database or a soundfile on a comunication program, so this limitaion is not a bug but a feature. >Peter da Silva. `-_-' <peter@sugar.neosoft.com>. +-------------------------------------------------------+ | Q: What's the best way to catch a rabbit? | | A: Hide into a bush and mimic the voice of a carrot. | +-------------------------------------------------------+
peter@sugar.hackercorp.com (Peter da Silva) (06/19/91)
Me: > "The Mac System 7 appears to have finally caught up with the 10 year old > Xerox Star here, and implemented drag-and-drop. There is some sort of gotcha > in the way it's implemented, apparently, based on Evan's description... > apparently you can only drop a file on the app that created it unless you > do something with ResEdit." In article <62@ryptyde.UUCP> dant@ryptyde.UUCP (Daniel Tracy) writes: > That's bull. Maybe if you would've read it properly. Well, actually, he sort of explained it poorly. And even he admits it's a kludge. > This is impossible on the Amiga, of course, Of course. It's impossible to pass a file to an application when you launch it (clue: it's not... you use shift-doubleclick). > as they don't HAVE resources Thank god, we don't have to play games with the likes of BinHex to interoperate with normal systems. What we *do* have is standard interchange formats, something the Mac doesn't. Instead of saying "this is a MacPaint file" we say "This is an interleaved bitmap". Much more useful. -- Peter da Silva. `-_-' <peter@sugar.neosoft.com>. 'U` "Have you hugged your wolf today?"
peter@sugar.hackercorp.com (Peter da Silva) (06/19/91)
In article <1991Jun18.165401.26383@ifi.unizh.ch> matija@amiga.ifi.unizh.ch (Matija Milostnik) writes: > Figure this out: somebody calls the filerequester of the asl.libray. For the > application this is a black box, and you get a string in response of this call. > Now it is up to you if you > -typed you filename in the string gadget > -clicked you trough the directory, untill you found your file > -or dropped you icon on the file requester window No good. You have to launch the application *first*. A drag and drop interface would kick off a tool if you dragged a project icon onto the tool icon and dropped it there. -- Peter da Silva. `-_-' <peter@sugar.neosoft.com>. 'U` "Have you hugged your wolf today?"
peter@sugar.hackercorp.com (Peter da Silva) (06/19/91)
In article <1991Jun18.163422.26170@ifi.unizh.ch> matija@amiga.ifi.unizh.ch (Matija Milostnik) writes: > You are stating that doubleclick is a loss of the original idea of > drag-and-drop. I am of the oppinion tha this was an elegant NEW approach > of 'how to start an application' No, it was a kludge invented by Apple because they were hung up on the one- button mouse. So instead of having buttons to select and activate objects, they had to make one button do double-duty. > and the pull-down menu was a so _good_ > approach, that almost evry new computer implements it. (a) No, they don't. Only the ones copying the Mac. Neither Motif nor Open Look use it, for example. (b) It was a kludge invented by apple to cover up the lack of a menu button. -- Peter da Silva. `-_-' <peter@sugar.neosoft.com>. 'U` "Have you hugged your wolf today?"
dant@ryptyde.UUCP (Daniel Tracy) (06/19/91)
Responding to the following: "Except your application must inform system 7 that it is capable of doing it." I don't know what caused this perception. Every application I know of keeps FREF resources indicating what file types it can open. The application doesn't even have to know ANYTHING about System 7.
matija@amiga.ifi.unizh.ch (Matija Milostnik) (06/19/91)
In article <1991Jun19.001332.23587@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >No good. You have to launch the application *first*. A drag and drop interface >would kick off a tool if you dragged a project icon onto the tool icon and >dropped it there. Good point. This is a transitory solution I envision untill ALL programms have drag-and-drop. >Peter da Silva. `-_-' <peter@sugar.neosoft.com>. +-------------------------------------------------------+ | Q: What's the best way to catch a rabbit? | | A: Hide into a bush and mimic the voice of a carrot. | +-------------------------------------------------------+
awessels@ccwf.cc.utexas.edu (Allen Wessels) (06/19/91)
In article <1991Jun19.000825.23509@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >Thank god, we don't have to play games with the likes of BinHex to interoperate >with normal systems. Uh, and neither do Mac users. I've transferred binaries straight from Unix machines to my Mac, and downloaded Mac binaries directly from several IBM BBS systems. Note that the accepted file formats on all the major commercial online services is also binary. >What we *do* have is standard interchange formats, something the Mac doesn't. >Instead of saying "this is a MacPaint file" we say "This is an interleaved >bitmap". Much more useful. Yep and so do we. If you've missed the posts, the format is PICT. The file type information is used for the purposes of figuring out whether a program can accept the drag and dropped file.
taab5@isuvax.iastate.edu (Marc Barrett) (06/19/91)
Drag-and-drop does sound interesting, but it ocurred to me that, in order for drag-and-drop to work well on an Amiga, one additional feature will have to be added. The problem is that on the Amiga, icons can be (and very often are) quite large. Icons larger than about 30x30 (a typical, usable size on a 640x200 Workbench) are common, and it is not unusual to find icons as large as half of the screen. Icons this large can play havoc with a feature like drag-and-drop, because when the user drags an unusually large icon over a cluster of applications, the user will not be able to tell which application will be launched when the icon is released. To solve this problem, one additional selection needs to be added to the "Show By" options in the Workbench 2.0 menus. The new option could be called "Show By Default Icon" (or something similar), and work work as follows: if no icons are selected, then all of the icons in the currently active window will be shown by the default system icon images instead of the actual images in the .info file. If an icon is selcted, then only the image for that particular file is replaced with the default image. If an icon is already the default image (for a program without an icon, for instance) then nothing happens for that icon. Further, if the icon for a program or project is swapped with the default icon and that icon is selected, the tools and tooltypes in the actual .info file should be used exactly as if the original icon was selected (in other words, the "Show By Default Icon" option should trade the image only, and notthing else). This would effectively solve the problem of large icons with the drag-and-drop feature, because if a program does have a large icon, the user could have the normal-sized default icon image shown instead, and drag that image over to the application. I know I did not explain this very well, but I am in a hurry at the moment. Anyway, the problem of large icons is serious enough to make drag-and-drop useless in many, many circumstances, and this added 'Show By ...' feature is one way to solve this. ------------------------------------------------------------- / Marc Barrett -MB- | BITNET: XGR39@ISUVAX.BITNET / / ISU COM S Student | Internet: XGR39@CCVAX.IASTATE.EDU / ------------------------------------------------------------ \ The great thing about standards is that / \ there are so many of them to choose from. / -------------------------------------------------------
stevep@wrq.com (Steve Poole) (06/20/91)
In article <1991Jun19.000825.23509@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >Thank god, we don't have to play games with the likes of BinHex to interoperate >with normal systems. What games are these? I don't play any games to transfer files between Macs, PCs, Unix boxes, HP minis, or Vaxen. >What we *do* have is standard interchange formats, something the Mac doesn't. >Instead of saying "this is a MacPaint file" we say "This is an interleaved >bitmap". Much more useful. Whereas the Mac is cursed with standards like TEXT, PICT, and numerous others, all of which are self-identifying. That's why drag-and-drop is NOT a kludge. You're confusing the simple steps needed to tell the Finder that a pre-7.0 application can open non-native files with the actual implementation of that feature. Presumably, any new application will contain an exhaustive list of types it understands, now that drag-and-drop is available. -- -------------------------------------------------------------------------- -- INTEL 80x86: Just say NOP -- Internet: stevep@wrq.com -- AOL: Spoole -- --------------------------------------------------------------------------
stevep@wrq.com (Steve Poole) (06/20/91)
In article <1991Jun18.125532.3766@NCoast.ORG> davewt@NCoast.ORG (David Wright) writes: > Sounds just like the Amiga to me. I can drag an icon onto the icon >editor's window and it will know to load the icon up. And the "icon alias" >sounds just like the "Leave Out" option of WorkBench too. No, aliases are pointers to files, folders, or disks. For example, I can create aliases to Word and leave them on my desktop, in an applications folder, and under the Apple menu. No matter where the real Word application goes, the aliases will be treated as if they were the application. One cool use is to put an alias to a file on floppy onto a mounted volume. When the alias is used, the system prompts for the correct volume to be mounted. -- -------------------------------------------------------------------------- -- INTEL 80x86: Just say NOP -- Internet: stevep@wrq.com -- AOL: Spoole -- --------------------------------------------------------------------------
gblock@csd4.csd.uwm.edu (Gregory R Block) (06/20/91)
From article <1991Jun19.154113.28723@news.iastate.edu>, by taab5@isuvax.iastate.edu (Marc Barrett): > To solve this problem, one additional selection needs to be added to > the "Show By" options in the Workbench 2.0 menus. The new option could > be called "Show By Default Icon" (or something similar), and work work That, and the ability to change the "view by" settings GLOBALLY. I.E have the ability to click on the main WB screen, and select a view by setting that will adjust ALL windows to that. And a few more hotkeys are needed. Greg -- Socrates: "I drank WHAT????" LMFAP: "Next time you see me, it won't be me." Wubba: "A dream is nothing more than a wish dipped in chocolate and sprinkled with a little imagination." (From my poem, "A Dream") -Wubba
rjc@wookumz.gnu.ai.mit.edu (Ray Cromwell) (06/20/91)
In article <1991Jun19.154113.28723@news.iastate.edu> taab5@isuvax.iastate.edu writes: > > Drag-and-drop does sound interesting, but it ocurred to me that, in >order for drag-and-drop to work well on an Amiga, one additional feature >will have to be added. > > The problem is that on the Amiga, icons can be (and very often are) >quite large. Icons larger than about 30x30 (a typical, usable size on >a 640x200 Workbench) are common, and it is not unusual to find icons as >large as half of the screen. Icons this large can play havoc with a >feature like drag-and-drop, because when the user drags an unusually large >icon over a cluster of applications, the user will not be able to tell >which application will be launched when the icon is released. I partialy agree. He will be able to tell because the mouse pointer is still visible, all he has to do is align the pointer with the destination icon, however, I do see the "geometry" problem. It wouldn't be a problem if developers would use some common sense, don't make icons as big as the whole screen! It might look pretty, but don't do it. Optionally a user can drag an offending icon into an IconEdit window and chop it up. (Does the Mac have the equivelent of Amiga AppWindows ? I know it has AppIcons (drag and drop onto other icons), but what about dragging an Icon from Finder directly into Word's window and having Word autoload it) Generally Marc, a good suggestion, one that should be mailed to cbmvax.commodore.com. It's fairly easy to add. In the future, Commodore should warn developers not to use mega big icons. -- / INET:rjc@gnu.ai.mit.edu * // The opinions expressed here do not \ | INET:r_cromwe@upr2.clu.net | \X/ in any way reflect the views of my self.| \ UUCP:uunet!tnc!m0023 * /
peter@sugar.hackercorp.com (Peter da Silva) (06/20/91)
In article <1991Jun19.201632.1386@milton.u.washington.edu> stevep@wrq.com (Steve Poole) writes: > No, aliases are pointers to files, folders, or disks. Oh. Symbolic links. Why don't you Mac people just speak English? -- Peter da Silva. `-_-' <peter@sugar.neosoft.com>. 'U` "Have you hugged your wolf today?"
peter@sugar.hackercorp.com (Peter da Silva) (06/20/91)
In article <50849@ut-emx.uucp> awessels@ccwf.cc.utexas.edu (Allen Wessels) writes: > In article <1991Jun19.000825.23509@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: > >Thank god, we don't have to play games with the likes of BinHex to interoperate > >with normal systems. > Uh, and neither do Mac users. I've transferred binaries straight from Unix > machines to my Mac, and downloaded Mac binaries directly from several IBM > BBS systems. Note that the accepted file formats on all the major > commercial online services is also binary. Oh, what happens to the resource fork? > Yep and so do we. If you've missed the posts, the format is PICT. The > file type information is used for the purposes of figuring out whether a > program can accept the drag and dropped file. If it's got the right format, why shouldn't it? All this "file type" business, and "resource forks", is a throwback to the old IBM and DEC operating systems. -- Peter da Silva. `-_-' <peter@sugar.neosoft.com>. 'U` "Have you hugged your wolf today?"
peter@sugar.hackercorp.com (Peter da Silva) (06/20/91)
In article <1991Jun19.103606.2496@ifi.unizh.ch> matija@amiga.ifi.unizh.ch (Matija Milostnik) writes: > Good point. This is a transitory solution I envision untill ALL programms have > drag-and-drop. Huh? With a drag-and-drop workbench interface no program would ever have to be changed, so what's the point? -- Peter da Silva. `-_-' <peter@sugar.neosoft.com>. 'U` "Have you hugged your wolf today?"
peter@sugar.hackercorp.com (Peter da Silva) (06/20/91)
In article <1991Jun19.154113.28723@news.iastate.edu> taab5@isuvax.iastate.edu writes: > The problem is that on the Amiga, icons can be (and very often are) > quite large. Yes, that's a general problem. I like the new IconEdit... what I typically do on installing a new program is open the program, use SNAP to cut an appropriate image form it, save it to IFF, and then IconEdit it to something useful. > Icons this large can play havoc with a > feature like drag-and-drop, because when the user drags an unusually large > icon over a cluster of applications, the user will not be able to tell > which application will be launched when the icon is released. Sure, since it's usually the *tools* that have the huge icons, it'll be easy to tell what little *project* you drop into it... No problem. > Anyway, the problem of large icons is serious enough to make > drag-and-drop useless in many, many circumstances, and this added > 'Show By ...' feature is one way to solve this. Sigh... -- Peter da Silva. `-_-' <peter@sugar.neosoft.com>. 'U` "Have you hugged your wolf today?"
navas@cory.Berkeley.EDU (David C. Navas) (06/20/91)
In article <1991Jun19.201632.1386@milton.u.washington.edu> stevep@wrq.com (Steve Poole) writes: >No, aliases are pointers to files, folders, or disks. For example, I can Like links? Like assigns? >create aliases to Word and leave them on my desktop, in an applications folder, >and under the Apple menu. No matter where the real Word application goes, >the aliases will be treated as if they were the application. One cool use We got links in 2.0, we've had assigns since the dawn of time. Of course (giggle) I've been doing things like this for awhile -- one of the VERY few advantages of having icons separate from programs. Now why did all of this get started? Oh, _now_ I understand the tickets to Texas and the billyclub.... ;) David Navas navas@cory.berkeley.edu 2.0 :: "You can't have your cake and eat it too." Also try c186br@holden, c260-ay@ara and c184-ap@torus
lsr@Apple.COM (Larry Rosenstein) (06/20/91)
In article <mykes.3652@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: >> Drag-and-drop seems to work fine on my Mac. Yep, here I go, just drag >>my application onto that ResEdit alias, and ResEdit opens up the application. >> > >Except your application must inform system 7 that it is capable of doing it. The information that System 7 uses for the drag-and-drop capability is the same information that links icons to files. So this capability works with existing applications. New applications are starting to take advantage of the wildcard capability. For example, the new version of DiskDoubler (a compression program) lets you drop any file on the app and it replaces the file with a compressed version (or uncompressed version as the case may be). -- Larry Rosenstein, Apple Computer, Inc. lsr@apple.com (or AppleLink: Rosenstein1)
awessels@ccwf.cc.utexas.edu (Allen Wessels) (06/20/91)
In article <1991Jun20.005257.9400@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >Oh, what happens to the resource fork? The file gets uploaded as a binary and downloaded into its component parts by the Mac. The conversion is handled by the download protocol, i.e. MacBinary. The host machine doesn't need to know about the resource fork, although when I'm downloading BinHexed files from my Sun account, I use mcvert to convert the BinHex file back to mac binary format. >If it's got the right format, why shouldn't it? How does the application know what is in the file? It is easier to check a 4 character file type resource than to read in some arbitrary number of bytes of the file to figure out what is in it. By having file types, it is easier to define standards, and surpass old ones. >All this "file type" business, and "resource forks", is a throwback to the >old IBM and DEC operating systems. Woo, such a substantive criticis I find the Mac use of resources pretty useful.
jbickers@templar.actrix.gen.nz (John Bickers) (06/20/91)
Quoted from <1991Jun19.154113.28723@news.iastate.edu> by taab5@isuvax.iastate.edu (Marc Barrett): > Drag-and-drop does sound interesting, but it ocurred to me that, in > order for drag-and-drop to work well on an Amiga, one additional feature The Ami already does something similar to the motions of this drag and drop, with the shift-click scheme (that has the additional advantage of allowing more than one argument file). > large as half of the screen. Icons this large can play havoc with a > feature like drag-and-drop, because when the user drags an unusually large Rubbish. If you can point and click these icons with the mouse, you can drop other icons on them. The "hot spot" of the icon when you release it over other icons could be the same as that of the mouse. > To solve this problem, one additional selection needs to be added to > the "Show By" options in the Workbench 2.0 menus. The new option could Real fun when using floppies, to be switching from real .info files to something else then back again, eh? > moment. Anyway, the problem of large icons is serious enough to make > drag-and-drop useless in many, many circumstances, and this added It is useless in many many points of view, no matter what the size of the icons. What might be nice is a way to do the shift-double- click thing entirely with the mouse, rather than having to go to the keyboard. > \ The great thing about standards is that / -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Endless variations, make it all seem new" - Devo. ***
dant@ryptyde.UUCP (Daniel Tracy) (06/20/91)
Responding to the following: >You're mixing up an interface tool with the inappropriate use of a metaphor. >A properly implemented "drag and drop" interface here would have an "eject" >icon that you dropped the disk onto. Dropping it in the trash would instead >format the disk. I can imagine Apple changing that after all these years. Users save their important documents onto floppy and drag it to the trash can only to get a dialog box saying "Reformatting Diskette..."
dant@ryptyde.UUCP (Daniel Tracy) (06/20/91)
Responding to the following: "> That's bull. Maybe if you would've read it properly. Well, actually, he sort of explained it poorly. And even he admits it's a kludge." 1) I'm sorry if that sounded like a flame, I must have had too much fruit that day. :-) 2) No, it's not a kludge. FREF resources have been used as long as I can remember to denote what apps can open what types of files. "> This is impossible on the Amiga, of course, Of course. It's impossible to pass a file to an application when you launch it (clue: it's not... you use shift-doubleclick)." I meant that it's impossible for the Workbench to know what types of files another app can open (unless more than one file can be created as a reference to each file?), and thus easily determine what can be dropped on what. "> as they don't HAVE resources Thank god, we don't have to play games with the likes of BinHex to interoperate with normal systems." hehe. You WISH you had resources! :-) I hate it when things akin to this is used as an argument. "I'm glad we don't have that feature, because we wouldn't know how to handle it anyway, nor would we want to. Too troublesome to have that kind of power". Yes, our file system is highly nonstandard, but very powerful.
dant@ryptyde.UUCP (Daniel Tracy) (06/20/91)
Responding to the following: "Sounds just like the Amiga to me. I can drag an icon onto the icon editor's window and it will know to load the icon up. And the "icon alias" sounds just like the "Leave Out" option of WorkBench too." No, I don't mean loading a program by dragging an icon, nor do I mean opening a document with its application the same way. I mean making another application (whether presently open or not) open a document that IT DIDN'T CREATE, and having the OS know what KINDS of files every application supports, so it doesn't let users open say a sound file into a Paint program (the Paint program would just ignore that anyway).
robart@agora.rain.com (Robert Barton) (06/20/91)
In article <1991Jun19.201632.1386@milton.u.washington.edu> stevep@wrq.com (Steve Poole) writes: >No, aliases are pointers to files, folders, or disks. For example, I can >create aliases to Word and leave them on my desktop, in an applications folder, >and under the Apple menu. No matter where the real Word application goes, >the aliases will be treated as if they were the application. One cool use >is to put an alias to a file on floppy onto a mounted volume. When the alias >is used, the system prompts for the correct volume to be mounted. This sounds like "ASSIGN" on the Amiga.
peterk@cbmger.UUCP (Peter Kittel GERMANY) (06/20/91)
In article <1991Jun19.154113.28723@news.iastate.edu> taab5@isuvax.iastate.edu writes: > > Drag-and-drop does sound interesting, but it ocurred to me that, in >order for drag-and-drop to work well on an Amiga, one additional feature >will have to be added. > > The problem is that on the Amiga, icons can be (and very often are) >quite large. Icons larger than about 30x30 (a typical, usable size on >a 640x200 Workbench) are common, and it is not unusual to find icons as >large as half of the screen. Icons this large can play havoc with a >feature like drag-and-drop, because when the user drags an unusually large >icon over a cluster of applications, the user will not be able to tell >which application will be launched when the icon is released. Yes he is, because it is so simple: It's just the icon under the mouse pointer that becomes the destination. You have the same problem also today when you have selected all icons inside a window and want to drag them into another one. Then you hold Shift depressed, click on one of the icons and drag it to the destination. The other icons will move in parallel to really weird places, but will end up in the same drawer/window as the first one. > To solve this problem, one additional selection needs to be added to >the "Show By" options in the Workbench 2.0 menus. Not necessary, I think. BTW, may I express my humbly opinion to the software producers, that TOO big icons are really annoying? They take away place on your Workbench, they need always an own window for themselves, because no other icon finds place besides them, and you have to do excessive front and back clicking to get to other icons. This is not fair and friendly. -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
peterk@cbmger.UUCP (Peter Kittel GERMANY) (06/20/91)
In article <1991Jun19.201632.1386@milton.u.washington.edu> stevep@wrq.com (Steve Poole) writes: >In article <1991Jun18.125532.3766@NCoast.ORG> davewt@NCoast.ORG (David Wright) writes: >> Sounds just like the Amiga to me. I can drag an icon onto the icon >>editor's window and it will know to load the icon up. And the "icon alias" >>sounds just like the "Leave Out" option of WorkBench too. > >No, aliases are pointers to files, folders, or disks. For example, I can >create aliases to Word and leave them on my desktop, in an applications folder, >and under the Apple menu. No matter where the real Word application goes, >the aliases will be treated as if they were the application. One cool use >is to put an alias to a file on floppy onto a mounted volume. When the alias >is used, the system prompts for the correct volume to be mounted. :-) :-) You just explained how "Leave out" works on the Amiga OS 2.0! Now I guess, it's really not alike, but perhaps identical? :-) -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
rjc@wookumz.gnu.ai.mit.edu (Ray Cromwell) (06/20/91)
In article <73@ryptyde.UUCP> dant@ryptyde.UUCP (Daniel Tracy) writes: >Responding to the following: > >"Sounds just like the Amiga to me. I can drag an icon onto the icon >editor's window and it will know to load the icon up. And the "icon alias" >sounds just like the "Leave Out" option of WorkBench too." > >No, I don't mean loading a program by dragging an icon, nor do I mean >opening a document with its application the same way. I mean making >another application (whether presently open or not) open a document >that IT DIDN'T CREATE, and having the OS know what KINDS of files >every application supports, so it doesn't let users open say a sound >file into a Paint program (the Paint program would just ignore that >anyway). This is something the application should decid at run time, not the OS. For instance, I can load executables into most Amiga text editors and patch them. I can load IFF files and edit the headers if I want. I would be really fustrated if the OS refused to let me drop ANY file into a text editor. I don't think the Mac's drag and drop allows you to drop an icon into an Application's window and have it load it. The "icon alias" sounds like a link in the filesystem rather than a true alias done by software. This means the GUI has to parse more files in the directory tree whereas a software alias would be "instantaneous" (cause it wouldn't be saved n the directory) Now the Amiga has aliases, assigns, environment variables, and now soft and hard links. -- / INET:rjc@gnu.ai.mit.edu * // The opinions expressed here do not \ | INET:r_cromwe@upr2.clu.net | \X/ in any way reflect the views of my self.| \ UUCP:uunet!tnc!m0023 * /
taab5@isuvax.iastate.edu (Marc Barrett) (06/21/91)
In article <4576.tnews@templar.actrix.gen.nz>, jbickers@templar.actrix.gen.nz (John Bickers) writes: > What might be nice is a way to do the shift-double- > click thing entirely with the mouse, rather than having to go to > the keyboard. You already can do this. If you have a three-button mouse, there is a program floating around which allows the third button to act as the shift key, for selecting multiple icons. > >> \ The great thing about standards is that / >-- >*** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** >*** "Endless variations, make it all seem new" - Devo. *** ------------------------------------------------------------- / Marc Barrett -MB- | BITNET: XGR39@ISUVAX.BITNET / / ISU COM S Student | Internet: XGR39@CCVAX.IASTATE.EDU / ------------------------------------------------------------ \ The great thing about standards is that / \ there are so many of them to choose from. / -------------------------------------------------------
peter@Sugar.NeoSoft.com (Peter da Silva) (06/21/91)
In article <50885@ut-emx.uucp> awessels@ccwf.cc.utexas.edu (Allen Wessels) writes: > The file gets uploaded as a binary and downloaded into its component parts > by the Mac. The conversion is handled by the download protocol, i.e. > MacBinary. The host machine doesn't need to know about the resource fork, > although when I'm downloading BinHexed files from my Sun account, I use > mcvert to convert the BinHex file back to mac binary format. In other words, the data and resource forks are merged and stored in a mini-archive. Like I said, it's an alien format to everyone else. One of the many design decisions that make Macs a cute little world isolated from the mainstream of computers. > How does the application know what is in the file? It is easier to check a > 4 character file type resource than to read in some arbitrary number of bytes > of the file to figure out what is in it. No, it's exactly the same operation to read an IFF file header and to scan a resource fork for a file type. Except that the file "type" in the IFF header allows interchange with other systems.The factt hat IFF is defined in a system independent manner is yet another advantage... > Woo, such a substantive criticis I find the Mac use of resources pretty > useful. Useful, yes. But it could have been done without breaking interoperability. -- Peter da Silva. `-_-' <peter@sugar.neosoft.com>. 'U` "Have you hugged your wolf today?"
peter@Sugar.NeoSoft.com (Peter da Silva) (06/21/91)
In article <72@ryptyde.UUCP> dant@ryptyde.UUCP (Daniel Tracy) writes: > "> This is impossible on the Amiga, of course, > Of course. It's impossible to pass a file to an application when you launch > it (clue: it's not... you use shift-doubleclick)." > I meant that it's impossible for the Workbench to know what types of files > another app can open (unless more than one file can be created as a > reference to each file?), and thus easily determine what can be dropped on > what. Why should the Workbench know that? Just kick off the program and let it decide if it likes what it sees. > hehe. You WISH you had resources! :-) I hate it when things akin to > this is used as an argument. "I'm glad we don't have that feature, because > we wouldn't know how to handle it anyway, nor would we want to. Too > troublesome to have that kind of power". Nonsense. I'll stick by this argument: gratuitous incompatibilities like multiple-forked files or files with special types should not be used lightly by any system designer who cares about the best interests of his users, because it will serve to isolate them from other systems. You have resource forks, IBM has their special file types, Sperry has 36-bit words. Each of you can point to the advantages of your particular chrome, but the all act as a barrier to interoperability. And none of it is necessary... any of these "features" can be implemented transparently at an application level without locking people into their own little worlds. > Yes, our file system is highly nonstandard, but very powerful. Oh? Where are the named pipes? How about the built-in ISAM? And the Fortran carriage control files? Everyone has their little "bonuses". The question is, are they worth it? -- Peter da Silva. `-_-' <peter@sugar.neosoft.com>. 'U` "Have you hugged your wolf today?"
sho@gibbs.physics.purdue.edu (Sho Kuwamoto) (06/21/91)
In article <1991Jun20.180421.22074@Sugar.NeoSoft.com> peter@Sugar.NeoSoft.com (Peter da Silva) writes: >In article <72@ryptyde.UUCP> dant@ryptyde.UUCP (Daniel Tracy) writes: >> I meant that it's impossible for the Workbench to know what types of files >> another app can open (unless more than one file can be created as a >> reference to each file?), and thus easily determine what can be dropped on >> what. > >Why should the Workbench know that? Just kick off the program and let it >decide if it likes what it sees. On the mac, the OS gives visual feedback to let you know when something will be dropped into something else. When moving a file into a folder, the folder lights up when the file is positioned correctly. When dragging a file into the trash, the trash can lights up when the file has been positioned correctly. In the same way, the program's icon lights up, but only if the file type is something the program can handle. This may seem like a minute detail, but it's these many minute details which add up to a user interface. In this case, it's nice to have immediate visual feedback about whether the program will accept your file or not. This is just a nicety. There is no reason that it could not work as you suggest. >Nonsense. I'll stick by this argument: gratuitous incompatibilities like >multiple-forked files or files with special types should not be used lightly >[...] >And none of it is necessary... any of these "features" can be implemented >transparently at an application level without locking people into their own >little worlds. I am a mac enthusiast, and I agree. I like resources a lot, but resources should be built on top of the file system, not into the file system. -Sho -- sho@physics.purdue.edu
aru@mentor.cc.purdue.edu (Sri-Man) (06/21/91)
In article <1991Jun19.224736.15828@mintaka.lcs.mit.edu> rjc@wookumz.gnu.ai.mit.edu (Ray Cromwell) writes: >> >> The problem is that on the Amiga, icons can be (and very often are) >>quite large. Icons larger than about 30x30 (a typical, usable size on >the whole screen! It might look pretty, but don't do it. Optionally >a user can drag an offending icon into an IconEdit window and chop it up. Why can't the operating system be smart enough to resize the icon when you move it? When you start moving the icon then it should resize to some default size and then you can drop it wherever its needed. Sounds like a good compromise to those who want big icons and still be able to use the drop feature. Sri aru@mentor.cc.purdue.edu
stevep@wrq.com (Steve Poole) (06/21/91)
In article <1991Jun20.004306.9309@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <1991Jun19.201632.1386@milton.u.washington.edu> stevep@wrq.com (Steve Poole) writes: >> No, aliases are pointers to files, folders, or disks. > >Oh. Symbolic links. > >Why don't you Mac people just speak English? Yeah, them gol durn Unix yanks, too. -- -------------------------------------------------------------------------- -- INTEL 80x86: Just say NOP -- Internet: stevep@wrq.com -- AOL: Spoole -- --------------------------------------------------------------------------
stevep@wrq.com (Steve Poole) (06/21/91)
In article <1991Jun20.160550.27873@mintaka.lcs.mit.edu> rjc@wookumz.gnu.ai.mit.edu (Ray Cromwell) writes: > This is something the application should decid at run time, not the OS. >For instance, I can load executables into most Amiga text editors and >patch them. I can load IFF files and edit the headers if I want. I would >be really fustrated if the OS refused to let me drop ANY file into a >text editor. The Finder is NOT the OS. Obviously, applications do decide at run time what they'd like to open. Drag and drop in the Finder allows the user to avoid the step of launching an application only to find that it doesn't understand that file type. If the app will open that file type at all then it can be opened via drag and drop. It's just another timesaver, not a fascist device. -- -------------------------------------------------------------------------- -- INTEL 80x86: Just say NOP -- Internet: stevep@wrq.com -- AOL: Spoole -- --------------------------------------------------------------------------
peter@Sugar.NeoSoft.com (Peter da Silva) (06/21/91)
In article <1991Jun20.231445.1371@milton.u.washington.edu> stevep@wrq.com (Steve Poole) writes: > Drag and drop in the Finder allows the user to avoid the step of launching > an application only to find that it doesn't understand that file type. I guess that makes sense when launching an application is such an expensive job. -- Peter da Silva. `-_-' <peter@sugar.neosoft.com>. 'U` "Have you hugged your wolf today?"
s902113@minyos.xx.rmit.oz.au (Luke Mewburn) (06/21/91)
robart@agora.rain.com (Robert Barton) writes: >In article <1991Jun19.201632.1386@milton.u.washington.edu> stevep@wrq.com (Steve Poole) writes: >>No, aliases are pointers to files, folders, or disks. For example, I can >>create aliases to Word and leave them on my desktop, in an applications folder, >>and under the Apple menu. No matter where the real Word application goes, >>the aliases will be treated as if they were the application. One cool use >>is to put an alias to a file on floppy onto a mounted volume. When the alias >>is used, the system prompts for the correct volume to be mounted. > This sounds like "ASSIGN" on the Amiga. Actually, aliases are _MUCH_ more powerful. Assign can _only_ be used for folders or volumes, _not_ files. But, one good use (using ASSIGN) on the Amiga is to make assignments starting with a ".", so when listed in a file requester which handles assign-ed paths, they appear at the top. I do this on Music programs (MED3.1, ST clones, etc), to find my songs directory really fast... Getting back to the point, the mac idea of an Apple Menu in system seven is great - a bit like a 'dock', but not wasteful of desktop space. (I know that wasn't the idea in pre-sys. 7 days, but that is the Apple Menu's most powerful feature, IMHO, in sys 7)...
torrie@cs.stanford.edu (Evan Torrie) (06/21/91)
rjc@wookumz.gnu.ai.mit.edu (Ray Cromwell) writes: >For instance, I can load executables into most Amiga text editors and >patch them. Of course, the "average" user is really going to want this feature :| >I can load IFF files and edit the headers if I want. I would >be really fustrated if the OS refused to let me drop ANY file into a >text editor. Just add a '****' wildcard resource to your text editor, and all will be dandy. In terms of the average users, I wager most people would be confused, and annoyed if they could drag anything onto any application, only to find out when the application launched that it says "Sorry, I can't open this file". -- ------------------------------------------------------------------------------ Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu Murphy's Law of Intelism: Just when you thought Intel had done everything possible to pervert the course of computer architecture, they bring out the 860
es1@cunixb.cc.columbia.edu (Ethan Solomita) (06/21/91)
In article <1991Jun21.021339.11214@minyos.xx.rmit.oz.au> s902113@minyos.xx.rmit.oz.au (Luke Mewburn) writes: >robart@agora.rain.com (Robert Barton) writes: > >>In article <1991Jun19.201632.1386@milton.u.washington.edu> stevep@wrq.com (Steve Poole) writes: >>>No, aliases are pointers to files, folders, or disks. For example, I can >>>create aliases to Word and leave them on my desktop, in an applications folder, >>>and under the Apple menu. No matter where the real Word application goes, >>>the aliases will be treated as if they were the application. One cool use >>>is to put an alias to a file on floppy onto a mounted volume. When the alias >>>is used, the system prompts for the correct volume to be mounted. > > >> This sounds like "ASSIGN" on the Amiga. > > Actually, aliases are _MUCH_ more powerful. Assign can _only_ be used for >folders or volumes, _not_ files. But, one good use (using ASSIGN) on the >Amiga is to make assignments starting with a ".", so when listed in a file >requester which handles assign-ed paths, they appear at the top. I do this >on Music programs (MED3.1, ST clones, etc), to find my songs directory >really fast... > Getting back to the point, the mac idea of an Apple Menu in system seven >is great - a bit like a 'dock', but not wasteful of desktop space. (I know >that wasn't the idea in pre-sys. 7 days, but that is the Apple Menu's most >powerful feature, IMHO, in sys 7)... It is very lucky for us then that WB2.0 has the ability to make symbolic links. 8-) -- Ethan "...Know-Nothing-Bozo the Non-Wonder Dog, an animal so stupid that it had been sacked from one of Will's own commercials for being incapable of knowing which dog food it was supposed to prefer, despite the fact that the meat in all the other bowls had engine oil poured all over it."
dant@ryptyde.UUCP (Daniel Tracy) (06/21/91)
Responding to the following: "This is something the application should decid at run time, not the OS. For instance, I can load executables into most Amiga text editors and patch them. I can load IFF files and edit the headers if I want. I would be really fustrated if the OS refused to let me drop ANY file into a text editor." If the text editor will normally open any file and edit it, then the OS will allow you to drop any file on the text editor icon. It is NOT the OS's decision, it is the application's decision. "I don't think the Mac's drag and drop allows you to drop an icon into an Application's window and have it load it." Since, on a Macintosh, a window represents a document, you wouldn't be opening the dragged file, but rather appending documents. The window is a document in itself, so why would this be wanted? It appears by the above that the Amiga uses a metaphor in which windows represent programs. How do you open more than one document at a time in a single application? "The "icon alias" sounds like a link in the filesystem rather than a true alias done by software. This means the GUI has to parse more files in the directory tree whereas a software alias would be "instantaneous" (cause it wouldn't be saved n the directory)" An alias on a Macintosh is truly a file. The file has a type indicating it is an alias, and when programs pass this file to the File Manager, the function is performed on the real file. The Alias functions in all ways as the original, and may be placed anywhere, on any volume, moved, renamed, etc. You may even rename the original. The OS will maintain the "link".
jbickers@templar.actrix.gen.nz (John Bickers) (06/21/91)
Quoted from <1991Jun20.111358.759@agora.rain.com> by robart@agora.rain.com (Robert Barton): > In article <1991Jun19.201632.1386@milton.u.washington.edu> stevep@wrq.com (Steve Poole) writes: > >No, aliases are pointers to files, folders, or disks. For example, I can > This sounds like "ASSIGN" on the Amiga. About as brilliant an "innovation" as the OS/2 version of our run-time libraries... :) Does the Mac OS have run-time libraries? -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Endless variations, make it all seem new" - Devo. ***
matija@amiga.ifi.unizh.ch (Matija Milostnik) (06/21/91)
In article <1991Jun20.005413.9471@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <1991Jun19.103606.2496@ifi.unizh.ch> matija@amiga.ifi.unizh.ch (Matija Milostnik) writes: >> Good point. This is a transitory solution I envision untill ALL programms >>have drag-and-drop. > >Huh? With a drag-and-drop workbench interface no program would ever have to >be changed, so what's the point? Not really true. Drag-and-drop is far more complex as just starting an appliction. The full drag-and-drop concept doesnt apply just to the start, but handles the incoming request during the hole sesion. Let me explane it. It a long one. As far as we look at the start of a dropped document on a _not yet_ started application, I completelly agree with you, there is no need to change a line in the application code. The program will have a workbench message passed, as a shift-clik start. Now take an already running application and drop a project on it. How can you handle this situation? You have to notify your appliction someone just dropped something. This can be done in two differnt ways: a) you get an arexx message b) Intuition sends an IDCMP message In both cases the application has to deal with the incomming message and act adequatelly. This is done in a) installing an arexx port for you or in b) with an appropriate GetMsg/ReplyMsg and case-select. The difficul management fo drops in a running appliction should be standarised and a claen and stable interface defined. Another question is 'how to drop something on a screen that isnt the WB-screen?' I didnt figure how to do it in an reasonably way. Any suggestion? My proposal for a drop-requester in asl.library is a solution to have the drop alternative in existing programms _now_ and wait for the programmer to implement it. You see, there is a need for changing program code, but with some magic we can offer some alternatives today, waiting for tomorow.:-) >Peter da Silva. `-_-' <peter@sugar.neosoft.com>. bye Matija +-------------------------------------------------------+ | Q: What's the best way to catch a rabbit? | | A: Hide into a bush and mimic the voice of a carrot. | +-------------------------------------------------------+
matija@amiga.ifi.unizh.ch (Matija Milostnik) (06/21/91)
In article <1394@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: >BTW, may I express my humbly opinion to the software producers, >that TOO big icons are really annoying? They take away place on >your Workbench, they need always an own window for themselves, [deleted] >This is not fair and friendly. As I recall somewere in the RKM there _is_ a plea for small icons. So it's a programmer fault if he designs huges icons. >Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... e BBBBBBBBB B B B B BBBBBBBB Y Y EEEE B B Y Y E E B B Y Y EEEEEE BBBBBBBBB YYYY E Y EEE Y Y YYY Is this big ? Bye Matija +-------------------------------------------------------+ | Q: What's the best way to catch a rabbit? | | A: Hide into a bush and mimic the voice of a carrot. | +-------------------------------------------------------+
rjc@wookumz.gnu.ai.mit.edu (Ray Cromwell) (06/21/91)
In article <81@ryptyde.UUCP> dant@ryptyde.UUCP (Daniel Tracy) writes: >Responding to the following: > >"I don't think the Mac's drag and drop allows you to drop an icon into >an Application's window and have it load it." > >Since, on a Macintosh, a window represents a document, you wouldn't be >opening the dragged file, but rather appending documents. The window is >a document in itself, so why would this be wanted? It appears by the above >that the Amiga uses a metaphor in which windows represent programs. How >do you open more than one document at a time in a single application? Most Amiga programs allow you to have as many documents open as you'd like. For the ones that don't, you just run multiple copies of them. If a program opens a window (let's take the example of an icon editor) and I drop a icon in it, it should start editing that icon. How do you append icons or pictures? For instance, if I had a paint program open, I should be able to drag an icon of a picture into it's window and have the program load this picture as the next frame in the animation. (This is really moot since the vast majority of Amiga paint programs open their own screens, not windows.) Dragging a document icon into an editor/word processor should be the equivelent of pasting. -- / INET:rjc@gnu.ai.mit.edu * // The opinions expressed here do not \ | INET:r_cromwe@upr2.clu.net | \X/ in any way reflect the views of my self.| \ UUCP:uunet!tnc!m0023 * /
peterk@cbmger.UUCP (Peter Kittel GERMANY) (06/21/91)
In article <1991Jun21.021339.11214@minyos.xx.rmit.oz.au>, s902113@minyos.xx.rmit.oz.au (Luke Mewburn) writes: > robart@agora.rain.com (Robert Barton) writes: > > > This sounds like "ASSIGN" on the Amiga. > > Actually, aliases are _MUCH_ more powerful. Assign can _only_ be used for > folders or volumes, _not_ files. You're WRONG. It's a not often used feature, but the Amiga ASSIGN also does work for files! It's only not very comfortable to include that colon after the name always, using the shift key. With today's Shell, the Alias is more convenient. But you can't say it can't be done. (Sorry, can't crosspost to that Mac newsgroup :-) -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
cseaman@sequent.com (06/22/91)
stevep@wrq.com (Steve Poole) writes: < rjc@wookumz.gnu.ai.mit.edu (Ray Cromwell) writes: < > This is something the application should decid at run time, not the OS. < >For instance, I can load executables into most Amiga text editors and < >patch them. I can load IFF files and edit the headers if I want. I would < >be really fustrated if the OS refused to let me drop ANY file into a < >text editor. < < The Finder is NOT the OS. Obviously, applications do decide at run time < what they'd like to open. Drag and drop in the Finder allows the user < to avoid the step of launching an application only to find that it doesn't < understand that file type. If the app will open that file type at all < then it can be opened via drag and drop. It's just another timesaver, < not a fascist device. This topic epitomizes my main beef with the Mac 'philosophy'. Any user with a lick of common sense isn't even going to TRY to 'drag-and-drop' a file into an application, unless they believe (or at least suspect) that the application will know what to do with it. The 'Mac way', however, credits the user with the intelligence of a rock. It not only condones ignorance on the part of the user, it encourages and perpetuates it. 'Drag and drop in the Finder allows the user to avoid the step of launching an application...' Pshaw. 'Drag-and-drop' in the Finder allows the user to remain blissfully free of the ravages of intelligence. Chris -- Chris (Insert phrase here) Seaman | /--\ cseaman@sequent.com <or> | | | "This is as real as ...!uunet!sequent!cseaman | | \ | your so-called 'Life' gets" The Home of the Killer Smiley | \--X__
taab5@isuvax.iastate.edu (Marc Barrett) (06/22/91)
In article <1991Jun21.140245.19813@ifi.unizh.ch>, matija@amiga.ifi.unizh.ch (Matija Milostnik) writes: >In article <1394@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: >>BTW, may I express my humbly opinion to the software producers, >>that TOO big icons are really annoying? They take away place on >>your Workbench, they need always an own window for themselves, >[deleted] >>This is not fair and friendly. > >As I recall somewere in the RKM there _is_ a plea for small icons. >So it's a programmer fault if he designs huges icons. I don't agree (do I ever agree? :-) Remember, there are an awful lot of icon-making tools available, most of them easy enough for the novice to use. I have found that most of the big icons I've come across were created for icon-less Shareware and PD programs by the librarians of Amiga user group software libraries. At any rate, large icons will always exist, as long as the Amiga's Workbench allows them. There is no way anyone is going to prevent people from making large icons for their programs from the many tools available, so the best way to take care of the problem with large icons is to include a feature in the Workbench menus similar to the MAC's "Show By Small Icon" menu option. > >>Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... > >e >BBBBBBBBB > B B > B B > BBBBBBBB Y Y EEEE > B B Y Y E E > B B Y Y EEEEEE >BBBBBBBBB YYYY E > Y EEE > Y Y > YYY >Is this big ? > >Bye > Matija >+-------------------------------------------------------+ >| Q: What's the best way to catch a rabbit? | >| A: Hide into a bush and mimic the voice of a carrot. | >+-------------------------------------------------------+ ------------------------------------------------------------- / Marc Barrett -MB- | BITNET: XGR39@ISUVAX.BITNET / / ISU COM S Student | Internet: XGR39@CCVAX.IASTATE.EDU / ------------------------------------------------------------ \ The great thing about standards is that / \ there are so many of them to choose from. / -------------------------------------------------------
231b3678@fergvax.unl.edu (Phil Dietz) (06/22/91)
In <1394@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: >In article <1991Jun19.154113.28723@news.iastate.edu> taab5@isuvax.iastate.edu writes: >> >> Drag-and-drop does sound interesting, but it ocurred to me that, in >>order for drag-and-drop to work well on an Amiga, one additional feature >>will have to be added. >> >> The problem is that on the Amiga, icons can be (and very often are) >>quite large. Icons larger than about 30x30 (a typical, usable size on >>a 640x200 Workbench) are common, and it is not unusual to find icons as >>large as half of the screen. Icons this large can play havoc with a >>feature like drag-and-drop, because when the user drags an unusually large >>icon over a cluster of applications, the user will not be able to tell >>which application will be launched when the icon is released. >Yes he is, because it is so simple: It's just the icon under the mouse >pointer that becomes the destination. You have the same problem also >today when you have selected all icons inside a window and want to drag >them into another one. Then you hold Shift depressed, click on one of >the icons and drag it to the destination. The other icons will move in >parallel to really weird places, but will end up in the same drawer/window >as the first one. >> To solve this problem, one additional selection needs to be added to >>the "Show By" options in the Workbench 2.0 menus. Maybe Commodore should implement the MAC's "Show by Small ICON" method. Only a simple scaling function would be needed to say scale icons to a certain nxm size like (20 x 20). a 80 x 70 icon would scale to 20 x 20 as well as a 23 x 23 icon. All icons larger than 20 x 20 would be scaledd appropriately to be 20 x 20. Easy. And it allows easy multiple-drag-and-drop. ---- Quote #5 Phil Dietz "Phil is the man with a plan" 231b3678@fergvax.unl.edu -- Confucious University of Nebraska
es1@cunixb.cc.columbia.edu (Ethan Solomita) (06/22/91)
In article <1991Jun21.184235.29572@news.iastate.edu> taab5@isuvax.iastate.edu writes: > > I don't agree (do I ever agree? :-) Remember, there are an awful lot >of icon-making tools available, most of them easy enough for the novice >to use. I have found that most of the big icons I've come across were >created for icon-less Shareware and PD programs by the librarians of Amiga >user group software libraries. > Marc, as I noticed when I got my 3000, the IconEdit program limits the size of your icon to something quite nice and tidy. -- Ethan "...Know-Nothing-Bozo the Non-Wonder Dog, an animal so stupid that it had been sacked from one of Will's own commercials for being incapable of knowing which dog food it was supposed to prefer, despite the fact that the meat in all the other bowls had engine oil poured all over it."
jbickers@templar.actrix.gen.nz (John Bickers) (06/22/91)
Quoted from <13824@mentor.cc.purdue.edu> by aru@mentor.cc.purdue.edu (Sri-Man): > Why can't the operating system be smart enough to resize the icon when you > move it? When you start moving the icon then it should resize to some default Because some of the time when you move an icon, you are NOT going to "drag and drop" it - you are trying to change it's position on the Workbench. When you're doing this, you need to have the proper icon representation, so you can position it in a pixel perfect manner. > Sri -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Endless variations, make it all seem new" - Devo. ***
dant@ryptyde.UUCP (Daniel Tracy) (06/22/91)
Responding to the following: "> Yes, our file system is highly nonstandard, but very powerful. Oh? Where are the named pipes? How about the built-in ISAM? And the Fortran carriage control files?" Please explain what each is and maybe I can provide an answer.
dant@ryptyde.UUCP (Daniel Tracy) (06/22/91)
Responding to the following: "No, it's exactly the same operation to read an IFF file header and to scan a resource fork for a file type. Except that the file "type" in the IFF header allows interchange with other systems.The factt hat IFF is defined in a system independent manner is yet another advantage..." No, the file type of a Macintosh file is kept in the file header as well.
gblock@csd4.csd.uwm.edu (Gregory R Block) (06/22/91)
From article <1991Jun21.025704.27445@neon.Stanford.EDU>, by torrie@cs.stanford.edu (Evan Torrie): >>For instance, I can load executables into most Amiga text editors and >>patch them. > > Of course, the "average" user is really going to want this feature :| Well, you make a choice. You either gear the gui completely for the average fool ( insert smiley ), which eventually makes the OS a pain to the power user who likes features like this, or you leave it open enough that the average user has to deal with the choices he makes, without an os to slap his hand and say "no, bad boy." > Just add a '****' wildcard resource to your text editor, and all > will be dandy. Sounds like a kludge to get around something the OS doesn't want you to do to this mac user. And amiga user. And once 24bit support is better on the Amiga, I'm dropping my mac like a hot potato. > In terms of the average users, I wager most people would be confused, > and annoyed if they could drag anything onto any application, only > to find out when the application launched that it says > "Sorry, I can't open this file". Like I said, deal with what you do, or have the os stand over your shoulder. Frankly, NOBODY stands over MY shoulder. :) -- Socrates: "I drank WHAT????" LMFAP: "Next time you see me, it won't be me." Wubba: "A dream is nothing more than a wish dipped in chocolate and sprinkled with a little imagination." (From my poem, "A Dream") -Wubba
peter@Sugar.NeoSoft.com (Peter da Silva) (06/22/91)
In article <81@ryptyde.UUCP> dant@ryptyde.UUCP (Daniel Tracy) writes: > It appears by the above > that the Amiga uses a metaphor in which windows represent programs. How > do you open more than one document at a time in a single application? You run the application multiple times, usually. Multitasking strikes again... Since with shared libraries and shared text the application itself is usually small, this is rarely a problem. Certainly you can run more programs on an Amiga than on a Mac with the same amount of RAM. -- Peter da Silva. `-_-' <peter@sugar.neosoft.com>. 'U` "Have you hugged your wolf today?"
peter@Sugar.NeoSoft.com (Peter da Silva) (06/22/91)
In article <1991Jun21.134801.19644@ifi.unizh.ch> matija@amiga.ifi.unizh.ch (Matija Milostnik) writes: > Drag-and-drop is far more complex as just starting an appliction. The full > drag-and-drop concept doesnt apply just to the start, but handles the incoming > request during the hole sesion. Seems like overkill, but 2.0 has already implemented the second part. The first part should be there as well. Capiche? -- Peter da Silva. `-_-' <peter@sugar.neosoft.com>. 'U` "Have you hugged your wolf today?"
awessels@ccwf.cc.utexas.edu (Allen Wessels) (06/22/91)
In article <1991Jun21.181522.26401@sequent.com> cseaman@sequent.com writes: >This topic epitomizes my main beef with the Mac 'philosophy'. Any user >with a lick of common sense isn't even going to TRY to 'drag-and-drop' a >file into an application, unless they believe (or at least suspect) that >the application will know what to do with it. The 'Mac way', however, >credits the user with the intelligence of a rock. It not only condones >ignorance on the part of the user, it encourages and perpetuates it. Not only does Apple encourage ignorance on the part of most users, it carefully isolates the user from information. Let me tell you, for the majority of Mac users, it is a good thing there is no standard CLI. One reason the OS restricts drag and drop is that users aren't very careful about what they are doing. It is far easier to add capabilities once the user is proficient than to expect them to navigate a myriad of possible actions. Mac users pay extra for those "guard rails" that define possible actions. >'Drag and drop in the Finder allows the user to avoid the step of >launching an application...' Pshaw. 'Drag-and-drop' in the Finder >allows the user to remain blissfully free of the ravages of >intelligence. Yep, ignorance can be expensive. On the other hand, I don't think the 40-odd users on our departmental network would be able to get up to speed with any other machine like the Mac allows. And you CAN eventually get behind the interface and work with the guts.
peter@Sugar.NeoSoft.com (Peter da Silva) (06/22/91)
Quoting the famous Daniel Tracy:
"Responding to the following:
"``No, it's exactly the same operation to read an IFF file header and
to scan a resource fork for a file type. Except that the file "type" in the
IFF header allows interchange with other systems.The factt hat IFF is
defined in a system independent manner is yet another advantage...''
"No, the file type of a Macintosh file is kept in the file header as
well."
-- <85@ryptyde.UUCP>
You managed to completely miss both of the points I made and fastened on
a single phrase that you don't care for.
Sigh.
--
Peter da Silva. `-_-' <peter@sugar.neosoft.com>.
'U` "Have you hugged your wolf today?"caw@miroc.Chi.IL.US (Christopher A. Wichura) (06/22/91)
In article <1991Jun21.021339.11214@minyos.xx.rmit.oz.au> s902113@minyos.xx.rmit.oz.au (Luke Mewburn) writes: >robart@agora.rain.com (Robert Barton) writes: > >>In article <1991Jun19.201632.1386@milton.u.washington.edu> stevep@wrq.com (Steve Poole) writes: >>>No, aliases are pointers to files, folders, or disks. For example, I can >>>create aliases to Word and leave them on my desktop, in an applications folder, >>>and under the Apple menu. No matter where the real Word application goes, >>>the aliases will be treated as if they were the application. One cool use >>>is to put an alias to a file on floppy onto a mounted volume. When the alias >>>is used, the system prompts for the correct volume to be mounted. > >> This sounds like "ASSIGN" on the Amiga. > > Actually, aliases are _MUCH_ more powerful. Assign can _only_ be used for >folders or volumes, _not_ files. But, one good use (using ASSIGN) on the 12> Assign ASGN: C:Type 12> ASGN: UUSPOOOL:LOGFILE (06/21-07:31:16) uucico,clout,caw REQUEST S D.cloutX2165 X.mirocX2166 caw - D.cloutX2165 0666 caw (06/21-07:31:19) uucico,clout,caw REQUESTED CY (06/21-07:31:21) uucico,clout,- OK Conversation complete (06/21-07:31:29) uucico,reaper,- Wrong Time To Call reaper (06/21-07:31:30) UUXQT,-,- Processed 0 files (06/21-08:30:00) uucico,AmigaUUCP,- Startup V1.13 (06/21-08:30:02) uucico,reaper,- Wrong Time To Call reaper . . . Who says you can't make an assign to a file on the Amiga? -=> CAW Christopher A. Wichura Multitasking. Just DO it. caw@miroc.chi.il.us (my amiga) ...the Amiga way... u12401@uicvm.uic.edu (school account)
aru@mentor.cc.purdue.edu (Sri Ramkrishna) (06/22/91)
In article <4618.tnews@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes: > > When you're doing this, you need to have the proper icon > representation, so you can position it in a pixel perfect manner. What about using a keystroke in combination? For instance, <amiga> and then the right button to move it. Its possible to do it. As long as you can redefine what key and key click. Sri
torrie@cs.stanford.edu (Evan Torrie) (06/22/91)
gblock@csd4.csd.uwm.edu (Gregory R Block) writes: >From article <1991Jun21.025704.27445@neon.Stanford.EDU>, by torrie@cs.stanford.edu (Evan Torrie): >>>For instance, I can load executables into most Amiga text editors and >>>patch them. >> >> Of course, the "average" user is really going to want this feature :| >Well, you make a choice. You either gear the gui completely for the >average fool ( insert smiley ), which eventually makes the OS a pain >to the power user who likes features like this, or you leave it open >enough that the average user has to deal with the choices he makes, >without an os to slap his hand and say "no, bad boy." Or you make it open enough that the power user CAN get these features if he wants them, but by default, it supports a more intuitive/user friendly method for the average user. >> Just add a '****' wildcard resource to your text editor, and all >> will be dandy. >Sounds like a kludge to get around something the OS doesn't want you >to do to this mac user. It really has nothing to do with the OS (actually the Finder GUI, which is hardly the OS). It's the application that doesn't want you to open files it wasn't designed to handle. So go rag on the application writer. For applications designed to do this sort of thing, (e.g. ResEdit, DiskDoubler etc), the ability to handle any type of file is already built in by the programmer. >And amiga user. And once 24bit support is >better on the Amiga, I'm dropping my mac like a hot potato. It could well be a cold potato by the time that happens. >> In terms of the average users, I wager most people would be confused, >> and annoyed if they could drag anything onto any application, only >> to find out when the application launched that it says >> "Sorry, I can't open this file". >Like I said, deal with what you do, or have the os stand over your >shoulder. Frankly, NOBODY stands over MY shoulder. :) Oftentimes, a guide over your shoulder can help prevent even the experienced user from making mistakes. -- ------------------------------------------------------------------------------ Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu "Lay me place and bake me pie, I'm starving for me gravy... Leave my shoes and door unlocked, I might just slip away - hey - just for the day."
gblock@csd4.csd.uwm.edu (Gregory R Block) (06/22/91)
From article <1991Jun22.071317.26217@neon.Stanford.EDU>, by torrie@cs.stanford.edu (Evan Torrie): > Or you make it open enough that the power user CAN get these features > if he wants them, but by default, it supports a more intuitive/user friendly > method for the average user. I had to wring necks on my Mac to get the power out of it I needed in Finder, and I would have died and been reborn as a small tree frog to have a good shell like the Amiga does. And with WB2.0, I never use the shell. That says, at least to me, that the new workbench gives me as much power as the shell used to. It's raw power that's important, not the power you can coax out of it if you babysit your computer for awhile. > It really has nothing to do with the OS (actually the Finder GUI, > which is hardly the OS). It's the application that doesn't want you > to open files it wasn't designed to handle. So go rag on the > application writer. For applications designed to do this sort of > thing, (e.g. ResEdit, DiskDoubler etc), the ability to handle any > type of file is already built in by the programmer. Okay, I tend to think of the OS as the Finder/WorkBench. Bad habit. :) True. I was under the understanding that finder limited you to loading into applications only those documents to which it was the creator... My mistake. > It could well be a cold potato by the time that happens. I expect that I'll have the support I'm looking for real soon. A few more boards, a few more 24bit programs, and my mac is gone. Putting my workbench on a 24bit display isn't important to me right now. I would like it, but it's not dreadfully necessary. I just need to be able to use whatever I pick well. And things are getting better by the week. >>Like I said, deal with what you do, or have the os stand over your >>shoulder. Frankly, NOBODY stands over MY shoulder. :) > > Oftentimes, a guide over your shoulder can help prevent even the > experienced user from making mistakes. So you either learn from your mistakes, and become a more powerful user, or you have the OS guide you. I've made my share of mistakes, and I can even know laugh about them, even though at the time I could have screamed. The solutions are simple if you open your eyes and look for them... But if you don't have to look then why bother? My mistakes have made me a better user. A mac user can't say that... not as much, anyways. Greg -- Socrates: "I drank WHAT????" LMFAP: "Next time you see me, it won't be me." Wubba: "A dream is nothing more than a wish dipped in chocolate and sprinkled with a little imagination." (From my poem, "A Dream") -Wubba
taab5@isuvax.iastate.edu (Marc Barrett) (06/22/91)
In article <1991Jun21.195627.13543@cunixf.cc.columbia.edu>, es1@cunixb.cc.columbia.edu (Ethan Solomita) writes: >In article <1991Jun21.184235.29572@news.iastate.edu> taab5@isuvax.iastate.edu writes: >> >> I don't agree (do I ever agree? :-) Remember, there are an awful lot >>of icon-making tools available, most of them easy enough for the novice >>to use. I have found that most of the big icons I've come across were >>created for icon-less Shareware and PD programs by the librarians of Amiga >>user group software libraries. >> > Marc, as I noticed when I got my 3000, the IconEdit >program limits the size of your icon to something quite nice and >tidy. I was referring to such programs as Brush2Icon, which are actually easier to use than IconEdit. With Brush2Icon, a person can whip up a brush with a paint program, then have the brush rapidly converted to an icon with one command. I don't make icons very often, but whenever I do, this method is the one I use. > -- Ethan > >"...Know-Nothing-Bozo the Non-Wonder Dog, an animal so stupid that it >had been sacked from one of Will's own commercials for being incapable >of knowing which dog food it was supposed to prefer, despite the fact >that the meat in all the other bowls had engine oil poured all over it." ------------------------------------------------------------- / Marc Barrett -MB- | BITNET: XGR39@ISUVAX.BITNET / / ISU COM S Student | Internet: XGR39@CCVAX.IASTATE.EDU / ------------------------------------------------------------ \ The great thing about standards is that / \ there are so many of them to choose from. / -------------------------------------------------------
jbickers@templar.actrix.gen.nz (John Bickers) (06/22/91)
Quoted from <13863@mentor.cc.purdue.edu> by aru@mentor.cc.purdue.edu (Sri Ramkrishna): > In article <4618.tnews@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes: > > > > When you're doing this, you need to have the proper icon > > representation, so you can position it in a pixel perfect manner. > > What about using a keystroke in combination? For instance, <amiga> and then Well, if you're going to use a key/mouse combo, then why not stick with the current shift-mouse thing for passing arguments to Workbench programs that we have now? If we're going to use a key for one operation or the other, I vote that we use it for selecting arguments. I don't want to have to hit a key to move an icon - if I had to, wouldn't that make the operation less "in sync" with other movement operations, such as dragging windows? With a 3-button mouse the options would be more open, of course. Does the Mac still get along with one? Perhaps we can use a code of mouse clicks - 3 long clicks means make the icon full size and make it stick to the mouse pointer in preparation for moving. :) > Sri -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Endless variations, make it all seem new" - Devo. ***
sho@gibbs.physics.purdue.edu (Sho Kuwamoto) (06/23/91)
In article <4661.tnews@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes: > With a 3-button mouse the options would be more open, of course. > Does the Mac still get along with one? Perhaps we can use a code > of mouse clicks - 3 long clicks means make the icon full size and > make it stick to the mouse pointer in preparation for moving. :) You've hit the nail on the head. Under System 7 on the mac, the keyboard is no longer used to input text. You enter text by tapping Morse code on the mouse button. Since a single click might be misinterpreted as an 'e', a new dot/dash sequence (previously unused in Morse code) is used to represent 'real' mouse clicks. For backwards compatability, the keyboard also works, but I imagine most users will throw their keyboards away soon. Now the situation for the new OS code-named "pink" is a different matter. A roller will be placed underneath the keyboard itself to make it a 135 button mouse. Since this may not be enough to suit the needs of future power users, chording of up to five keys is vigorously supported by the OS. This gives us 41,924,045,475 different possible mouse commands. I use a one button mouse on my mac and a three button mouse on a Sun. I really don't care which I use. I don't think the one button mouse is much easier to use, and I don't think the three button mouse is much more powerful. Maybe I just haven't tweaked my .twmrc enough to get that added hyper-performance edge, but having to remember which button to use is exactly as annoying to me as having to remember when to use the shift key or when to double-click. Besides, I'm always having to resort to things like meta-left-button, ctrl-middle-button, and so on, so it's not as if I were able to ignore the keyboard completely when issuing mouse clicks. -Sho -- sho@physics.purdue.edu <<-- click. click, click.
torrie@cs.stanford.edu (Evan Torrie) (06/23/91)
gblock@csd4.csd.uwm.edu (Gregory R Block) writes: >I had to wring necks on my Mac to get the power out of it I needed in >Finder, and I would have died and been reborn as a small tree frog to >have a good shell like the Amiga does. You should have looked at MPW. If you had, you'd be croaking now. >And with WB2.0, I never use >the shell. That says, at least to me, that the new workbench gives me >as much power as the shell used to. What features did you use to use in the shell, that you can now use in WorkBench? >> application writer. For applications designed to do this sort of >> thing, (e.g. ResEdit, DiskDoubler etc), the ability to handle any >> type of file is already built in by the programmer. >True. I was under the understanding that finder limited you to >loading into applications only those documents to which it was the >creator... My mistake. Well, the Finder will limit you in the sense that it doesn't auto-highlight the destination application, unless that application is known to be able to process that type of file (via an FREF resource). Like I said before, ResEdit and DiskDoubler add a 7 byte wildcard resource '****', which means you can drop ANY file. >>>Like I said, deal with what you do, or have the os stand over your >>>shoulder. Frankly, NOBODY stands over MY shoulder. :) >> >> Oftentimes, a guide over your shoulder can help prevent even the >> experienced user from making mistakes. >So you either learn from your mistakes, and become a more powerful >user, or you have the OS guide you. Everything's B&W with you, isn't it? Perhaps there's some medley in the middle. -- ------------------------------------------------------------------------------ Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu "Lay me place and bake me pie, I'm starving for me gravy... Leave my shoes and door unlocked, I might just slip away - hey - just for the day."
torrie@cs.stanford.edu (Evan Torrie) (06/23/91)
jbickers@templar.actrix.gen.nz (John Bickers) writes: >Quoted from <13863@mentor.cc.purdue.edu> by aru@mentor.cc.purdue.edu (Sri Ramkrishna): >> In article <4618.tnews@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes: >> > >> > When you're doing this, you need to have the proper icon >> > representation, so you can position it in a pixel perfect manner. >> >> What about using a keystroke in combination? For instance, <amiga> and then > With a 3-button mouse the options would be more open, of course. > Does the Mac still get along with one? Perhaps we can use a code > of mouse clicks - 3 long clicks means make the icon full size and > make it stick to the mouse pointer in preparation for moving. :) Boy, the human interface people would sure love this one :) I'm a bit confused at all this large icon talk. Presumably, you can only drag something onto something else if you can actually see part of the icon. Then why can't the destination icon just be auto-highlighted as soon as the mouse pointer is on top of the part that is visible? That way, you get immediate feedback as to which application will be launched. Or has the discussion on this moved on to some other factor since I last checked in? -- ------------------------------------------------------------------------------ Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu "Lay me place and bake me pie, I'm starving for me gravy... Leave my shoes and door unlocked, I might just slip away - hey - just for the day."
gblock@csd4.csd.uwm.edu (Gregory R Block) (06/23/91)
From article <1991Jun22.173103.6857@neon.Stanford.EDU>, by torrie@cs.stanford.edu (Evan Torrie): > > You should have looked at MPW. If you had, you'd be croaking now. I did. And I thought I said a GOOD shell. MPW sucks. > What features did you use to use in the shell, that you can now use > in WorkBench? Better question would be: What features DON'T I use. And now between running things concurrently with Arexx as the middleman, I wouldn't want to go back to my mac stuff. I have several programs for my FidoNet system which do nothing except for sit and wait for arexx messages... It works. > Well, the Finder will limit you in the sense that it doesn't > auto-highlight the destination application, unless that application > is known to be able to process that type of file (via an FREF resource). > Like I said before, ResEdit and DiskDoubler add a 7 byte wildcard > resource '****', which means you can drop ANY file. How many users know to just use resedit to change the resource so that all files can be "dropped in"??? And would the program accept it??? Both unknowns. And I figured out how to do something similar to the drag&drop. Launch the application, and the application opens a window on the workbench somewhat like the "appserver" program... drop an icon in, and it's loaded into your WP/etc... on another screen. Therefore overcoming the can't-drag-over-onto-other-screen problem. > Everything's B&W with you, isn't it? Perhaps there's some medley in > the middle. That's like striving to be average instead of excellent, isn't it? -- Socrates: "I drank WHAT????" LMFAP: "Next time you see me, it won't be me." Wubba: "A dream is nothing more than a wish dipped in chocolate and sprinkled with a little imagination." (From my poem, "A Dream") -Wubba
torrie@cs.stanford.edu (Evan Torrie) (06/23/91)
gblock@csd4.csd.uwm.edu (Gregory R Block) writes: >I did. And I thought I said a GOOD shell. MPW sucks. I assume there are lots of good points to back up that assertion. >How many users know to just use resedit to change the resource so that >all files can be "dropped in"??? And would the program accept it??? >Both unknowns. I would guess most power users will find out as soon as they start using System 7, if they bother to look at the Hints and Tips in various magazines, online forums etc. ResEdit has always been one of the primary tools in any power user's repertoire. You can add the resource to any program, since every program has an FREF. >> Everything's B&W with you, isn't it? Perhaps there's some medley in >> the middle. >That's like striving to be average instead of excellent, isn't it? I don't think so. In fact, if you look at many of the great ideas, they're great because they combine two or more disparate approaches into a single combination which has the good features of both, but eliminates the bad. -- ------------------------------------------------------------------------------ Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu "Cold is God's way of telling us to burn more Catholics" - Lady Whiteadder
jbickers@templar.actrix.gen.nz (John Bickers) (06/23/91)
Quoted from <1991Jun22.173103.6857@neon.Stanford.EDU> by torrie@cs.stanford.edu (Evan Torrie): > What features did you use to use in the shell, that you can now use > in WorkBench? You can use paths, aliases, and resident lists, btw, using PD software under Workbench 1.2 or 1.3. > Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Endless variations, make it all seem new" - Devo. ***
jbickers@templar.actrix.gen.nz (John Bickers) (06/23/91)
Quoted from <1991Jun22.173557.7038@neon.Stanford.EDU> by torrie@cs.stanford.edu (Evan Torrie): > I'm a bit confused at all this large icon talk. Presumably, you can only > drag something onto something else if you can actually see part of the icon. Workbench already has a drag and drop like operation, for copying files (ie: drag an icon over a disk icon, and it gets copied, etc). So I think the large icons argument is false. Auto selecting would be a problem, btw, because if the file icon is large and covers two or three application icons, how will the OS know which one to select? And if you go for some nice solution of using the position of the mouse pointer to judge, then you don't need to autoselect at all - just use the mouse pointer in the first place... > Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Endless variations, make it all seem new" - Devo. ***
dant@ryptyde.UUCP (Daniel Tracy) (06/23/91)
Responding to the following: "Since with shared libraries and shared text the application itself is usually small, this is rarely a problem. Certainly you can run more programs on an Amiga than on a Mac with the same amount of RAM." Can you explain to me what shared libraries are? It sounds to me like object-oriented code that is sharable across applications. That would be interesting. Basically follows the same philosophy of resources, eh? I don't agree with your last statement at all. Various resources aren't loaded into memory until they're needed, and if there isn't enough room, some more resources are purged. Resources are also, then, a sort of quasi-Virtual Memory that we've had since 1984.
dant@ryptyde.UUCP (Daniel Tracy) (06/23/91)
In article <1991Jun22.021136.315@Sugar.NeoSoft.com> peter@Sugar.NeoSoft.com (Peter da Silva) writes: >In article <1991Jun21.134801.19644@ifi.unizh.ch> matija@amiga.ifi.unizh.ch (Matija Milostnik) writes: >> Drag-and-drop is far more complex as just starting an appliction. The full >> drag-and-drop concept doesnt apply just to the start, but handles the incoming >> request during the hole sesion. > >Seems like overkill, but 2.0 has already implemented the second part. The first >part should be there as well. Capiche? Will 2.0 cause applications that aren't 2.0 aware to open documents while they're running? We've had this since 1986, and that's the way it was implimented: no application awareness needed. Hey, I'm using a standard quoting scheme! (Did it work?) :-)>-- >Peter da Silva. `-_-' <peter@sugar.neosoft.com>. > 'U` "Have you hugged your wolf today?"
jbickers@templar.actrix.gen.nz (John Bickers) (06/23/91)
Quoted from <5338@dirac.physics.purdue.edu> by sho@gibbs.physics.purdue.edu (Sho Kuwamoto): > button to use is exactly as annoying to me as having to remember when > to use the shift key or when to double-click. Besides, I'm always > having to resort to things like meta-left-button, ctrl-middle-button, The thing is not remembering which keys to press. It's having to reach for the keyboard at all. Imagine the following scenario - bleary eyed user snaking through their system, mouse in one hand and coffee in the other, leaning back in their chair. I do this from time to time, or I would if it was easier to get around the system with just the mouse. It's the mouse equivalent of typing "dir" repeatedly under MS-DOS - one of those fuzzy things one does just to pass the time... :) > -Sho -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Endless variations, make it all seem new" - Devo. ***
torrie@cs.stanford.edu (Evan Torrie) (06/23/91)
jbickers@templar.actrix.gen.nz (John Bickers) writes: > Workbench already has a drag and drop like operation, for copying > files (ie: drag an icon over a disk icon, and it gets copied, etc). Does the disk icon auto-highlight? > Auto selecting would be a problem, btw, because if the file icon is > large and covers two or three application icons, how will the OS know > which one to select? Always go for where the mouse pointer is pointing. The 'hot spot' is where the action happens. >And if you go for some nice solution of using > the position of the mouse pointer to judge, then you don't need to > autoselect at all - just use the mouse pointer in the first place... This cuts against the one of the core tenets of human interface design - namely "VISUAL FEEDBACK". A good user interface will always try and provide immediate visual feedback to indicate the result of completing the action. In the case of dragging and dropping, auto-highlighting the appropriate application while the user drags the document icon indicates to the user that if he lets go now, this is the application which will get launched. If you don't highlight at all, what happens when your icons are all crammed together, and it's difficult to tell exactly which one the mouse pointer is on top of?? If we were to carry your argument further, then why would you bother highlighting menu items as you drag the mouse down the menu? By your reasoning, you can see where the mouse pointer is... why bother auto-highlighting? I suggest you try a menu system without auto-highlighting, and then come back and tell us whether it's a good idea or not... (Hint: what happens when you're halfway between two menu items?) -- ------------------------------------------------------------------------------ Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu "If it weren't for your gumboots, where would you be? You'd be in the hospital, or in-firm-ary..." F. Dagg
peter@Sugar.NeoSoft.com (Peter da Silva) (06/23/91)
In article <1991Jun22.173103.6857@neon.Stanford.EDU> torrie@cs.stanford.edu (Evan Torrie) writes: > Everything's B&W with you, isn't it? Perhaps there's some medley in > the middle. [ of course it's B&W... he's got a Mac :-> ] [ I know, small joke ] You don't understand... the Amy *is* the medley in the middle: GUI and shell, a workstation environment for the price of a PC. -- Peter da Silva. `-_-' <peter@sugar.neosoft.com>. 'U` "Have you hugged your wolf today?"
peter@Sugar.NeoSoft.com (Peter da Silva) (06/23/91)
The Strange and Wonderful Daniel Tracy:
"Responding to the following:
"``Since with shared libraries and shared text the application itself is
usually small, this is rarely a problem. Certainly you can run more programs
on an Amiga than on a Mac with the same amount of RAM.''
"Can you explain to me what shared libraries are? It sounds to me like
object-oriented code that is sharable across applications. That would
be interesting."
-- <95@ryptyde.UUCP>
Shared libraries are basically utility routines, like the ones in the Mac
ROM and system file, but loaded on demand by the programmer. They can be
ones provided by Commodore, or third party ones. Here's what I have in my
libs: directory:
1.SYS:> dir libs:
.info arp.library
asl.library commodities.library
diskfont.library iff.library
iffparse.library kd_freq.library
mathieeedoubbas.library mathieeedoubtrans.library
mathieeesingtrans.library mathtrans.library
powerpacker.library Readme
req.library rexxsupport.library
rexxsyslib.library screenshare.library
translator.library version.library
xprascii.library
Some of these are Commodore's (like diskfont.library), some are third
party (like arp.library), and some are third party stuff Commodore has
added to the standard distribution (like commodities.library).
> Basically follows the same philosophy of resources, eh?
But shared among programs: if two applications use arp.library, then only
one copy is loaded. When they're done with it, it's purged. The entire Amiga
operating system is basically a collection of these libraries and various
processes that call them.
If the Mac has had an equivalent to shared libraries, then why are Mac
programs so large? Most Amiga programs are under 50K:
1.SYS:> list work:system
Directory "Work:System" on Sunday 23-Jun-91
DirMaster 58788 ----rwed 19-Nov-90 22:23:58
Movie 86408 ----rwed Friday 19:06:27
ZoePlay 34640 ----rwed 20-Nov-90 07:31:36
VirusX 11896 ----rwed 01-Sep-78 13:43:11
Vzoom 19580 ----rwed 12-Apr-91 20:09:21
NewZAP3.0 31232 ----rwed 12-Apr-91 20:15:37
PM 14436 ----rwed 02-Sep-78 13:17:19
SysMon 7896 ----rwed 02-Sep-78 13:17:27
DVPLAYER 196476 ----rwed Monday 17:58:34
--
Peter da Silva. `-_-' <peter@sugar.neosoft.com>.
'U` "Have you hugged your wolf today?"peter@Sugar.NeoSoft.com (Peter da Silva) (06/23/91)
In article <96@ryptyde.UUCP> dant@ryptyde.UUCP (Daniel Tracy) writes: > Will 2.0 cause applications that aren't 2.0 aware to open documents while > they're running? No. I suppose you could use a kludge to give the appearance of having them do this. Personally, I'd rather not install such a prop and force application programmers to update their code. The fewer kludges added in the name of backwards compatibility the better... that's the philosophy that's held the Mac back so badly. -- Peter da Silva. `-_-' <peter@sugar.neosoft.com>. 'U` "Have you hugged your wolf today?"
peter@Sugar.NeoSoft.com (Peter da Silva) (06/23/91)
In article <5338@dirac.physics.purdue.edu> sho@gibbs.physics.purdue.edu (Sho Kuwamoto) writes: > I use a one button mouse on my mac and a three button mouse on a Sun. X windows has this basic, fundamental, design flaw for an end-user window system. It's fine for research, but the protocol is so low level and there were never any good standards set, so the use of buttons is utter chaos. X delenda est. -- Peter da Silva. `-_-' <peter@sugar.neosoft.com>. 'U` "Have you hugged your wolf today?"
taab5@isuvax.iastate.edu (Marc Barrett) (06/23/91)
In article <1991Jun23.044133.23463@neon.Stanford.EDU>, torrie@cs.stanford.edu (Evan Torrie) writes: >jbickers@templar.actrix.gen.nz (John Bickers) writes: > >> Workbench already has a drag and drop like operation, for copying >> files (ie: drag an icon over a disk icon, and it gets copied, etc). > > Does the disk icon auto-highlight? No it doesn't, and this is a very big beef I have with Workbench 2.0. With WB2.0, when you are copying files into drawers, the only way you can guarantee that the file will go where you want it to go is to open the drawer and drop the icon into the drawer's window. This is a needless extra step that is totally eliminated on the MAC with auto-highlighting. > >> Auto selecting would be a problem, btw, because if the file icon is >> large and covers two or three application icons, how will the OS know >> which one to select? > > Always go for where the mouse pointer is pointing. The 'hot spot' is >where the action happens. This is not intuitive. It is also confusing, because hwo can the user see which icon the mouse pointer is currently 'over' if the icon being dragged is covering up a bunch of the screen? > >>And if you go for some nice solution of using >> the position of the mouse pointer to judge, then you don't need to >> autoselect at all - just use the mouse pointer in the first place... > > This cuts against the one of the core tenets of human interface design - >namely "VISUAL FEEDBACK". A good user interface will always try and >provide immediate visual feedback to indicate the result of completing >the action. In the case of dragging and dropping, auto-highlighting the >appropriate application while the user drags the document icon indicates >to the user that if he lets go now, this is the application which will >get launched. > If you don't highlight at all, what happens when your icons are all >crammed together, and it's difficult to tell exactly which one the mouse >pointer is on top of?? > If we were to carry your argument further, then why would you bother >highlighting menu items as you drag the mouse down the menu? By your >reasoning, you can see where the mouse pointer is... why bother >auto-highlighting? > I suggest you try a menu system without auto-highlighting, and then >come back and tell us whether it's a good idea or not... (Hint: what >happens when you're halfway between two menu items?) (Left in because it irks people! :-) > > > > >-- >------------------------------------------------------------------------------ >Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu >"If it weren't for your gumboots, where would you be? You'd be in the >hospital, or in-firm-ary..." F. Dagg ------------------------------------------------------------- / Marc Barrett -MB- | BITNET: XGR39@ISUVAX.BITNET / / ISU COM S Student | Internet: XGR39@CCVAX.IASTATE.EDU / ------------------------------------------------------------ \ The great thing about standards is that / \ there are so many of them to choose from. / -------------------------------------------------------
torrie@cs.stanford.edu (Evan Torrie) (06/24/91)
taab5@isuvax.iastate.edu (Marc Barrett) writes: >In article <1991Jun23.044133.23463@neon.Stanford.EDU>, torrie@cs.stanford.edu (Evan Torrie) writes: >>jbickers@templar.actrix.gen.nz (John Bickers) writes: >> >>> Workbench already has a drag and drop like operation, for copying >>> files (ie: drag an icon over a disk icon, and it gets copied, etc). >> >> Does the disk icon auto-highlight? > No it doesn't, and this is a very big beef I have with Workbench 2.0. I can see why... I wonder how many HI people Commodore has? >> Always go for where the mouse pointer is pointing. The 'hot spot' is >>where the action happens. > This is not intuitive. It is also confusing, because hwo can the user >see which icon the mouse pointer is currently 'over' if the icon being >dragged is covering up a bunch of the screen? Well, on the Mac, the icon is dragged as a gray outline of the icon shape. So, the icon is transparent, and you can see exactly where the mouse pointer is pointing. [i.e. you can see through behind the icon that you're dragging]. -- ------------------------------------------------------------------------------ Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu "If it weren't for your gumboots, where would you be? You'd be in the hospital, or in-firm-ary..." F. Dagg
sho@gibbs.physics.purdue.edu (Sho Kuwamoto) (06/24/91)
In article <cyc> peter@Sugar.NeoSoft.com (Peter da Silva) writes: >In article <lops> sho@gibbs.physics.purdue.edu (Sho Kuwamoto) writes: >> I use a one button mouse on my mac and a three button mouse on a Sun. > >X windows has this basic, fundamental, design flaw for an end-user window >system. It's fine for research, but the protocol is so low level and there >were never any good standards set, so the use of buttons is utter chaos. Agreed. Could you refresh my memory about the standards for mouse buttons on the Amiga? One button brings up the menubar, right? Er... something like that. I'd like to know how multiple button mice are used on the Amiga, how consistent their use is across different programs, and how you find it helps you in getting from point A to point B. -Sho -- sho@physics.purdue.edu <<-- probably has it all wrong, having seen WB 2.0 only once in his life.
jbickers@templar.actrix.gen.nz (John Bickers) (06/24/91)
Quoted from <1991Jun23.044133.23463@neon.Stanford.EDU> by torrie@cs.stanford.edu (Evan Torrie): > jbickers@templar.actrix.gen.nz (John Bickers) writes: > > Workbench already has a drag and drop like operation, for copying > Does the disk icon auto-highlight? Not that I remember. > > the position of the mouse pointer to judge, then you don't need to > > autoselect at all - just use the mouse pointer in the first place... > > This cuts against the one of the core tenets of human interface design - > namely "VISUAL FEEDBACK". A good user interface will always try and > provide immediate visual feedback to indicate the result of completing I think it's a little more complex than that. Perhaps "a good user interface will always try and provide immediate visual feedback to indicate the result of completing the action, except when doing so will result in visual 'noise'". This is probably a matter of opinion. I had a discussion a while back with a guy who writes user interface stuff for touch screen applications, and apparently a long standing divider in the company he works for is the direction scrolling lists should move in when the user presses a cursor key. These things are small and insignificant. Note that menus are not generally a cluttered visual space, but a Workbench where the icons are jammed closely enough together to be a problem is obviously quite cluttered. > Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Endless variations, make it all seem new" - Devo. ***
taab5@isuvax.iastate.edu (Marc Barrett) (06/24/91)
In article <1991Jun23.173533.8864@neon.Stanford.EDU>, torrie@cs.stanford.edu (Evan Torrie) writes: >taab5@isuvax.iastate.edu (Marc Barrett) writes: > >>In article <1991Jun23.044133.23463@neon.Stanford.EDU>, torrie@cs.stanford.edu (Evan Torrie) writes: >>>jbickers@templar.actrix.gen.nz (John Bickers) writes: >>> >>>> Workbench already has a drag and drop like operation, for copying >>>> files (ie: drag an icon over a disk icon, and it gets copied, etc). >>> >>> Does the disk icon auto-highlight? > >> No it doesn't, and this is a very big beef I have with Workbench 2.0. > > I can see why... I wonder how many HI people Commodore has? > >>> Always go for where the mouse pointer is pointing. The 'hot spot' is >>>where the action happens. > >> This is not intuitive. It is also confusing, because hwo can the user >>see which icon the mouse pointer is currently 'over' if the icon being >>dragged is covering up a bunch of the screen? > > Well, on the Mac, the icon is dragged as a gray outline of the icon >shape. So, the icon is transparent, and you can see exactly where the >mouse pointer is pointing. [i.e. you can see through behind the icon >that you're dragging]. This does not happen on an Amiga. When you drag an icon, the actual image of the icon is dragged, and not an outline. This is why the idea of using the mouse pointer as the "hot spot" makes absolutely no sense at all. Unless much more of the MAC's user interface is implemented, drag-and- drop simply will not work on an Amiga. > >-- >------------------------------------------------------------------------------ >Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu >"If it weren't for your gumboots, where would you be? You'd be in the >hospital, or in-firm-ary..." F. Dagg ------------------------------------------------------------- / Marc Barrett -MB- | BITNET: XGR39@ISUVAX.BITNET / / ISU COM S Student | Internet: XGR39@CCVAX.IASTATE.EDU / ------------------------------------------------------------ \ The great thing about standards is that / \ there are so many of them to choose from. / -------------------------------------------------------
rjc@geech.gnu.ai.mit.edu (Ray Cromwell) (06/24/91)
In article <1991Jun23.201625.18225@news.iastate.edu> taab5@isuvax.iastate.edu writes: > This does not happen on an Amiga. When you drag an icon, the actual >image of the icon is dragged, and not an outline. This is why the idea of >using the mouse pointer as the "hot spot" makes absolutely no sense at >all. Sure it does, that's why it's call a _POINTER_. > Unless much more of the MAC's user interface is implemented, drag-and- >drop simply will not work on an Amiga. Oh, please no! I like the entire icon being dragged, it looks way better, the same way dragging the entire window on the NeXT looks cool. Drag and drop, can and does work on the Amiga. I have had no problem drag and dropping icons on the Amiga. The icons are big and it's easy to get the mouse pointer inside one. It would be a problem it icons were 4 pixels big, but it isn't. Don't Macify my Amiga, no thank you. Although highlighting is a nice idea, it makes no difference since Amiga icons are solid (not outlines) so you wouldn't be able to see if the icon is highlighted anyway. Look at the icons in AmigaVision once, they would look _stupid_ if they were drag as outlines. The next generation UI being developed at Xerox PARC takes this one step further, they have animated icons since animation provides more information in less screen real estate. (Perhaps Apple will steal this too.) -- / INET:rjc@gnu.ai.mit.edu * // The opinions expressed here do not \ | INET:r_cromwe@upr2.clu.net | \X/ in any way reflect the views of my self.| \ UUCP:uunet!tnc!m0023 * /
dant@ryptyde.UUCP (Daniel Tracy) (06/24/91)
Responding to the following: "You managed to completely miss both of the points I made and fastened on a single phrase that you don't care for." I don't understand. You made a statement, and I corrected you. You stated that the file type of a Macintosh file was kept in the resource fork. It isn't. I wasn't attacking your points. However, they are invalid. You are talking about interchange formats, documents. The interchange format docs on the Macintosh don't NEED a resource fork and couldn't care less if they had one! Our bitmap, drawing, text, formatted text, movie, sound, etc. don't need resources, although they can be transfered into one (some of them). You can just as easily use them on other machines. So what is the interchange advantage of the Amiga?
torrie@cs.stanford.edu (Evan Torrie) (06/24/91)
taab5@isuvax.iastate.edu (Marc Barrett) writes: >> Well, on the Mac, the icon is dragged as a gray outline of the icon >>shape. So, the icon is transparent, and you can see exactly where the >>mouse pointer is pointing. [i.e. you can see through behind the icon >>that you're dragging]. > This does not happen on an Amiga. When you drag an icon, the actual >image of the icon is dragged, and not an outline. I guessed as much. In most respects, you would say that dragging an image of the icon is actually better, but I guess this is one case where it works against you. >This is why the idea of >using the mouse pointer as the "hot spot" makes absolutely no sense at >all. Unless you somehow added a transparency feature, so you could see through the icon's image to what was beneath it. Sounds like a job for the alpha channel! -- ------------------------------------------------------------------------------ Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu Fame, fame, fame... What's it good for? Ab-so-lute-ly nothing
mykes@amiga0.SF-Bay.ORG (Mike Schwartz) (06/24/91)
In article <1991Jun21.021339.11214@minyos.xx.rmit.oz.au> s902113@minyos.xx.rmit.oz.au (Luke Mewburn) writes: >robart@agora.rain.com (Robert Barton) writes: > >> This sounds like "ASSIGN" on the Amiga. > > Actually, aliases are _MUCH_ more powerful. Assign can _only_ be used for >folders or volumes, _not_ files. But, one good use (using ASSIGN) on the >Amiga is to make assignments starting with a ".", so when listed in a file >requester which handles assign-ed paths, they appear at the top. I do this >on Music programs (MED3.1, ST clones, etc), to find my songs directory >really fast... Assign works for files, too: ASSIGN FOO: path:bar where bar is a file (NOT A DIRECTORY). -- **************************************************** * I want games that look like Shadow of the Beast * * but play like Leisure Suit Larry. * ****************************************************
awessels@ccwf.cc.utexas.edu (Allen Wessels) (06/24/91)
In article <1991Jun23.145612.16729@Sugar.NeoSoft.com> peter@Sugar.NeoSoft.com (Peter da Silva) writes: >If the Mac has had an equivalent to shared libraries, then why are Mac >programs so large? Most Amiga programs are under 50K: Please be so good as to define "most" Mac programs. I'm betting you're comparing Amiga utilities to commercial Mac applications. However, I'll take up your claim. I ftp'd sumex-aim (36.44.0.6) and listed out all the files in the /info-mac/util directory. Of 161 files in that directory, 89 were under your 50k limit. Add in the fact that they are stored in the bloated Binhex format (figure a quarter to a third size increase), and the fact that a lot of the documentation includes bitmapped screen shots, and you will probably find that Mac programs aren't all that big. Just for grins I did the same with /info-mac/app. Only 25 of 88 files were under 50k, but taking into consideration the overhead of Binhex files and assuming some additional overhead for documention, I think your 50k metric would be met by the contents of that directory as well. It may well be that Mac programs are in general larger than an Amiga program with the same feature set, but the quote above isn't proof. (I was tempted to do a list of the desk accesory directory at sumex since DAs are applications under System 7.0, but that would stack the numbers WAY in my favor.)
awessels@ccwf.cc.utexas.edu (Allen Wessels) (06/24/91)
In article <1991Jun23.204705.23687@mintaka.lcs.mit.edu> rjc@geech.gnu.ai.mit.edu (Ray Cromwell) writes: >they were drag as outlines. The next generation UI being developed at >Xerox PARC takes this one step further, they have animated icons since >animation provides more information in less screen real estate. >(Perhaps Apple will steal this too.) I don't know what sort of animation the PARC GUI does, but the Mac has a couple of different sorts of animated icons. Most of it is a sort of two-frame animation like the trashcan uses - basically a variant on the original, i.e. a trashcan with contents has a bulging icon. The other sort display when inits are loaded. This type has 8 frames. Geez, Apple can't do anything right. If they don't use a feature, they're "old technology" and if they do, they "stole it." I can guarantee you that in spite of the inflated salaries and the requirements of the user base, Apple DOES manage to do some smart things with all that research money. Amazingly, people doing research on the same subject CAN come to similar conclusions.
s8105119@ipc04.mqcs.mq.oz.au (Gary Kevin MAKIN) (06/24/91)
In article <1991Jun23.145612.16729@Sugar.NeoSoft.com> peter@Sugar.NeoSoft.com (Peter da Silva) writes: >Shared libraries are basically utility routines, like the ones in the Mac >ROM and system file, but loaded on demand by the programmer. Not entirely true. The Mac does have a real equivalent to shared libraries, but I know of noone other than Apple using them. These are called Packages on the Mac. Apple uses packages for all sorts of things: the disk initialization routines, the List manager, Standard File package, floating point, transcendental functions, apple events, help manager, etc. Using the Mac's "shared libraries" every program since 1984 has been able to use the same routine to ask the user for the file to open! And many of these packages are either in ROM or loaded into the System heap, so each program does not have to load it's own copy. >-- >Peter da Silva. `-_-' <peter@sugar.neosoft.com>. > 'U` "Have you hugged your wolf today?" Gary.
torrie@cs.stanford.edu (Evan Torrie) (06/24/91)
jbickers@templar.actrix.gen.nz (John Bickers) writes: >Quoted from <1991Jun23.044133.23463@neon.Stanford.EDU> by torrie@cs.stanford.edu (Evan Torrie): > This is probably a matter of opinion. As is a lot of computer human interface stuff. In most cases, the democratic solution wins out : i.e. it's what the majority feels most comfortable with that wins out in a design tradeoff, even though there may be a sizeable dissenting group. >I had a discussion a while back > with a guy who writes user interface stuff for touch screen > applications, and apparently a long standing divider in the company > he works for is the direction scrolling lists should move in > when the user presses a cursor key. This depends on whether you consider the piece of "paper" the list is on to be fixed, and you're just moving a cut-out rectangle over the top of it, or whether the cut-out rectangle is fixed, and you're moving the paper. Most computer GUIs have chosen the "cut-out rectangle approach". Incidentally, the PenPoint OS does it the alternative way for its gesture movement of scrolling. You click on the screen with your pen, and pull down to move the text "UP". This really put me off the first few times I used it, but it's something you get used to. > These things are small and insignificant. Note that menus are not > generally a cluttered visual space, but a Workbench where the icons > are jammed closely enough together to be a problem is obviously > quite cluttered. Which is all the more reason to have visual feedback to tell you which one of the jammed together icons your action will apply to. -- ------------------------------------------------------------------------------ Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu "I didn't get where I am today without knowing a good deal when I see one, Reggie." "Yes, C.J."
torrie@cs.stanford.edu (Evan Torrie) (06/24/91)
peter@Sugar.NeoSoft.com (Peter da Silva) writes: >No. I suppose you could use a kludge to give the appearance of having them >do this. Personally, I'd rather not install such a prop and force application >programmers to update their code. The fewer kludges added in the name of >backwards compatibility the better... that's the philosophy that's held the >Mac back so badly. Unfortunately, users who have paid a lot of money for their old software like to see it take advantage of all these new features. If the installed software base were non-existent, then kludges wouldn't be necessary. And I'm sure the Amiga has its fair share of backwards compatibility problems [remember that discussion we had about "Which has advanced more, the Mac or the Amiga"]? -- ------------------------------------------------------------------------------ Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu "I didn't get where I am today without knowing a good deal when I see one, Reggie." "Yes, C.J."
torrie@cs.stanford.edu (Evan Torrie) (06/24/91)
s8105119@ipc04.mqcs.mq.oz.au (Gary Kevin MAKIN) writes: >In article <1991Jun23.145612.16729@Sugar.NeoSoft.com> peter@Sugar.NeoSoft.com (Peter da Silva) writes: >>Shared libraries are basically utility routines, like the ones in the Mac >>ROM and system file, but loaded on demand by the programmer. >Not entirely true. The Mac does have a real equivalent to shared libraries, but >I know of noone other than Apple using them. These are called Packages on the >Mac. Apple uses packages for all sorts of things: the disk initialization >routines, the List manager, Standard File package, floating point, >transcendental functions, apple events, help manager, etc. Using the Mac's >"shared libraries" every program since 1984 has been able to use the same >routine to ask the user for the file to open! Yes, but Apple has limited packages to at most 16, since the _Pack traps are actually separate trap numbers, and only 16 trap numbers are set aside for packages, all of which Apple has reserved, and is now using with System 7. So, it's a general mechanism for Apple to provide shared library like code, but not for other developers. Apple has not really published a standard for shared code like methods, although some developers have published methods for accessing their core code (for example, CE Software with their QuicKeys engine, and Aladdin with the Stuffit Engine technology). Now, with AppleEvents and IAC being promoted as a standard, I can see essentially any application being capable of being a "shared" library. [since that's the whole point of IAC - getting other applications to do your work for you]. People can write faceless applications, which just accept AppleEvents, and return responses. -- ------------------------------------------------------------------------------ Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu "Apes evolved from creationists" - seen on a bumper sticker.
jbickers@templar.actrix.gen.nz (John Bickers) (06/24/91)
Quoted from <1991Jun23.201625.18225@news.iastate.edu> by taab5@isuvax.iastate.edu (Marc Barrett): > This does not happen on an Amiga. When you drag an icon, the actual > image of the icon is dragged, and not an outline. This is why the idea of > using the mouse pointer as the "hot spot" makes absolutely no sense at It makes perfect sense. I don't need to see the exact position of my hands when I scratch my back. Understand? > Unless much more of the MAC's user interface is implemented, drag-and- > drop simply will not work on an Amiga. As far as starting an application goes, you are lying. Consider the following: Use an input handler to track mouse drags in the Workbench window, and do the appropriate things when the mouse button is released. It would take a bit of fiddling to get working, but it is eminently feasible. > / Marc Barrett -MB- | BITNET: XGR39@ISUVAX.BITNET / -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Endless variations, make it all seem new" - Devo. ***
jbickers@templar.actrix.gen.nz (John Bickers) (06/24/91)
Quoted from <1991Jun23.162103.12891@news.iastate.edu> by taab5@isuvax.iastate.edu (Marc Barrett): > In article <1991Jun23.044133.23463@neon.Stanford.EDU>, torrie@cs.stanford.edu (Evan Torrie) writes: > > Does the disk icon auto-highlight? > With WB2.0, when you are copying files into drawers, the only way you can > guarantee that the file will go where you want it to go is to open the I can guarantee that the file will go where I want it in other ways. Did you mean the generic "you" in your sentence above, or just you in particular, MB? > / Marc Barrett -MB- | BITNET: XGR39@ISUVAX.BITNET / (Left in because it irks people! :-) -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Endless variations, make it all seem new" - Devo. ***
peter@Sugar.NeoSoft.com (Peter da Silva) (06/24/91)
In article <1073@macuni.mqcc.mq.oz> s8105119@ipc04.mqcs.mq.oz.au (Gary Kevin MAKIN) writes: > Not entirely true. The Mac does have a real equivalent to shared libraries, > but I know of noone other than Apple using them. Why not? -- Peter da Silva. `-_-' <peter@sugar.neosoft.com>. 'U` "Have you hugged your wolf today?"
peter@Sugar.NeoSoft.com (Peter da Silva) (06/24/91)
The Amazing Daniel Tracy:
"Responding to the following:
"``You managed to completely miss both of the points I made and
fastened on a single phrase that you don't care for.''
"I don't understand. You made a statement, and I corrected you."
-- <102@ryptyde.UUCP>
I know you don't understand. The points that I was making were entirely
independent of where the file type was stored. Though an implementation
where it was stored in the resource fork (or, equivalently, in a header)
would certainly be cleaner.
Then you continue:
"I wasn't attacking your points. However, they are invalid. You are
talking about interchange formats, documents. The interchange format docs
on the Macintosh don't NEED a resource fork and couldn't care less if they
had one!"
-- <102@ryptyde.UUCP>
Now I'll have to plead ignorance. This seems again entirely irrelevant to my
message. Perhaps you would like to explain what that has to do with:
1. The basic capability of IFF and the Mac's typed files are
equivalent.
2. Since the IFF standard is defined in a system-independent manner
(and in fact is used in EA programs on the IBM-PC and the Mac as
well as the Amiga) it's a superior design.
If you want to find out more about IFF, look it up. It's a published standard.
--
Peter da Silva. `-_-' <peter@sugar.neosoft.com>.
'U` "Have you hugged your wolf today?"peter@Sugar.NeoSoft.com (Peter da Silva) (06/24/91)
In article <5342@dirac.physics.purdue.edu> sho@gibbs.physics.purdue.edu (Sho Kuwamoto) writes: > Agreed. Could you refresh my memory about the standards for mouse > buttons on the Amiga? One button brings up the menubar, right? The two buttons are SELECT and MENU. A third button for ACTIVATE would be better, but it's too late for that. In any case, one button brings up the menu bar (or, in my case, menu box... PopUpMenu should be shipped with the system, dammit), and the other selects the object to be operated on. Double-clicking is only used as a shortcut for SELECT-MENU-(select "Open")... and that's what "ACTIVATE" should be for. > I'd like to know how multiple button mice are > used on the Amiga, how consistent their use is across different > programs, Pretty much all programs use them consistently, except for ports from the Atari ST and other systems where no standard exists. There's one big exception that's become a standard: paint programs tend to use the menu button as a complement-select. That is, when painting the menu button uses an alternate color. > and how you find it helps you in getting from point A to point B. Well, it's quite handy in paint programs and the like not to have to worry about system gadgets taking up space. For animation software, since it's going to go straight to video, that's even more important. Since there are two buttons, you can select a number of menu options at a time and have them take effect all at once without playing with keyboard shortcuts. With PopUpMenu you lose the "menu stretch", reaching across a large display with the mouse to get to the menus. Basically, it reduces screen clutter and user actions, and speeds up multiple selections. -- Peter da Silva. `-_-' <peter@sugar.neosoft.com>. 'U` "Have you hugged your wolf today?"
peter@Sugar.NeoSoft.com (Peter da Silva) (06/24/91)
In article <1991Jun23.162103.12891@news.iastate.edu> taab5@isuvax.iastate.edu writes: > No it doesn't, and this is a very big beef I have with Workbench 2.0. > With WB2.0, when you are copying files into drawers, the only way you can > guarantee that the file will go where you want it to go is to open the > drawer and drop the icon into the drawer's window. I have no idea what you're referring to here, unless you're suffering from some physical disorder that makes it impossible to position the mouse with a minimum degree of accuracy. I've never had a problem with copying or moving files into drawers on *any* version of Workbench. > This is not intuitive. It is also confusing, because hwo can the user > see which icon the mouse pointer is currently 'over' if the icon being > dragged is covering up a bunch of the screen? So GET RID OF THE BLOODY BIG ICONS! You have IconEdit... use it! -- Peter da Silva. `-_-' <peter@sugar.neosoft.com>. 'U` "Have you hugged your wolf today?"
peter@Sugar.NeoSoft.com (Peter da Silva) (06/24/91)
In article <51086@ut-emx.uucp> awessels@ccwf.cc.utexas.edu (Allen Wessels) writes: > Geez, Apple can't do anything right. You got that right. > If they don't use a feature, they're "old technology" No, they're "old technology" because they screwed up so badly on the original design. It's got nothing to do with "features". Multitasking isn't a "feature", it's a basic capability that should be the core of *any* system since about 1965. > and if they do, they "stole it." People talk about Apple stealing stuff because of what their lawyers do, not what their programmers do. > Apple DOES manage to do some smart things with all that research money. Probably so. Too bad they're so big on NIH and have such a crummy platform to apply that research to. -- Peter da Silva. `-_-' <peter@sugar.neosoft.com>. 'U` "Have you hugged your wolf today?"
dant@ryptyde.UUCP (Daniel Tracy) (06/24/91)
Responding to the following: "If the Mac has had an equivalent to shared libraries, then why are Mac programs so large? Most Amiga programs are under 50K" I didn't say it had the equivolent, not at all. Resources follow this same philosophy, but they're not in that stage yet (nor are shared libraries, however). In the future, perhaps resources can be stated as being global and shared among applications (including CODE resources). I get the impression that the NeXT has this equivolent though...
dant@ryptyde.UUCP (Daniel Tracy) (06/24/91)
Responding to the following: "No. I suppose you could use a kludge to give the appearance of having them do this. Personally, I'd rather not install such a prop and force application programmers to update their code. The fewer kludges added in the name of backwards compatibility the better... that's the philosophy that's held the Mac back so badly." Excuse me? Are you flaming Apple for being able to do something Commodore couldn't? That is, cause applications to open documents by double-clicking on them even if the app is running, without apps having to be rewritten? There is no "appearance" of them having done this. What do you mean? Holography? :) That's just it, the Workbench way DOES force programmers to update their code, while Apple's doesn't. What's the disadvantage? What is your point, if you have one?
rjc@churchy.gnu.ai.mit.edu (Ray Cromwell) (06/24/91)
In article <51086@ut-emx.uucp> awessels@ccwf.cc.utexas.edu (Allen Wessels) writes: >In article <1991Jun23.204705.23687@mintaka.lcs.mit.edu> rjc@geech.gnu.ai.mit.edu (Ray Cromwell) writes: >>they were drag as outlines. The next generation UI being developed at >>Xerox PARC takes this one step further, they have animated icons since >>animation provides more information in less screen real estate. >>(Perhaps Apple will steal this too.) > >I don't know what sort of animation the PARC GUI does, but the Mac has a couple >of different sorts of animated icons. Most of it is a sort of two-frame >animation like the trashcan uses - basically a variant on the original, i.e. >a trashcan with contents has a bulging icon. The other sort display when >inits are loaded. This type has 8 frames. The Amiga has this too, but that's not what I'm talking about. The PARC icons can animate with any number of frames. PARC also implemented large virtual screens wih a technique called "clustering" that clusters together screen information which you use a lot. (This prevents the need for scrolling around the huge virtual screen looking for stuff). They also present information as an "information tree". I don't have all the details about it since I read about it a long time ago but it sounded really neat. They have done a lot of study on human interfacing, and came up a system that is different from the Mac/Amiga/NeXT/etc.) >Geez, Apple can't do anything right. If they don't use a feature, they're >"old technology" and if they do, they "stole it." I can guarantee you that >in spite of the inflated salaries and the requirements of the user base, >Apple DOES manage to do some smart things with all that research money. >Amazingly, people doing research on the same subject CAN come to similar >conclusions. The problem is, when Apple does use a feature, they proclaim they invented it and copyright it. I have no qualms with sharing ideas (I think information should be free to all[i don't like software patents or copyrights on screen layouts]) I do detest Apple's attempts at copyrighting look-and-feel. -- / INET:rjc@gnu.ai.mit.edu * // The opinions expressed here do not \ | INET:r_cromwe@upr2.clu.net | \X/ in any way reflect the views of my self.| \ UUCP:uunet!tnc!m0023 * /
gblock@csd4.csd.uwm.edu (Gregory R Block) (06/24/91)
From article <1991Jun22.213406.13336@neon.Stanford.EDU>, by torrie@cs.stanford.edu (Evan Torrie): > I assume there are lots of good points to back up that assertion. There are, but there's no point. It's like you trying to convince me to buy an IBM, even though my amiga gives me everything I need, and what it doesn't, I get from the Mac IIcx sitting next to it. It's pointless, and it's pretty well based on tastes... > I would guess most power users will find out as soon as they start > using System 7, if they bother to look at the Hints and Tips in various > magazines, online forums etc. ResEdit has always been one of the > primary tools in any power user's repertoire. Does ResEdit come with the OS? :) Still sounds like a way of getting around something the OS has set up. If it was meant to do it, it would do it. "Fixing" the program with ResEdit is.... well, a kludge. But once again, that's my opinion shining through. >>That's like striving to be average instead of excellent, isn't it? > > I don't think so. In fact, if you look at many of the great ideas, they're > great because they combine two or more disparate approaches into a single > combination which has the good features of both, but eliminates the bad. Which? And many great ideas come from taking theory and working it into something that works in the real-world... some things are just not possible except on paper... Greg -- Socrates: "I drank WHAT????" LMFAP: "Next time you see me, it won't be me." Wubba: "A dream is nothing more than a wish dipped in chocolate and sprinkled with a little imagination." (From my poem, "A Dream") -Wubba
gblock@csd4.csd.uwm.edu (Gregory R Block) (06/24/91)
From article <1991Jun23.144517.16554@Sugar.NeoSoft.com>, by peter@Sugar.NeoSoft.com (Peter da Silva): > [ of course it's B&W... he's got a Mac :-> ] Boo, hiss. :) > [ I know, small joke ] Real small. 9 inches, I think... But that's only part of the joke. :) > You don't understand... the Amy *is* the medley in the middle: GUI and shell, > a workstation environment for the price of a PC. And with 2.0, it's more than that. The shell is there, and so is a new Workbench, giving the power of the shell with the ease of the intuition interface, now detailed with a style guide available in a store near you. The new look is amazing, and should be a treat to see my Mac friends squirm under 7.0. :) Several have already fallen under it's grip, and now own 2000's. The rest will wise up eventually.. :D Greg -- Socrates: "I drank WHAT????" LMFAP: "Next time you see me, it won't be me." Wubba: "A dream is nothing more than a wish dipped in chocolate and sprinkled with a little imagination." (From my poem, "A Dream") -Wubba
rjc@churchy.gnu.ai.mit.edu (Ray Cromwell) (06/24/91)
In article <111@ryptyde.UUCP> dant@ryptyde.UUCP (Daniel Tracy) writes: >Responding to the following: > >"No. I suppose you could use a kludge to give the appearance of having them >do this. Personally, I'd rather not install such a prop and force application >programmers to update their code. The fewer kludges added in the name of >backwards compatibility the better... that's the philosophy that's held the >Mac back so badly." > >Excuse me? Are you flaming Apple for being able to do something Commodore >couldn't? That is, cause applications to open documents by double-clicking >on them even if the app is running, without apps having to be rewritten? >There is no "appearance" of them having done this. What do you mean? >Holography? :) That's just it, the Workbench way DOES force programmers >to update their code, while Apple's doesn't. What's the disadvantage? >What is your point, if you have one? You don't know what you're talking about. The Workbench way doesn't force anything. What Peter was trying to say is, C= could add some workarounds in the OS (The Apple way a.k.a. kludge) to make new stuff work, however Peter doesn't want this to happen. Instead, Peter wants Workbench to provide new functionality and have the Apps upgrade to use it, rather than have the OS exert a placebo on the App tricking it into using a new feature without its knowledge. In 2.0 new features have been added to the OS (I'm not sure) that allow you to open windows that allow you to drop icons into them and have applications notified.(AppWindows?) Drag-an-drop launching of programs have nothing to do with the App at all, it's something the OS does for you. A good example of this is Apple's bubble-help system. What if Apple decided to somehow make bubble-help work on Apps that didn't support it (I have no idea how they would do this, perhaps they would review the manual information for every application ever written on the Mac and include it on the system 7 disk) Instead of this god-awful kludge, System 7 Apps have to upgrade to use this ability. Peter would rather have software updates instead of backward compatible baggage in the OS depending on how much code it took and what sacrifices were made. (I hope I represented yor view here Peter) The Amiga OS is open and dynamic, however when no previous interface existed to certain features, an upgrade is a must. (E.g. balloon help, quicktime on Mac) IBM could get a DIG library in BIOS tommorow, however no programs would take advantage of this since the interface to these routines weren't there before. I've said this all before, sometimes upgrades are required to take advantage of new features that had no previous calling interface. Sometimes you must also sacrifice some backwards compatibility to advance your design (and sometimes it is not possible because of the market, like MS-DOS) -- / INET:rjc@gnu.ai.mit.edu * // The opinions expressed here do not \ | INET:r_cromwe@upr2.clu.net | \X/ in any way reflect the views of my self.| \ UUCP:uunet!tnc!m0023 * /
sho@gibbs.physics.purdue.edu (Sho Kuwamoto) (06/25/91)
In article <2button> peter@Sugar.NeoSoft.com (Peter da Silva) writes: >In article <1button> sho@gibbs.physics.purdue.edu (Sho Kuwamoto) writes: >> Agreed. Could you refresh my memory about the standards for mouse >> buttons on the Amiga? One button brings up the menubar, right? >In any case, one button brings up the menu bar (or, in my case, menu box... >PopUpMenu should be shipped with the system, dammit), and the other selects >the object to be operated on. Double-clicking is only used as a shortcut for >SELECT-MENU-(select "Open")... and that's what "ACTIVATE" should be for. >[...] >Well, it's quite handy in paint programs and the like not to have to worry >about system gadgets taking up space. For animation software, since it's >going to go straight to video, that's even more important. Since there are >two buttons, you can select a number of menu options at a time and have them >take effect all at once without playing with keyboard shortcuts. > >With PopUpMenu you lose the "menu stretch", reaching across a large >display with the mouse to get to the menus. > >Basically, it reduces screen clutter and user actions, and speeds up multiple >selections. Thanks for the clear explanation. Now my comments... On the mac, double-click and shift-click are the basic variants of the mouse click used by applications. It sounds hellish, but for experienced users, it's not too bad. Some examples: * double-click in a word processing application and a whole word is selected. If you then drag the mouse, the selection region grows by word boundaries. * double-click in the Finder to open up a directory/disk or to run the appropriate application. * shift-click to extend selection ranges. Go to the top of your word processing document and click. Go to the bottom and shift-click. The range in between will be selected. * shift-click in the Finder and in drawing programs, to add items to your list of selected objects. These are the kinds of things I expected the other buttons to do. For example, in X windows (as you know) you can use one button to select and another button to extend the selection, while a third button can be used to paste the current selection. From what you are telling me, the most obvious benefit of having two mouse buttons on the Amiga is that: * the menubar can remain hidden until needed. * multiple menu selections can be made at once by holding down one button and clicking the other one. * paint programs have a special use for the menu button. It sounds like all that would happen if the menu button were dropped is that the menubar would have to be on the screen constantly, multiple menu selections would be a thing of the past, and paint programs would have to suffer. While this would change your interface significantly (and I'm sure you like things just the way they are), from an outsider's point of view, it seems like the change wouldn't be all that drastic. What I'm getting at is that there *are* significant differences between the mac and the Amiga. In most ways I prefer the mac, and in some ways I covet the Amiga. When I think about how multiple mouse buttons come into play in defining the differences between the mac and the Amiga, I think about it like this: how would the Amiga differ if it had a single mouse button, and how would a mac differ if it had multiple buttons which were used like the Amiga. From what you say, all it would change on the mac is that the menubar would stop hogging screen real estate. I was hoping it'd take care of *some* of the shift-option-click business. I do see that the vanishing menubar is nice for things like video. You also mention something called PopUpMenu, and how it should come standard. I agree. It seems to me that as long as you are going to have a dedicated menu button, you should have popup menus. Pulldown menus were created so that you could use a menu with only one mouse button. There is a PopUpMenu INIT for the mac, but you have to do something like command-option-shift-click to pop the menu up. -Sho -- sho@physics.purdue.edu
s8105119@ipc04.mqcs.mq.oz.au (Gary Kevin MAKIN) (06/25/91)
In article <1991Jun24.092659.28842@Sugar.NeoSoft.com> peter@Sugar.NeoSoft.com (Peter da Silva) writes: > 2. Since the IFF standard is defined in a system-independent manner > (and in fact is used in EA programs on the IBM-PC and the Mac as > well as the Amiga) it's a superior design. Let's get things in perspective here. In 1984 there was no IFF standard. In fact, the Mac's graphics capabilities were fairly unique (at least compared to other mainstream computers). Therefore, the PICT standard was developed. >-- >Peter da Silva. `-_-' <peter@sugar.neosoft.com>. > 'U` "Have you hugged your wolf today?" Gary Makin
peter@Sugar.NeoSoft.com (Peter da Silva) (06/25/91)
The Great, The Powerful, Daniel Tracy:
"Excuse me? Are you flaming Apple for being able to do something
Commodore couldn't? That is, cause applications to open documents by
double-clicking on them even if the app is running, without apps having to
be rewritten?"
-- <111@ryptyde.UUCP>
Huh? No, the Amiga has had that ability from day 1. It's called "multitasking".
I remember a few releases ago Andy Ongun was talking about how this new
capability was forcing him to change his program. It seems he was putting
his own icons on the desktop while Finder was turned off.
What the Workbench does is allow programs to register their windows with
it so you can drag and drop icons onto them. Sort of virtual folders.
--
Peter da Silva. `-_-' <peter@sugar.neosoft.com>.
'U` "Have you hugged your wolf today?"kdarling@hobbes.catt.ncsu.edu (Kevin Darling) (06/25/91)
>Since the IFF standard is defined in a system-independent manner >(and in fact is used in EA programs on the IBM-PC and the Mac as >well as the Amiga) it's a superior design. Well, I use and like IFF... but I wouldn't claim it as "superior" :) Heck, the IFF chunks used by the Amiga are as Amiga-specific as you can get: a limited number of bitplanes in the ANIM files, 6-bit HAM (versus system independent 12-bit) files, signed 8-bit audio, big-endian layout, etc. Write some HAM->chunky pixel conversion programs and you'll start cussing. The main "system-independent" claim of IFF is that the chunks always contain enough info to convert the files to another format (well, ALMOST always... the halfbrite and HAM Amiga ILBMs ended up needed another type chunk :-(. >If you want to find out more about IFF, look it up. > It's a published standard. ^^^^^^^^^^^^^^^^^^ Yes, _that's_ the most important feature. - kevin <kdarling@catt.ncsu.edu>
morris-ng@cup.portal.com (Yuklung Morris Ng) (06/25/91)
In Amiga shell, ALIAS is the command similar to the Mac alias which is only capable of doing stuff in GUI. For Amiga GUI, we have something call "IconX" which, may be less straight forward than the Mac's alias, it will effectively do the same thing, plus more for document specific scripts. Oh, Amiga DOES NOT need a lot of desktop space compared to Mac, as we have screens, which a lot of Mac users still not quite understand... - Morris
torrie@cs.stanford.edu (Evan Torrie) (06/25/91)
peter@Sugar.NeoSoft.com (Peter da Silva) writes: >In article <51086@ut-emx.uucp> awessels@ccwf.cc.utexas.edu (Allen Wessels) writes: >> If they don't use a feature, they're "old technology" >No, they're "old technology" because they screwed up so badly on the original >design. It's got nothing to do with "features". Multitasking isn't a "feature", >it's a basic capability that should be the core of *any* system since about >1965. Geez. I didn't think the CBM Pet, or the C-64 had multitasking. Guess Commodore screwed up royally on those, huh? -- ------------------------------------------------------------------------------ Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu "And in the death, as the last few corpses lay rotting in the slimy thoroughfare, the shutters lifted in inches, high on Poacher's Hill..."
torrie@cs.stanford.edu (Evan Torrie) (06/25/91)
gblock@csd4.csd.uwm.edu (Gregory R Block) writes: >From article <1991Jun22.213406.13336@neon.Stanford.EDU>, by torrie@cs.stanford.edu (Evan Torrie): >> I assume there are lots of good points to back up that assertion. >There are, but there's no point. It's >pointless, and it's pretty well based on tastes... So they aren't technical points, but merely opinions? Doesn't sound like a good enough reason to say blankly "it sucks"... >> I would guess most power users will find out as soon as they start >> using System 7, if they bother to look at the Hints and Tips in various >> magazines, online forums etc. ResEdit has always been one of the >> primary tools in any power user's repertoire. >Does ResEdit come with the OS? :) It doesn't come on the System disks, but it's free if you want it... (i.e. it's available for ftp, as well as on user group disks, it even has its own book in the shops now). >Still sounds like a way of getting >around something the OS has set up. If it was meant to do it, it >would do it. I repeat. It's not the OS which has the responsibility for what the application decides it can open. It only reflects (via auto-highlighting) what the application author has indicated he wants the Finder to do in the case of drag-and-drop. >> I don't think so. In fact, if you look at many of the great ideas, they're >> great because they combine two or more disparate approaches into a single >> combination which has the good features of both, but eliminates the bad. >Which? Well, lots of examples in Computer Science... e.g. priority scheduling schemes. You take Unix which has process aging of priorities, and a real-time scheduler like Amiga OS, and combine the two so that all processes with priorities above 0 are done on a real-time basis [i.e. run to completion], while those under 0 are aged like Unix. (This is, I believe what VMS supports). Also segments vs page-based OS memory schemes. Segments give you protection over the exact extent of your process, but are inflexible in terms of requiring contiguous space. Pages don't require contiguous space, but they have internal fragmentation at the end of your process, because they must be a fixed size. Therefore, you can combine the two (as IBM does in its mainframe architectures) to have pages within segment tables - thereby giving you exact protection, but the flexibility of paging. Similar things occur in architecture... caches for example. You have main memory, which is big, but slow, and internal registers, which are fast, but few. Combine the two ideas, and you have a cache - reasonably large [to satisfy most requests], yet fast enough to keep the processor from stalling too often. -- ------------------------------------------------------------------------------ Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu "And in the death, as the last few corpses lay rotting in the slimy thoroughfare, the shutters lifted in inches, high on Poacher's Hill..."
torrie@cs.stanford.edu (Evan Torrie) (06/25/91)
rjc@churchy.gnu.ai.mit.edu (Ray Cromwell) writes: > A good example of this is Apple's bubble-help system. What if Apple >decided to somehow make bubble-help work on Apps that didn't support it >(I have no idea how they would do this, perhaps they would review the >manual information for every application ever written on the Mac >and include it on the system 7 disk) Instead of this god-awful kludge, >System 7 Apps have to upgrade to use this ability. Or, the local power user can add help balloons to old applications without having to touch the application code, since help balloons are simply resources. > Peter would rather have software updates instead of backward >compatible baggage in the OS depending on how much code it took and >what sacrifices were made. (I hope I represented yor view here Peter) Yes, it depends on what effort is needed, and how useful the feature is. For example, Apple no longer supports MFS 400K disks in System 7. MFS used to require the Finder to go through a lot of chicanery to present the illusion of real folders, when in fact, the disk was a flat filing system. Apple supported it for five years after its demise, but no longer. -- ------------------------------------------------------------------------------ Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu "And in the death, as the last few corpses lay rotting in the slimy thoroughfare, the shutters lifted in inches, high on Poacher's Hill..."
peterk@cbmger.UUCP (Peter Kittel GERMANY) (06/25/91)
In article <1991Jun24.094738.29131@Sugar.NeoSoft.com> peter@Sugar.NeoSoft.com (Peter da Silva) writes: >In article <5342@dirac.physics.purdue.edu> sho@gibbs.physics.purdue.edu (Sho Kuwamoto) writes: >> Agreed. Could you refresh my memory about the standards for mouse >> buttons on the Amiga? One button brings up the menubar, right? > >The two buttons are SELECT and MENU. A third button for ACTIVATE would be >better, but it's too late for that. > >In any case, one button brings up the menu bar ... May I remark that this is IMHO one on the strong features of the Amiga GUI: Because of the existence of this extra menu button, we spare one line on the display for better purpose! When you look at Windows/Mac/ST, they permanently display the menu bar, thus wasting this display line. And they *MUST* display it, because else (at least with the one-button Mac mouse) there were no way to know for the system, does the user just want to paint to the upper line or wants he to invoke the menu. -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
jbickers@templar.actrix.gen.nz (John Bickers) (06/25/91)
Quoted from <111@ryptyde.UUCP> by dant@ryptyde.UUCP (Daniel Tracy): [quoting some unattributed citizen] > "No. I suppose you could use a kludge to give the appearance of having them > do this. Personally, I'd rather not install such a prop and force application > Excuse me? Are you flaming Apple for being able to do something Commodore > couldn't? That is, cause applications to open documents by double-clicking Not "couldn't". Wouldn't. I can believe Apple doesn't have a problem with this sort of hack, since they "multitask" using similar levels of chicanery. > to update their code, while Apple's doesn't. What's the disadvantage? One approach is clean. The other is not. -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Endless variations, make it all seem new" - Devo. ***
farren@well.sf.ca.us (Mike Farren) (06/25/91)
dant@ryptyde.UUCP (Daniel Tracy) writes: >You stated that the file type of a Macintosh file was kept in the >resource fork. It isn't. Where is it kept, then? Last time *I* looked, file types were definitely resources, and thus *had* to be in the resource fork. Has this changed in 7.0? If so, why doesn't EVERYTHING break? >Our bitmap, drawing, text, formatted text, movie, sound, etc. >don't need resources, although they can be transfered into one (some of >them). Hmm? Many of those ARE resources, kept in the resource fork. Are you saying this is not so? If so, what about those that are? >You can just as easily use them on other machines. Yeah, so? You have to go through hoops to do so. I did the Amiga version of Crystal Quest, and one of the biggest pains in the butt of the entire conversion was pulling the data out of the resources and converting it into some usable format on the Ami. Just how many machines, pray tell, can handle PICT resources directly? -- Mike Farren farren@well.sf.ca.us
s8105119@ipc04.mqcs.mq.oz.au (Gary Kevin MAKIN) (06/25/91)
In article <13361@uwm.edu> gblock@csd4.csd.uwm.edu writes: >Does ResEdit come with the OS? :) Still sounds like a way of getting >around something the OS has set up. If it was meant to do it, it >would do it. "Fixing" the program with ResEdit is.... well, a >kludge. But once again, that's my opinion shining through. Firstly, ResEdit is available easily enough. If someone's heard of ResEdit then they probably have a bit of an idea where to find it (try user groups, ftp.apple.com, etc). Secondly, this isn't a case of making a program do something it wasn't meant to do. For example, Microsoft Word will open many types of files including MacWrite files. Naturally, Word does not contain any icons for MacWrite files, only for it's native file formats (text, Word, dictionaries, etc). So, Word does not have an FREF resouce for file of type MACA (MacWrite). Therefore, the Finder does not know that Word will open MacWrite files. By adding an FREF resource for a file type of MACA, the Finder will then know that Word can open MACA files. This is not a kludge. It is simply one of the things that Microsoft will be changing when they bring out the next version of Word. The fact that the current version of Word does not have a MACA FREF is because it is not Sys 7 savvy. If, by adding or changing a resouce using ResEdit, I could make the current version of Word accept Apple Events, or start using Publish and Subscribe, would this be a kludge too? Or would it be a sign of a good implementation of a new system feature? > >Greg Gary Makin.
dant@ryptyde.UUCP (Daniel Tracy) (06/25/91)
Responding to the following: "> This does not happen on an Amiga. When you drag an icon, the actual > image of the icon is dragged, and not an outline. This is why the idea of > using the mouse pointer as the "hot spot" makes absolutely no sense at It makes perfect sense. I don't need to see the exact position of my hands when I scratch my back. Understand?" I'm sorry I'm replying via my old quoting method, but my reader just can't seem to respond to John Bickers' messages. Give me a break, John. Try distinguishing between sight and tactile sense! Sure, you don't need to see your hand, but can you feel edge of the icon?
dant@ryptyde.UUCP (Daniel Tracy) (06/25/91)
Responding to the following:
"Now I'll have to plead ignorance. This seems again entirely irrelevant to my
message. Perhaps you would like to explain what that has to do with:
1. The basic capability of IFF and the Mac's typed files are
equivalent.
2. Since the IFF standard is defined in a system-independent manner
(and in fact is used in EA programs on the IBM-PC and the Mac as
well as the Amiga) it's a superior design."
How are Macintosh file formats system-dependant? These standards are also
published. Give me a break. I'd also like to point out that your point
hasn't changed, but your argument has since I corrected you, and then you
flame me about it!chuck@brain.UUCP (Chuck Shotton) (06/25/91)
In article <43643@cup.portal.com>, morris-ng@cup.portal.com (Yuklung Morris Ng) writes: > Oh, Amiga DOES NOT need a lot of desktop space compared to Mac, as we have > screens, which a lot of Mac users still not quite understand... > Well, that shows what a wonderfully intuitve box the Amiga is, doesn't it? ----------------------------------------------------------------------- Chuck Shotton Internet: cshotton@girch1.med.uth.tmc.edu BIAP Systems UUCP: ...!buster!brain!chuck "Your silly quote here." AppleLink: D1683 MacNet: shotton
rjc@churchy.gnu.ai.mit.edu (Ray Cromwell) (06/25/91)
In article <D2150025.izm3tm@brain.UUCP> chuck@brain.uucp writes: > >In article <43643@cup.portal.com>, morris-ng@cup.portal.com (Yuklung Morris Ng) writes: >> Oh, Amiga DOES NOT need a lot of desktop space compared to Mac, as we have >> screens, which a lot of Mac users still not quite understand... >> > >Well, that shows what a wonderfully intuitve box the Amiga is, doesn't it? No, I think it show the kind of intelligence the average Mac user has, and the kind of people the machine is targeted at. :) But, as an explanation. The Amiga has Windows (which the Mac user will recognize.) and in addition to windows, the Amiga has a notion of "viewports" (the user need not know about this) Viewports allow the Amiga programmer to open multiple resolutions on the same monitor all at once. So if he wanted, the top of the screen could be a hires control panel and the bottom part of the display could be a lores, but higher amount of color area. Viewports also allow the Amiga programmer to reuse sprites. Intuition, the Amiga GUI manager, uses ViewPorts to build Screens. Screens are sort of multiple desktop areas. For instance, I could have a 640x480 4 color "Workbench" screen (analogous to Finder) and on another Screen I could have a HAM mode paint program. I can switch between these screens as easily as windows and I can drag them around. The advantage is, I can run my desktop in a 4 color 3d type screen (fast) and run the paint program on a slower screen more colorful screen. It also results in faster rendering since there would be no overlapping windows if the application used its own screen. >----------------------------------------------------------------------- >Chuck Shotton Internet: cshotton@girch1.med.uth.tmc.edu >BIAP Systems UUCP: ...!buster!brain!chuck >"Your silly quote here." AppleLink: D1683 MacNet: shotton -- / INET:rjc@gnu.ai.mit.edu * // The opinions expressed here do not \ | INET:r_cromwe@upr2.clu.net | \X/ in any way reflect the views of my self.| \ UUCP:uunet!tnc!m0023 * /
peterk@cbmger.UUCP (Peter Kittel GERMANY) (06/25/91)
In article <5353@dirac.physics.purdue.edu> sho@gibbs.physics.purdue.edu (Sho Kuwamoto) writes: > >On the mac, double-click and shift-click are the basic variants of the >mouse click used by applications. It sounds hellish, but for >experienced users, it's not too bad. Some examples: > > * double-click in a word processing application and a whole word > is selected. If you then drag the mouse, the selection region > grows by word boundaries. Ok for a word. But to select a greater area, why not just click at the beginning (*ONCE*) and drag the mouse to the end? Many Amiag programs do it this way. Is there really always needed a double-click? > * double-click in the Finder to open up a directory/disk or to run > the appropriate application. Same on Amiga > * shift-click to extend selection ranges. Go to the top of your > word processing document and click. Go to the bottom and > shift-click. The range in between will be selected. As stated above, this also works with dragging. Even the famous AmigaBasic editor scrolls its window thus expanding the selected range, when you drag the mouse below or over the top of the window. > * shift-click in the Finder and in drawing programs, to add items > to your list of selected objects. Same on Amiga > how would the Amiga differ if >it had a single mouse button, and how would a mac differ if it had >multiple buttons which were used like the Amiga. From what you say, >all it would change on the mac is that the menubar would stop hogging >screen real estate. I was hoping it'd take care of *some* of the >shift-option-click business. As stated above, I don't think your issue of the shift-clicks is not only a question of the system, but also of intuitive programming. This can obviously also be solved with one single button, as demon- strated above. -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
gblock@csd4.csd.uwm.edu (Gregory R Block) (06/26/91)
From article <D2150025.izm3tm@brain.UUCP>, by chuck@brain.UUCP (Chuck Shotton): > > In article <43643@cup.portal.com>, morris-ng@cup.portal.com (Yuklung Morris Ng) writes: >> Oh, Amiga DOES NOT need a lot of desktop space compared to Mac, as we have >> screens, which a lot of Mac users still not quite understand... >> > > Well, that shows what a wonderfully intuitve box the Amiga is, doesn't it? Actually, yes. Either that, or it shows that MultiFinder is counterintuitive, because it is quite similar... Greg -- Socrates: "I drank WHAT????" LMFAP: "Next time you see me, it won't be me." Wubba: "A dream is nothing more than a wish dipped in chocolate and sprinkled with a little imagination." (From my poem, "A Dream") -Wubba
navas@cory.Berkeley.EDU (David C. Navas) (06/26/91)
In article <1991Jun25.053133.671@neon.Stanford.EDU> torrie@cs.stanford.edu (Evan Torrie) writes: > Geez. I didn't think the CBM Pet, or the C-64 had multitasking. Guess >Commodore screwed up royally on those, huh? I am very grateful that Cmdre came into Amiga Corp.'s life late in the game, or we would have had another C64. As it is, management has been loathe to fire people who only know how to sell game machines and hire someone who knows how to sell a "real" computer. But there you go. Draw you own conclusions about your question :) David Navas navas@cory.berkeley.edu 2.0 :: "You can't have your cake and eat it too." Also try c186br@holden, c260-ay@ara and c184-ap@torus
chucks@pnet51.orb.mn.org (Erik Funkenbusch) (06/26/91)
Am i missing something on this Drag and drop thing? it seems to me that WB 2.0 already has this feature in the form of AppIcons, and AppWindows. There is a program called toolmanager which when you drag an icon ontop of it's AppIcon it will load that application into the tools menu of 2.0. And the 2.0 IconEd supports Dragging an icon off the workbench into the icon editing window to load it. Am i missing something or is Drag and Drop different than AppIcons or AppWindows? .--------------------------------------------------------------------------. | UUCP: {amdahl!tcnet, crash}!orbit!pnet51!chucks | "I know he's come back | | ARPA: crash!orbit!pnet51!chucks@nosc.mil | from the dead, but do | | INET: chucks@pnet51.orb.mn.org | you really think he's | |-------------------------------------------------| moved back in?" | | Amiga programmer at large, employment options | Lou Diamond Philips in | | welcome, inquire within. | "The First Power". | `--------------------------------------------------------------------------'
awessels@ccwf.cc.utexas.edu (Allen Wessels) (06/26/91)
In article <25668@well.sf.ca.us> farren@well.sf.ca.us (Mike Farren) writes: >Yeah, so? You have to go through hoops to do so. I did the Amiga version >of Crystal Quest, and one of the biggest pains in the butt of the entire >conversion was pulling the data out of the resources and converting it >into some usable format on the Ami. Just how many machines, pray tell, >can handle PICT resources directly? How did you go about converting the PICTs? I just opened a PICT out of the game Diamonds (I don't have Crystal Quest) with ResEdit, copy-and-pasted it into PixelPaint Pro. To speed things up I'd use CanOpener to yank all the PICTs out of Crystal Quest and then use something to convert the PICT files to GIF, color TIFF or whatever. I think the Sun I'm logged into can read PICT files and produce a number of other formats from them, and if I remember correctly, the Hijak (sp?) software can convert from PICTs on the PC. (Most of this is hypothetical. I would send the file to the Amiga as an 8 bit GIF probably and let the Amiga deal with getting it into the target format.)
taab5@isuvax.iastate.edu (Marc Barrett) (06/26/91)
In article <13420@uwm.edu>, gblock@csd4.csd.uwm.edu (Gregory R Block) writes: >From article <D2150025.izm3tm@brain.UUCP>, by chuck@brain.UUCP (Chuck Shotton): >> >> In article <43643@cup.portal.com>, morris-ng@cup.portal.com (Yuklung Morris Ng) writes: >>> Oh, Amiga DOES NOT need a lot of desktop space compared to Mac, as we have >>> screens, which a lot of Mac users still not quite understand... >>> >> >> Well, that shows what a wonderfully intuitve box the Amiga is, doesn't it? > >Actually, yes. Either that, or it shows that MultiFinder is >counterintuitive, because it is quite similar... Multifinder is very distantly similar. On an Amiga, you can have as many screens as chip RAM can hold, and switching between them is very rapid any uses essentially zero processor time. On a MAC, it is fun to run a program like StuffIt and then switch to the Finder. It can take the OS as much as half a minute to redraw the desktop, even on a MAC SE/30. The MAC does NOT have multiple screen capability. It has software almost-virtual-multiple-screens-loaded-from-disk. When you switch to a different application's "screen" under multifinder, the current screen is saved to disk and the screen of the application is loaded from disk. The MAC has only one area of memory reserved for the display, and this area is wiped and redrawn when you switch applications under multifinder. On the Amiga, you have truly seperate areas of memory reserved for each screen, allocated in a dynamic fashion. When a new screen is created, a new area of chip RAM is set aside for that screen. A single hardware register determines which screen is the frontmost screen, and other registers determine how the screens are 'layored'. For an everyday description, the Amiga's multiple screens is like having multiple pieces of paper in a pile, and bringing the sheet of paper on the bottom of the pile to the top is easy. The MAC is analogous to having only a single piece of paper, that has to be erased and redrawn. > >Greg >-- >Socrates: "I drank WHAT????" >LMFAP: "Next time you see me, it won't be me." >Wubba: "A dream is nothing more than a wish dipped in chocolate and sprinkled >with a little imagination." (From my poem, "A Dream") -Wubba ------------------------------------------------------------- / Marc Barrett -MB- | BITNET: XGR39@ISUVAX.BITNET / / ISU COM S Student | Internet: XGR39@CCVAX.IASTATE.EDU / ------------------------------------------------------------ \ The great thing about standards is that / \ there are so many of them to choose from. / -------------------------------------------------------
smp@myamiga.UUCP (Steven M. Palm) (06/26/91)
In <1991Jun24.150700.2117@mintaka.lcs.mit.edu> rjc@churchy.gnu.ai.mit.edu (Ray Cromwell) writes: > > The problem is, when Apple does use a feature, they proclaim they >invented it and copyright it. I have no qualms with sharing ideas What are the odds that once Apple and Big Blue come out with PINK (if they do) that Apple sues IBM for some sort of infringement and takes over IBM. What a world, what a world.... :-) >/ INET:rjc@gnu.ai.mit.edu * // The opinions expressed here do not \ >| INET:r_cromwe@upr2.clu.net | \X/ in any way reflect the views of my self.| >\ UUCP:uunet!tnc!m0023 * / -- /-----------------+--------------------------+-----------------------------\ | smp@myamiga.UUCP | myamiga!smp@fps.mcw.edu | rutgers!uwm!fps!myamiga!smp | \-----------------+--------------------------+-----------------------------/
matt@vrtwo.UUCP (Matt Buford) (06/26/91)
About all this drag-and-drop stuff... On the Amiga you can just double click on the document! Why drag it over to it's app? Just click twice on the document and it knows which application created it... -- .____________________________________________________________________________. | | | | Please send all | Sysop of the Virtual Reality BBS | | complaints to | uunet.uu.net!umich!vela!sycom!vrtwo!matt | | | 808-337-1560 * 2400 baud * C-Net Amiga | | >NIL: | USR 14400 baud DS on order - 40 megs storage | |__________________________|_________________________________________________|
s8105119@ipc07.mqcs.mq.oz.au (Gary Kevin MAKIN) (06/26/91)
In article <25668@well.sf.ca.us> farren@well.sf.ca.us (Mike Farren) writes: >>You stated that the file type of a Macintosh file was kept in the >>resource fork. It isn't. > >Where is it kept, then? Last time *I* looked, file types were definitely >resources, and thus *had* to be in the resource fork. Has this changed >in 7.0? If so, why doesn't EVERYTHING break? This is very simple. The file type is *not* kept in the resource fork of a file. It has never been kept there. The file type is in the file header. Proof: every file has a file type. Not every file has a resource fork. QED. There is sometimes a resource with the same ID as the file type, but this is not where the file type information is stored. > >>Our bitmap, drawing, text, formatted text, movie, sound, etc. >>don't need resources, although they can be transfered into one (some of >>them). > >Hmm? Many of those ARE resources, kept in the resource fork. Are you >saying this is not so? If so, what about those that are? Lets use PICTs as an example. There is a file format PICT and there is a standard resource called PICT. These use the same format and can be easily converted between. To get a resource and turn it into a file, use ResEdit to copy the PICT into the clipboard. Open MacDraw and past the PICT in. Now save this MacDraw document as a PICT file. Reverse the procedure to go in the other direction. > >>You can just as easily use them on other machines. > >Yeah, so? You have to go through hoops to do so. I did the Amiga version >of Crystal Quest, and one of the biggest pains in the butt of the entire >conversion was pulling the data out of the resources and converting it >into some usable format on the Ami. Just how many machines, pray tell, >can handle PICT resources directly? Maybe you should have turned the PICT resource into a file as mentioned above, and then used something like Giffer to turn this into a GIF file. Or used another program for a different format. Whatever you would like. Crystal Quest, and most other Mac games, use PICT resources so that all the graphics are contained in the one file and are then easily available. This make life much simpler (on the Mac) than having a directory full of small misc graphics files. I consider it one of the best results of using a resource fork. > >-- >Mike Farren farren@well.sf.ca.us Gary Makin
gblock@csd4.csd.uwm.edu (Gregory R Block) (06/26/91)
From article <1991Jun25.221925.11815@news.iastate.edu>, by taab5@isuvax.iastate.edu (Marc Barrett):
> The MAC does NOT have multiple screen capability. It has software
I know, but I was trying to put screens in a way that a Mac user would
understand. In other words, make every word shorter than 5 sentences,
and use a lot of grunts. :)
Greg
--
Socrates: "I drank WHAT????"
LMFAP: "Next time you see me, it won't be me."
Wubba: "A dream is nothing more than a wish dipped in chocolate and sprinkled
with a little imagination." (From my poem, "A Dream") -Wubbatorrie@cs.stanford.edu (Evan Torrie) (06/26/91)
peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: >In article <5353@dirac.physics.purdue.edu> sho@gibbs.physics.purdue.edu (Sho Kuwamoto) writes: >> >> * double-click in a word processing application and a whole word >> is selected. If you then drag the mouse, the selection region >> grows by word boundaries. >Ok for a word. But to select a greater area, why not just click at the >beginning (*ONCE*) and drag the mouse to the end? Many Amiag programs >do it this way. Is there really always needed a double-click? You can do this on the Mac, but the double click-drag means that you want the selection to jump by word boundaries, rather than character boundaries. This is extremely useful because you don't end up fluffing around trying to position the mouse in the region of a single character [especially painful with 9 point fonts]. I'd say at least 90% of the time, you want to select a group of full words when editing text, so this actually ends up being a time saver. >> * shift-click to extend selection ranges. Go to the top of your >> word processing document and click. Go to the bottom and >> shift-click. The range in between will be selected. >As stated above, this also works with dragging. Even the famous >AmigaBasic editor scrolls its window thus expanding the selected range, >when you drag the mouse below or over the top of the window. Same on Mac programs. But once again, Shift Clicking is a lot faster when you have a 600 page document. -- ------------------------------------------------------------------------------ Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu Fame, fame, fame... What's it good for? Ab-so-lute-ly nothing
lron@easy.lrcd.com (Dwight Hubbard) (06/26/91)
In article <1991Jun24.094738.29131@Sugar.NeoSoft.com> peter@Sugar.NeoSoft.com (Peter da Silva) writes: >Basically, it reduces screen clutter and user actions, and speeds up multiple >selections. Good explanation, but you happen to have any Idea why the damn menus are in screen title bar instead of the title bar for the window were they belong?? -- ---------------------------------------------------------------------- -Dwight Hubbard INTERNET: lron@easy.lrcd.com - -Kaneohe, Hawaii USENET : ...!uunet!easy!lron - - BIX : lron - ----------------------------------------------------------------------
jbickers@templar.actrix.gen.nz (John Bickers) (06/26/91)
Quoted from <1991Jun25.055430.1316@neon.Stanford.EDU> by torrie@cs.stanford.edu (Evan Torrie): > >> I don't think so. In fact, if you look at many of the great ideas, they're > >> great because they combine two or more disparate approaches into a single > completion], while those under 0 are aged like Unix. (This is, I believe > what VMS supports). Are you saying that VMS is better than Unix? > Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Endless variations, make it all seem new" - Devo. ***
jbickers@templar.actrix.gen.nz (John Bickers) (06/26/91)
Quoted from <118@ryptyde.UUCP> by dant@ryptyde.UUCP (Daniel Tracy): > "> This does not happen on an Amiga. When you drag an icon, the actual > > image of the icon is dragged, and not an outline. This is why the idea of > It makes perfect sense. I don't need to see the exact position of my > hands when I scratch my back. Understand?" > distinguishing between sight and tactile sense! Sure, you don't need to > see your hand, but can you feel edge of the icon? Hm. Didn't expect to have to explain. Moving a solid icon over another, this is the info one has to determine where to let go of the mouse button: 1. One saw the target icon before dragging the solid icon over it. 2. One can see the mouse pointer. Isn't that enough? My point is you don't need to know, to the exact pixel position, the location of things in this operation. You can be general, just like you are when you do other things where you don't have exact information (no matter what the sense involved). -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Endless variations, make it all seem new" - Devo. ***
jbickers@templar.actrix.gen.nz (John Bickers) (06/26/91)
Quoted from <119@ryptyde.UUCP> by dant@ryptyde.UUCP (Daniel Tracy):
[quoting someone else]
> 1. The basic capability of IFF and the Mac's typed files are
> equivalent.
So you can add "chunks", and things like that (the main advantage
of IFF, next to being commonly used)? I've seen the format for what
appear to be standard Macintosh picture files, and it is flaky in
the extreme.
Some files have an extra piece of junk on the front, while others
don't (and in my program, I tell by checking if some particular
byte is an alphanumeric... there may be some better way, but it
wasn't apparent at the time). And the size of the picture is fixed.
The only nice thing was that they used the same compression scheme
that IFF ILBMs use. :)
These are .MAC files on the local boards.
--
*** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz ***
*** "Endless variations, make it all seem new" - Devo. ***chucks@pnet51.orb.mn.org (Erik Funkenbusch) (06/26/91)
taab5@isuvax.iastate.edu (Marc Barrett) writes: > I was referring to such programs as Brush2Icon, which are actually >easier to use than IconEdit. With Brush2Icon, a person can whip up a >brush with a paint program, then have the brush rapidly converted to an >icon with one command. I don't make icons very often, but whenever I I have yet to come across *ANYTHING* easier to use than IconEdit 2.0. what could be easier than dragging an icon off the workbench into the iconedit window? >do, this method is the one I use. > ------------------------------------------------------------- > / Marc Barrett -MB- | BITNET: XGR39@ISUVAX.BITNET / >/ ISU COM S Student | Internet: XGR39@CCVAX.IASTATE.EDU / >------------------------------------------------------------ >\ The great thing about standards is that / > \ there are so many of them to choose from. / > ------------------------------------------------------- .--------------------------------------------------------------------------. | UUCP: {amdahl!tcnet, crash}!orbit!pnet51!chucks | "I know he's come back | | ARPA: crash!orbit!pnet51!chucks@nosc.mil | from the dead, but do | | INET: chucks@pnet51.orb.mn.org | you really think he's | |-------------------------------------------------| moved back in?" | | Amiga programmer at large, employment options | Lou Diamond Philips in | | welcome, inquire within. | "The First Power". | `--------------------------------------------------------------------------'
lron@easy.lrcd.com (Dwight Hubbard) (06/26/91)
In article <5215@orbit.cts.com> chucks@pnet51.orb.mn.org (Erik Funkenbusch) writes: >Am i missing something on this Drag and drop thing? it seems to me that WB >2.0 already has this feature in the form of AppIcons, and AppWindows. There >is a program called toolmanager which when you drag an icon ontop of it's >AppIcon it will load that application into the tools menu of 2.0. And the 2.0 > IconEd supports Dragging an icon off the workbench into the icon editing >window to load it. Am i missing something or is Drag and Drop different than >AppIcons or AppWindows? I want to be able to select Leave out at the workbench menu for my lharc program and be able to drag the icon for an .lzh archive and drop it right on the lharc program icon without having to shift double click or start the lharc program first. -- ---------------------------------------------------------------------- -Dwight Hubbard INTERNET: lron@easy.lrcd.com - -Kaneohe, Hawaii USENET : ...!uunet!easy!lron - - BIX : lron - ----------------------------------------------------------------------
dant@ryptyde.UUCP (Daniel Tracy) (06/26/91)
Responding to the following: "In 2.0 new features have been added to the OS (I'm not sure) that allow you to open windows that allow you to drop icons into them and have applications notified.(AppWindows?) Drag-an-drop launching of programs have nothing to do with the App at all, it's something the OS does for you." Exactly. Gee, but apps didn't have to be rewritten to take advantage of Drag-and-drop, did they? The point is, the more the OS does for apps, the more advances can be made without programmers updating their code to take advantage of it. This is exactly how it is with the OS causing an application to open a document even though it's already open. In what way is it a kludge? Another example: User is using DiskDoubler, a simple utility that auto- compresses (almost) all the files on your hard disk, then when they're opened, they're automatically decompressed. Is this a kludge as well? Give me a break. The ultimate example is MS-DOS. It has so little resources, does so little, and is so lame-brained that multitasking had to be done at the chip level! (V86 mode) But of course, Intel was more than willing to accomodate them since that's their only (nearly) market.
dant@ryptyde.UUCP (Daniel Tracy) (06/26/91)
Responding to the following: "I remember a few releases ago Andy Ongun was talking about how this new capability was forcing him to change his program. It seems he was putting his own icons on the desktop while Finder was turned off." I'm finding it hard to understand you. How do you turn the Finder off?
rhealey@kas.helios.mn.org (Rob Healey) (06/26/91)
In article <1991Jun19.195839.26050@milton.u.washington.edu> stevep@wrq.com (Steve Poole) writes: >Whereas the Mac is cursed with standards like TEXT, PICT, and numerous >others, all of which are self-identifying. That's why drag-and-drop is NOT >a kludge. You're confusing the simple steps needed to tell the Finder that >a pre-7.0 application can open non-native files with the actual implementation >of that feature. Presumably, any new application will contain an exhaustive >list of types it understands, now that drag-and-drop is available. Ahhhh, that's the grreat thing about standards, there's so MANY to choose from... Maybe an interchange format that has a type field and one file format would be a tad easier to handle? After all, just open one file that contains sound, graphics, text, binarys and look at the header record inside to see if it contains anything of interest to the app. Then again, maybe as many file types as RS232 standards is a better idea... -Rob
torrie@cs.stanford.edu (Evan Torrie) (06/26/91)
jbickers@templar.actrix.gen.nz (John Bickers) writes: >Quoted from <1991Jun25.055430.1316@neon.Stanford.EDU> by torrie@cs.stanford.edu (Evan Torrie): >> completion], while those under 0 are aged like Unix. (This is, I believe >> what VMS supports). > Are you saying that VMS is better than Unix? Is this a loaded question? :-) I'm sure Ken Olsen thinks VMS is better than Unix. I think, in terms of their market today, that VMS is a better designed, and more well thought out OS, than the Unix which has grown from a simple time-sharing OS into something for everyone. Of course, this may be because VMS doesn't have to be portable, and can be tied down to a particular architecture (namely the VAX), thus avoiding the nastiness of Unix when it comes to things like VM etc... -- ------------------------------------------------------------------------------ Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu Murphy's Law of Intelism: Just when you thought Intel had done everything possible to pervert the course of computer architecture, they bring out the 860
stevep@wrq.com (Steve Poole) (06/27/91)
In article <1991Jun25.221925.11815@news.iastate.edu> taab5@isuvax.iastate.edu writes: > Multifinder is very distantly similar. On an Amiga, you can have as many >screens as chip RAM can hold, and switching between them is very rapid any >uses essentially zero processor time. On a MAC, it is fun to run a program >like StuffIt and then switch to the Finder. It can take the OS as much as >half a minute to redraw the desktop, even on a MAC SE/30. > > The MAC does NOT have multiple screen capability. It has software >almost-virtual-multiple-screens-loaded-from-disk. When you switch to a >different application's "screen" under multifinder, the current screen >is saved to disk and the screen of the application is loaded from disk. >The MAC has only one area of memory reserved for the display, and this >area is wiped and redrawn when you switch applications under multifinder. What the hell are you talking about? If you know as little about the Amiga as you do about the Mac then I'd better keep a salt lick handy when reading your posts. Can you recommend a feed store/Amiga dealer in the Seattle area? > / Marc Barrett -MB- | BITNET: XGR39@ISUVAX.BITNET / -- -------------------------------------------------------------------------- -- INTEL 80x86: Just say NOP -- Internet: stevep@wrq.com -- AOL: Spoole -- --------------------------------------------------------------------------
gaynor@agvax2.ag.ohio-state.edu (06/27/91)
In article <1991Jun25.160016.10433@mintaka.lcs.mit.edu>, rjc@churchy.gnu.ai.mit.edu (Ray Cromwell) writes: >In article <D2150025.izm3tm@brain.UUCP> chuck@brain.uucp writes: >>In article <43643@cup.portal.com>, morris-ng@cup.portal.com (Yuklung Morris Ng) writes: >>> >>> Oh, Amiga DOES NOT need a lot of desktop space compared to Mac, as we have >>> screens, which a lot of Mac users still not quite understand... >> >>Well, that shows what a wonderfully intuitve box the Amiga is, doesn't it? > > No, I think it show the kind of intelligence the average Mac >user has, and the kind of people the machine is targeted at. :) [explanation of Amiga "screens" deleted...] Well, I won't argue Amiga vs. Mac. I have an SE/30, my fiancee has an A500. I've been spending more time on the A500 for the past few days, since we bought Lemmings over the weekend. 8-D (How does one make an insane smiley?) But I don't think that the "screens" are very intuitive. Once you figure them out, they're great - it's nice to have three layered screens, 2 dedicated to full-screen apps, and the other dedicated to WorkBench and some windowing apps. However, the screens aren't quite obvious. Clicking on the menu bar with the left button and dragging it down to show the screen behind just isn't one of those things that come to you - especially when there is no visual indicator to show that there -is- a screen behind. Perhaps, with some kind of notifier that there is a layered screen, it could be more intuitive. As for the "intelligence" shot, well, it was smileyed, so I won't bother spouting the old-time Mac Religion. Save us both, eh? --- Jim Gaynor - AgVAX System Manager - Academic Computing - Ohio State University VMS:<gaynor@agvax2.ag.ohio-state.edu> UNIX:<gaynor@magnus.acs.ohio-state.edu> Disclaimer : All opinions expressed here are mine and only mine. So there! Witty Quote: "Shoot him now! Shoot him now!" - Daffy Duck, "Rabbit Seasonings"
greg@pfloyd.lonestar.org (Greg Harp) (06/27/91)
In article <D2150025.izm3tm@brain.UUCP> chuck@brain.UUCP (Chuck Shotton) writes: >In article <43643@cup.portal.com>, morris-ng@cup.portal.com (Yuklung Morris Ng) writes: >> Oh, Amiga DOES NOT need a lot of desktop space compared to Mac, as we have >> screens, which a lot of Mac users still not quite understand... > >Well, that shows what a wonderfully intuitve box the Amiga is, doesn't it? ...or maybe it just says something about the typical Mac user. ;-) Seriously, I don't find the multiple screen capability of the Amiga in the least bit counterintuitive. I never had a problem grasping the concept... -- ----greg@pfloyd.lonestar.org---greg@pfloyd.UUCP---convex!egsner!pfloyd!greg---- "How I wish. How I wish you were here. We're just two lost souls swimming in a fishbowl year after year. Running over the same old ground. What have we found? The same old fears. Wish you were here." -- Pink Floyd
navas@cory.Berkeley.EDU (David C. Navas) (06/27/91)
In article <lron.5182@easy.lrcd.com> lron@easy.lrcd.com (Dwight Hubbard) writes: >Good explanation, but you happen to have any Idea why the damn menus are in >screen title bar instead of the title bar for the window were they belong?? Well, this is a safer topic than any other I seem to have picked up, so I'll offer a partial answer. :) Let's decide that we are going to put all menus in the window title, where they ostensibly belong. In fact, under the Amiga more so than on the Mac this is true. On the Mac you have a very standard menu set shared by all programs, so the menus are a bit more global. This is not true of the Amiga. At anyrate, let's discover what tradeoffs and problems we could run into. The first thing we might have to decide is whether to restrict the menu rendering to a particular window, or whether the menu should be drawn straight to the screen as is done currently. Benefits: (for clipping to window) Only that window will have it's graphic rendering halted, no other window would be affected, and other programs wouldn't appear to "freeze" It's more consistent with the idea that the menu belongs to the window. Problems: The window may not be large enough to display the menu. I personally would say that the Problem was larger than the Benefits, and so opt for screen-drawn menus. However, the list of problems doesn't stop there. What if the window title is not large enough to fit all the menu header items? Do we use the Motif/Windows trick of expanding the title area vertically? What if that is still not enough room? What happens to menus which, when rendered at the top of the screen, would have had enough room to fit themselves vertically, but don't when the window is at the very bottom of the screen? The list kinda goes on in the same vein from there. None of these are unsolvable, the question becomes "which is the best solution?" Which is the one that the human-computer interface folks will thrill over? The second half of the problem is that menu layout, gadget layout, etc. are processes which belong in the user interface's context, not in the application context. Unfortunately, not even gadtools provides this flexibility. Alas. The short answer to your question is that Cmdre does not spend enough money to either keep its employees (ie. commensurate compensation), or to hire enough employees to address these and other areas. Peter Cherna impresses me a great deal [something I don't say often], but he is only a single programmer.... >-Dwight Hubbard INTERNET: lron@easy.lrcd.com - >-Kaneohe, Hawaii USENET : ...!uunet!easy!lron - ^^^^^^^^^^^^^^^ Lucky guy. PS. By the by, I'd be willing to discuss this more vigorously via e-mail. I tried to keep it short, and left out a lot of examples, etc. Please mail me this posting, and I'll elaborate to whatever extent you'd like. :) David Navas navas@cory.berkeley.edu 2.0 :: "You can't have your cake and eat it too." Also try c186br@holden, c260-ay@ara and c184-ap@torus
rjc@geech.gnu.ai.mit.edu (Ray Cromwell) (06/27/91)
In article <1991Jun26.200208.25581@zardoz.eng.ohio-state.edu> gaynor@agvax2.ag.ohio-state.edu writes: >In article <1991Jun25.160016.10433@mintaka.lcs.mit.edu>, rjc@churchy.gnu.ai.mit.edu (Ray Cromwell) writes: >>In article <D2150025.izm3tm@brain.UUCP> chuck@brain.uucp writes: >>>In article <43643@cup.portal.com>, morris-ng@cup.portal.com (Yuklung Morris Ng) writes: >>>> >>>> Oh, Amiga DOES NOT need a lot of desktop space compared to Mac, as we have >>>> screens, which a lot of Mac users still not quite understand... >>> >>>Well, that shows what a wonderfully intuitve box the Amiga is, doesn't it? >> >> No, I think it show the kind of intelligence the average Mac >>user has, and the kind of people the machine is targeted at. :) > >[explanation of Amiga "screens" deleted...] > >Well, I won't argue Amiga vs. Mac. I have an SE/30, my fiancee has an A500. >I've been spending more time on the A500 for the past few days, since we bought >Lemmings over the weekend. 8-D (How does one make an insane smiley?) > >But I don't think that the "screens" are very intuitive. Once you figure them >out, they're great - it's nice to have three layered screens, 2 dedicated to >full-screen apps, and the other dedicated to WorkBench and some windowing apps. I guess if you're used to the Mac it might be less obvious, but what's to figure out? If you start up an App that opens its own screen and you want to get back to workbench you just press the front/back gadgets at the top of the screen to flip screens. The same thing happens with windows that open to the full size of the screeen. If you want to see what's behind them you click on the gadget to send the screen to the back. >However, the screens aren't quite obvious. Clicking on the menu bar with the >left button and dragging it down to show the screen behind just isn't one of >those things that come to you - especially when there is no visual indicator to >show that there -is- a screen behind. Perhaps, with some kind of notifier that >there is a layered screen, it could be more intuitive. You don't have to drag screens, you just click on the front/back gadgets just like windows. What's the visual indicator on the Mac if a window opens and takes up the whole screen? How do you know there's something behind it? Common sense of course. >As for the "intelligence" shot, well, it was smileyed, so I won't bother >spouting the old-time Mac Religion. Save us both, eh? Layered screens aren't any less intuition than layered windows. For all intents and purposes Screens can be thought of as large full screen windows with child windows inside them. >--- >Jim Gaynor - AgVAX System Manager - Academic Computing - Ohio State University >VMS:<gaynor@agvax2.ag.ohio-state.edu> UNIX:<gaynor@magnus.acs.ohio-state.edu> >Disclaimer : All opinions expressed here are mine and only mine. So there! >Witty Quote: "Shoot him now! Shoot him now!" - Daffy Duck, "Rabbit Seasonings" -- / INET:rjc@gnu.ai.mit.edu * // The opinions expressed here do not \ | INET:r_cromwe@upr2.clu.net | \X/ in any way reflect the views of my self.| \ UUCP:uunet!tnc!m0023 * /
peter@Sugar.NeoSoft.com (Peter da Silva) (06/27/91)
In article <1991Jun25.053133.671@neon.Stanford.EDU> torrie@cs.stanford.edu (Evan Torrie) writes: > Geez. I didn't think the CBM Pet, or the C-64 had multitasking. Guess > Commodore screwed up royally on those, huh? No argument from me. I'm an old Atari hand (and the Atari 800 operating system was in many ways superior to TOS and MS-DOS, though Apple's PRODOS was a bit nicer)... But they're not stuck with retaining compatibility with C=64s, like Apple is with the old Mac. Sometimes you need a revolution to make progress. Thomas Jefferson believed a nation should have a revolution at least every 70 years. Computers need more frequent housecleaning. -- Peter da Silva. `-_-' <peter@sugar.neosoft.com>. 'U` "Have you hugged your wolf today?"
espie@ibis.Stanford.EDU (Marc Espie) (06/27/91)
In article <1991Jun26.230459.19455@mintaka.lcs.mit.edu> rjc@geech.gnu.ai.mit.edu (Ray Cromwell) writes: [Lots of stuff edited to save bandwidth] > I guess if you're used to the Mac it might be less obvious, but what's to >figure out? If you start up an App that opens its own screen and you >want to get back to workbench you just press the front/back gadgets at >the top of the screen to flip screens. The same thing happens with windows >that open to the full size of the screeen. If you want to see what's behind >them you click on the gadget to send the screen to the back. > and in article <1991Jun26.200208.25581@zardoz.eng.ohio-state.edu> gaynor@agvax2.ag.ohio-state.edu writes: >>However, the screens aren't quite obvious. Clicking on the menu bar with the >>left button and dragging it down to show the screen behind just isn't one of >>those things that come to you-especially when there is no visual indicator to >>show that there -is- a screen behind. Perhaps, with some kind of notifier that >>there is a layered screen, it could be more intuitive. > > You don't have to drag screens, you just click on the front/back gadgets >just like windows. What's the visual indicator on the Mac if a window >opens and takes up the whole screen? How do you know there's something >behind it? Common sense of course. > >>As for the "intelligence" shot, well, it was smileyed, so I won't bother >>spouting the old-time Mac Religion. Save us both, eh? > > Layered screens aren't any less intuition than layered windows. >For all intents and purposes Screens can be thought of as large >full screen windows with child windows inside them. > >>--- >>Jim Gaynor - AgVAX System Manager - Academic Computing - Ohio State University >>VMS:<gaynor@agvax2.ag.ohio-state.edu> UNIX:<gaynor@magnus.acs.ohio-state.edu> >>Disclaimer : All opinions expressed here are mine and only mine. So there! >>Witty Quote: "Shoot him now! Shoot him now!" -Daffy Duck, "Rabbit Seasonings" > >/ INET:rjc@gnu.ai.mit.edu * // The opinions expressed here do not \ >| INET:r_cromwe@upr2.clu.net | \X/ in any way reflect the views of my self.| >\ UUCP:uunet!tnc!m0023 * / Well, actually, the 1.3 system of screens must have been a bit less than intuitive, because it got better. Under 2.0, you can flip through all screens with amiga-m. You can also drag a screen around without having to reach for the title bar (and you can also drag it in the horizontal direction... virtual screens can be much larger than the real screen, even the workbench.) You can also create new screens and declare them as public, so that you can have as many scratch areas as you wish. There are also some features for applications to actually share non standard screens (developper starting to slobber over his keyboard :-) ). This is getting more and more to match the ``sheets of paper'' paradigm, and since we can't push windows off the screen (we could use that), this helps A LOT in uncluttering your workspace. IMHO, this is even better in most cases. It takes me much less time to flip through several screens than to rearrange window positions/size/depth... to the point I regret that some programs cannot open their own screens. ---- Marc Espie (espie@flamingo.stanford.edu)
gblock@csd4.csd.uwm.edu (Gregory R Block) (06/27/91)
From article <1991Jun26.200208.25581@zardoz.eng.ohio-state.edu>, by gaynor@agvax2.ag.ohio-state.edu: > Lemmings over the weekend. 8-D (How does one make an insane smiley?) Perhaps a >-) is in order. :) >But I don't think that the "screens" are very intuitive. Once you figure them > out, they're great - it's nice to have three layered screens, 2 dedicated to >full-screen apps, and the other dedicated to WorkBench and some windowing apps I found them extremely intuitive, and well planned. I didn't find the two gadgets, screentofront & screentoback, real intuitive. Screentofront didn't seem real useful, and I always seemed to hit the wrong one. With 2.0, all there is is screentoback, I think, and it's great. Extremely intuitive. > However, the screens aren't quite obvious. Clicking on the menu bar with the > left button and dragging it down to show the screen behind just isn't one of >those things that come to you - especially when there is no visual indicator > show that there -is- a screen behind. Perhaps, with some kind of notifier > there is a layered screen, it could be more intuitive. I almost never really use dragged screens. I just pop thru with the button. It seemed awfully intuitive to me, and I started as a Mac fanatic (looking in retrospect, they were kind of dumb, but now they're almost half an amiga... :-) > As for the "intelligence" shot, well, it was smileyed, so I won't bother > spouting the old-time Mac Religion. Save us both, eh? Of course. :) If I had a bible for every comment, I'd be a brainwashed christian. :D And once again, it's a joke folks. BTW, some %*#!^% jacka$$ wrote me a note about that smiley'ed comment... I could have sworn that that's what the smiley was meant to avoid. Let's mellow out, folks. As always, Greg -- Socrates: "I drank WHAT????" LMFAP: "Next time you see me, it won't be me." Wubba: "A dream is nothing more than a wish dipped in chocolate and sprinkled with a little imagination." (From my poem, "A Dream") -Wubba
philip@pescadero.Stanford.EDU (Philip Machanick) (06/27/91)
In article <1991Jun27.005059.11450@neon.Stanford.EDU>, espie@ibis.Stanford.EDU (Marc Espie) writes: > and since we can't push windows off the screen (we could use that), > this helps A LOT in uncluttering > your workspace. IMHO, this is even better in most cases. It takes me much less > time to flip through several screens than to rearrange window > their own screens. For once, a Mac vs Amiga discussion is not turning into another silly "my computer is better than yours war". Other than the feature of being able to have different video attributes on each screen, is this really so much different from the Mac feature of being able to selectively hide applications (in System 7)? -- Philip Machanick philip@pescadero.stanford.edu
rjc@geech.gnu.ai.mit.edu (Ray Cromwell) (06/27/91)
In article <1991Jun27.033737.19606@neon.Stanford.EDU> philip@pescadero.stanford.edu writes: >In article <1991Jun27.005059.11450@neon.Stanford.EDU>, espie@ibis.Stanford.EDU (Marc Espie) writes: >> and since we can't push windows off the screen (we could use that), >> this helps A LOT in uncluttering >> your workspace. IMHO, this is even better in most cases. It takes me much less >> time to flip through several screens than to rearrange window >> their own screens. >For once, a Mac vs Amiga discussion is not turning into another >silly "my computer is better than yours war". Other than the >feature of being able to have different video attributes on >each screen, is this really so much different from the Mac >feature of being able to selectively hide applications (in >System 7)? I dunno because I don't know how the hide feature works on the Mac. On the Amiga, usually "hide" closes the current app screen/window and changes it into an icon or titlebar that can be clicked on or brought back via hotkey. Amiga Screens are not really hidden at all since one can drag down the current screen and see whats behind it (rendering may still be taking place). Sometimes when I am ray-tracing or generating something I put the screen in the back and pull down the front screen just enough to see how far the rendering has gone. In AmigaDOS2.0 screens can be dragged horizontally as well as vertically, so you can have very large virtual displays to scroll around it. The best thing I like about multiple screens is it gives me more desktop space and faster rendering. (when you have lots of windows open on the same screen switching between windows is slowed because of all the clipping being done.) When a Mac app is hidden, does it still run/render, and more importantly, how long does it take for it to reopen it's display? If it has to redraw everything, it may start to get annoying if you switch alot. >-- >Philip Machanick >philip@pescadero.stanford.edu -- / INET:rjc@gnu.ai.mit.edu * // The opinions expressed here do not \ | INET:r_cromwe@upr2.clu.net | \X/ in any way reflect the views of my self.| \ UUCP:uunet!tnc!m0023 * /
torrie@cs.stanford.edu (Evan Torrie) (06/27/91)
jbickers@templar.actrix.gen.nz (John Bickers) writes: > I've seen the format for what > appear to be standard Macintosh picture files, and it is flaky in > the extreme. > Some files have an extra piece of junk on the front, while others > don't (and in my program, I tell by checking if some particular > byte is an alphanumeric... there may be some better way, but it > wasn't apparent at the time). And the size of the picture is fixed. You're talking about MacPaint format pictures (I remember the same .MAC files on the local boards), which are simply B&W bitmaps with limited compression, produced by the 1984 MacPaint. The PICT format is much more general - see IM 5 for a good description. > The only nice thing was that they used the same compression scheme > that IFF ILBMs use. :) Actually, under QuickTime, PICTs can use JPEG compression, which is very nice for all those 24-bit files lying around. -- ------------------------------------------------------------------------------ Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu Murphy's Law of Intelism: Just when you thought Intel had done everything possible to pervert the course of computer architecture, they bring out the 860
mykes@amiga0.SF-Bay.ORG (Mike Schwartz) (06/27/91)
In article <1991Jun25.060849.1731@neon.Stanford.EDU> torrie@cs.stanford.edu (Evan Torrie) writes: >rjc@churchy.gnu.ai.mit.edu (Ray Cromwell) writes: > >> A good example of this is Apple's bubble-help system. What if Apple >>decided to somehow make bubble-help work on Apps that didn't support it >>(I have no idea how they would do this, perhaps they would review the >>manual information for every application ever written on the Mac >>and include it on the system 7 disk) Instead of this god-awful kludge, >>System 7 Apps have to upgrade to use this ability. > > Or, the local power user can add help balloons to old applications >without having to touch the application code, since help balloons >are simply resources. > This is the FIRST feature I turned off when I got system 7. It is so SLOOWWWW. And Apple wasted ROM space on it hahahaha. -- **************************************************** * I want games that look like Shadow of the Beast * * but play like Leisure Suit Larry. * ****************************************************
torrie@cs.stanford.edu (Evan Torrie) (06/27/91)
rjc@geech.gnu.ai.mit.edu (Ray Cromwell) writes: >In article <1991Jun27.033737.19606@neon.Stanford.EDU> philip@pescadero.stanford.edu writes: >>For once, a Mac vs Amiga discussion is not turning into another >>silly "my computer is better than yours war". Other than the >>feature of being able to have different video attributes on >>each screen, is this really so much different from the Mac >>feature of being able to selectively hide applications (in >>System 7)? > I dunno because I don't know how the hide feature works on the Mac. >On the Amiga, usually "hide" closes the current app screen/window >and changes it into an icon or titlebar that can be clicked on or >brought back via hotkey. Hide on the Mac removes all the application's windows from the screen, and dims the application's icon in the Application menu. You can choose to either Hide the current application, or Hide all others (most useful in the Finder to get at the desktop). You can also hide the current application as you switch to another by holding down the Option key. > When a Mac app is hidden, does it still run/render, Yes. >and more importantly, >how long does it take for it to reopen it's display? As long as it takes to respond to an update event. In the case of something like HyperCard, it's instantaneous. With a complicated model in AutoCad, it could take a while, unless the application saves away the current state of the screen on a Suspend event (as Switcher used to do). >If it has >to redraw everything, it may start to get annoying if you switch alot. Yes, in which case I use the 21" monitor, and have everything open at the same time. :-) -- ------------------------------------------------------------------------------ Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu "I didn't get where I am today without knowing a good deal when I see one, Reggie." "Yes, C.J."
jbickers@templar.actrix.gen.nz (John Bickers) (06/27/91)
Quoted from <1084@macuni.mqcc.mq.oz> by s8105119@ipc07.mqcs.mq.oz.au (Gary Kevin MAKIN): > This is very simple. The file type is *not* kept in the resource fork of a file. > It has never been kept there. The file type is in the file header. Proof: every What happens when you move the file to another sort of machine? > Gary Makin -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Endless variations, make it all seem new" - Devo. ***
jbickers@templar.actrix.gen.nz (John Bickers) (06/27/91)
Quoted from <1414@cbmger.UUCP> by peterk@cbmger.UUCP (Peter Kittel GERMANY): > In article <5353@dirac.physics.purdue.edu> sho@gibbs.physics.purdue.edu (Sho Kuwamoto) writes: > >all it would change on the mac is that the menubar would stop hogging > >screen real estate. I was hoping it'd take care of *some* of the > >shift-option-click business. Well, there is room for PD software. The screen blanker I use has "left-click-and-hold, right-click" for moving the current window (or screen) to the back. It also has "double-left-click" to bring the current window to the front (plus other user definable variations). Other software uses the "both-click" as an easily read trigger to stop some CPU intensive operation. This can be useful when priorities get out of hand, and straight Intuition input is put on hold by the priority problems. The text/graphics snapping program I use has "C= right-click" to paste (as well as a pure keyboard "C= S"). And both are user definable. -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Endless variations, make it all seem new" - Devo. ***
mykes@amiga0.SF-Bay.ORG (Mike Schwartz) (06/27/91)
In article <51197@ut-emx.uucp> awessels@ccwf.cc.utexas.edu (Allen Wessels) writes: >In article <25668@well.sf.ca.us> farren@well.sf.ca.us (Mike Farren) writes: > >>Yeah, so? You have to go through hoops to do so. I did the Amiga version >>of Crystal Quest, and one of the biggest pains in the butt of the entire >>conversion was pulling the data out of the resources and converting it >>into some usable format on the Ami. Just how many machines, pray tell, >>can handle PICT resources directly? > >How did you go about converting the PICTs? I just opened a PICT out of the >game Diamonds (I don't have Crystal Quest) with ResEdit, copy-and-pasted it >into PixelPaint Pro. To speed things up I'd use CanOpener to yank all the >PICTs out of Crystal Quest and then use something to convert the PICT files >to GIF, color TIFF or whatever. > I doubt that much of Crystal Quest's graphics were in PICT form ( a series of drawing commands ). It is much more likely that they are custom bitmap type resources. BTW, I ported Dark Castle and Beyond Dark Castle to the Amiga, and I agree that the biggest pain was in getting the resource data into Amiga form. -- **************************************************** * I want games that look like Shadow of the Beast * * but play like Leisure Suit Larry. * ****************************************************
lron@easy.lrcd.com (Dwight Hubbard) (06/27/91)
In article <matt.0301@vrtwo.UUCP> matt@vrtwo.UUCP (Matt Buford) writes: >About all this drag-and-drop stuff... On the Amiga you can just double click >on the document! Why drag it over to it's app? Just click twice on the >document and it knows which application created it... It does if it has an icon, it might not have an icon if you selected Show All from the Window menu on workbench so you can see those other files that maybe weren't created by an application that creates icons for you. -- ---------------------------------------------------------------------- -Dwight Hubbard INTERNET: lron@easy.lrcd.com - -Kaneohe, Hawaii USENET : ...!uunet!easy!lron - - BIX : lron - ----------------------------------------------------------------------
peter@Sugar.NeoSoft.com (Peter da Silva) (06/27/91)
In article <lron.5182@easy.lrcd.com> lron@easy.lrcd.com (Dwight Hubbard) writes: > Good explanation, but you happen to have any Idea why the damn menus are in > screen title bar instead of the title bar for the window were they belong?? Because they don't belong either place. They should remain invisible until selected with the menu button, and pop up under the mouse with the last selected option already active. In article <14300@pasteur.Berkeley.EDU> navas@cory.Berkeley.EDU writes: > Benefits: (for clipping to window) > Only that window will have it's graphic rendering halted, no other > window would be affected, and other programs wouldn't appear to > "freeze" That's not a benefit of putting the menus in the window title bar. That's a benefit of drawing the menus through layers.library. You could do that with the current menu sysyem as well. It'd just slow them down a bit. > Problems: > The window may not be large enough to display the menu. No problem, just use scrolling menus. I suspect it'd be possible to write a handler like PopUpMenu that'd do the job. Go for it. -- Peter da Silva. `-_-' <peter@sugar.neosoft.com>. 'U` "Have you hugged your wolf today?"
peter@Sugar.NeoSoft.com (Peter da Silva) (06/27/91)
In article <1991Jun27.033737.19606@neon.Stanford.EDU> philip@pescadero.stanford.edu writes: > feature of being able to have different video attributes on > each screen, is this really so much different from the Mac > feature of being able to selectively hide applications (in > System 7)? Yes. It's faster. A lot faster. Fast enough that even on a 7 MHz 68000 the time to swap screens is invisible to the user. On the Mac, even juggling apps is slow enough to drive me bats (at least on Mac-II and lower class machines) I can't imagine how it'd be like if the app had to repaint *all* its windows instead of just the ones that had been obscured. Until we have infinitely fast processors, faster implementations of an interface may in practice operate differently enough to be effectively a different interface. -- Peter da Silva. `-_-' <peter@sugar.neosoft.com>. 'U` "Have you hugged your wolf today?"
lron@easy.lrcd.com (Dwight Hubbard) (06/27/91)
In article <1991Jun27.115950.24857@Sugar.NeoSoft.com> peter@Sugar.NeoSoft.com (Peter da Silva) writes: >In article <lron.5182@easy.lrcd.com> lron@easy.lrcd.com (Dwight Hubbard) writes: >> Good explanation, but you happen to have any Idea why the damn menus are in >> screen title bar instead of the title bar for the window were they belong?? > >Because they don't belong either place. They should remain invisible until >selected with the menu button, and pop up under the mouse with the last >selected option already active. I don't know about you but I find that annoying. >In article <14300@pasteur.Berkeley.EDU> navas@cory.Berkeley.EDU writes: >> Benefits: (for clipping to window) >> Only that window will have it's graphic rendering halted, no other >> window would be affected, and other programs wouldn't appear to >> "freeze" > >That's not a benefit of putting the menus in the window title bar. That's a >benefit of drawing the menus through layers.library. You could do that with >the current menu sysyem as well. It'd just slow them down a bit. > >> Problems: >> The window may not be large enough to display the menu. > >No problem, just use scrolling menus. > >I suspect it'd be possible to write a handler like PopUpMenu that'd do >the job. Go for it. Know where I can get the source to PopUpMenu, I might see if I can find the time (before 1994 :-) -- ---------------------------------------------------------------------- -Dwight Hubbard INTERNET: lron@easy.lrcd.com - -Kaneohe, Hawaii USENET : ...!uunet!easy!lron - - BIX : lron - ----------------------------------------------------------------------
dant@ryptyde.UUCP (Daniel Tracy) (06/27/91)
Responding to the following: "Oh, Amiga DOES NOT need a lot of desktop space compared to Mac, as we have screens, which a lot of Mac users still not quite understand..." Give me a break. On my dinky 9" screen (Mac SE) I have a Virtual 2-page display. The screen scrolls automatically according to the active window, WP cursor position, or mouse cursor. I can tell it to take a section of it and enlarge it 3x, take another part of the virtual screen and reduce it to 75%. And despite this, I can STILL use what I see (press button, switch windows, etc) normally.
gaynor@agvax2.ag.ohio-state.edu (06/27/91)
In article <1991Jun27.033737.19606@neon.Stanford.EDU>, philip@pescadero.Stanford.EDU (Philip Machanick) writes: >In article <1991Jun27.005059.11450@neon.Stanford.EDU>, espie@ibis.Stanford.EDU (Marc Espie) writes: >> and since we can't push windows off the screen (we could use that), >> this helps A LOT in uncluttering >> your workspace. IMHO, this is even better in most cases. It takes me much less >> time to flip through several screens than to rearrange window >> their own screens. >For once, a Mac vs Amiga discussion is not turning into another >silly "my computer is better than yours war". Other than the >feature of being able to have different video attributes on >each screen, is this really so much different from the Mac >feature of being able to selectively hide applications (in >System 7)? Great, isn't it? The fanatics on both the Amiga and the Mac side have managed to keep from foaming at the mouth. <grin> Actually, Philip, it's quite different. Imagine your standard 640 x 480 Macintosh screen. Now, add another button to the mouse that is attached to the Mac that is attached to the screen in your imagination. <grin> By clicking with this new button on a gadget at the far right of the menubar (looks like 2 sheets of paper, one half-covering the other), you get a whole new screen. And if you click-and-drag the menubar with that new button, the screen slides away to expose part of the other screen. Programs can take up an entire screen for themselves, or they can just run in a window. Admittedly, you get the same "functionality" of screen-flipping with the Hide feature in System 7. But the multiple virtual screens provide more apparent room. It's hard to quantify, but it is my opinion (as someone who's used both Macs and Amigas) that being able to flip or drag "virtual" screens is more useful than app hiding. I mean, let's be honest here. I know -I'd- rather have more screen space - virtual -or- real. Hey, to the folks who were talking about AmigaDOS 2.0 - is that thing out of beta yet? I saw a beta about a year ago, and was -very- impressed. It was supposed to out RSN back then... :-( --- Jim Gaynor - AgVAX System Manager - Academic Computing - Ohio State University VMS:<gaynor@agvax2.ag.ohio-state.edu> UNIX:<gaynor@magnus.acs.ohio-state.edu> Disclaimer : All opinions expressed here are mine and only mine. So there! Witty Quote: "Shoot him now! Shoot him now!" - Daffy Duck, "Rabbit Seasonings"
gaynor@agvax2.ag.ohio-state.edu (06/27/91)
In article <1991Jun27.041627.29718@mintaka.lcs.mit.edu>, rjc@geech.gnu.ai.mit.edu (Ray Cromwell) writes: > > I dunno because I don't know how the hide feature works on the Mac. >On the Amiga, usually "hide" closes the current app screen/window >and changes it into an icon or titlebar that can be clicked on or >brought back via hotkey. Same thing on the Mac, essentially. "Hide" will remove all the app's windows and gadgets, but there will still be an entry on the System Menu. (The System Menu is a pull-down menu on the far right of the menubar that lists all active apps, and contains the hide/restore commands). Also, the icon that represents the application will still be "grayed". (Mac apps aren't re-entrant, so a running app will have its icon dimmed). By double-clicking the program icon, or by selecting the app name from the System Menu, the app will come back. > When a Mac app is hidden, does it still run/render, and more importantly, >how long does it take for it to reopen it's display? If it has >to redraw everything, it may start to get annoying if you switch alot. Hmmm... I haven't really tested that. I'll have to try it tonight when I run my Navigator session - see if everything still bops along when hidden. But it does have to redraw. :-( That's one of the reasons why I said in a previous post that multiple "virtual" screens on the Amiga are more useful that app-hiding on the Mac. Neither app-hiding nor "virtual" screens can touch having real multiple monitors, though. :-) (Sure, and I've got a Mac IIfx and Amiga 3000/25 at home... <sigh>) --- Jim Gaynor - AgVAX System Manager - Academic Computing - Ohio State University VMS:<gaynor@agvax2.ag.ohio-state.edu> UNIX:<gaynor@magnus.acs.ohio-state.edu> Disclaimer : All opinions expressed here are mine and only mine. So there! Witty Quote: "Shoot him now! Shoot him now!" - Daffy Duck, "Rabbit Seasonings"
jcav@quads.uchicago.edu (john cavallino) (06/27/91)
In article <1991Jun27.155751.28356@zardoz.eng.ohio-state.edu> gaynor@agvax2.ag.ohio-state.edu writes: >Same thing on the Mac, essentially. "Hide" will remove all the app's >windows and gadgets, but there will still be an entry on the System >Menu. (The System Menu is a pull-down menu on the far right of the >menubar that lists all active apps, and contains the hide/restore >commands). Also, the icon that represents the application will still >be "grayed". (Mac apps aren't re-entrant, so a running app will have >its icon dimmed). ^^^^^^ ^^^^^^^^^^ ?????? The grayed icon is purely user-interface feedback, to let you know that the application is running but hidden. It hasn't anything at all to do with re-entrancy. -- John Cavallino | EMail: jcav@midway.uchicago.edu University of Chicago Hospitals | USMail: 5841 S. Maryland Ave, Box 145 Office of Facilities Management | Chicago, IL 60637 B0 f++ c+ g+ k s+(+) e+ h- pv (qv) | Telephone: 312-702-6900
chucks@pnet51.orb.mn.org (Erik Funkenbusch) (06/28/91)
lron@easy.lrcd.com (Dwight Hubbard) writes: >In article <1991Jun24.094738.29131@Sugar.NeoSoft.com> peter@Sugar.NeoSoft.com (Peter da Silva) writes: > >>Basically, it reduces screen clutter and user actions, and speeds up multiple >>selections. > >Good explanation, but you happen to have any Idea why the damn menus are in >screen title bar instead of the title bar for the window were they belong?? Becuase windows are frequenty smaller than the size of a screen, and Menu's are frequently the full width of the screen. i don't know about you, but if i resize a window to a smaller size, i don't want to have to resize it larger just to get to a menu. I *LIKE* them in the screen title bar. .--------------------------------------------------------------------------. | UUCP: {amdahl!tcnet, crash}!orbit!pnet51!chucks | "I know he's come back | | ARPA: crash!orbit!pnet51!chucks@nosc.mil | from the dead, but do | | INET: chucks@pnet51.orb.mn.org | you really think he's | |-------------------------------------------------| moved back in?" | | Amiga programmer at large, employment options | Lou Diamond Philips in | | welcome, inquire within. | "The First Power". | `--------------------------------------------------------------------------'
gaynor@agvax2.ag.ohio-state.edu (06/28/91)
In article <127@ryptyde.UUCP>, dant@ryptyde.UUCP (Daniel Tracy) writes: >Responding to the following: > >"Oh, Amiga DOES NOT need a lot of desktop space compared to Mac, as we have >screens, which a lot of Mac users still not quite understand..." > >Give me a break. On my dinky 9" screen (Mac SE) I have a Virtual 2-page >display. The screen scrolls automatically according to the active window, >WP cursor position, or mouse cursor. But "Joe MacUser" doesn't have this. Your virtual 2-page monitor requires a third-party extension to the Macintosh System Software, whereas the multiple virtual screens of the Amiga are part of the OS. Please, this has been a great thread thus far - this is the first semi-imflammatory response thus far (that wasn't smileyed). Let's keep it that way, not turn it into a "oh yeah?" "sez you!" thread... --- Jim Gaynor - AgVAX System Manager - Academic Computing - Ohio State University VMS:<gaynor@agvax2.ag.ohio-state.edu> UNIX:<gaynor@magnus.acs.ohio-state.edu> Disclaimer : All opinions expressed here are mine and only mine. So there! Witty Quote: "Shoot him now! Shoot him now!" - Daffy Duck, "Rabbit Seasonings"
gaynor@agvax2.ag.ohio-state.edu (06/28/91)
In article <mykes.3812@amiga0.SF-Bay.ORG>, mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: >In article <1991Jun25.060849.1731@neon.Stanford.EDU> torrie@cs.stanford.edu (Evan Torrie) writes: >>rjc@churchy.gnu.ai.mit.edu (Ray Cromwell) writes: >>> A good example of this is Apple's bubble-help system. [...] >> >> Or, the local power user can add help balloons to old applications >>without having to touch the application code, since help balloons >>are simply resources. > >This is the FIRST feature I turned off when I got system 7. It is so >SLOOWWWW. And Apple wasted ROM space on it hahahaha. No, Apple did not "waste" ROM space on it. (As of yet, System 7 isn't part of the Apple ROMs) Balloon Help is useful when you're poking about an application - y'know, the usual exploring-without-opening-the-docs, or when you look at something and say to yourself, "What the heck is that?" Just point at the thing, and your Mac tells you what it is. It's great for first time users, too. For an experienced user in an evironment they're familiar with, it's useless. That's why you can turn it -off-. Most of the RTFM-type questions that have been asked about System 7 in the c.s.m.* groups were easily answerable with Balloon Help. And they were asked by folks who, just like you, turned it off as the very first thing. --- Jim Gaynor - AgVAX System Manager - Academic Computing - Ohio State University VMS:<gaynor@agvax2.ag.ohio-state.edu> UNIX:<gaynor@magnus.acs.ohio-state.edu> Disclaimer : All opinions expressed here are mine and only mine. So there! Witty Quote: "Shoot him now! Shoot him now!" - Daffy Duck, "Rabbit Seasonings"
gaynor@agvax2.ag.ohio-state.edu (06/28/91)
In article <1991Jun27.161530.14821@midway.uchicago.edu>, jcav@quads.uchicago.edu (john cavallino) writes: >?????? The grayed icon is purely user-interface feedback, to let you know >that the application is running but hidden. It hasn't anything at all to >do with re-entrancy. Correct, to an extent. The grayed icon is to show that the program is running (whether or not the app is hidden makes no difference). And you're right, the grayed icon doesn't have anything to directly do with re-entrancy. It's visual feedback, to show the user that the program is already running and that (here's the kicker) -because- it's already running, you can't run it again. Get it? It's visual feedback that the program can't be run, -because it's already running-. On the Amiga WorkBench or in MS Windows, the icon of a running app undergoes no change. Why? Because apps are re-entrant there. I can have the same application running two or three time if I like. Dumb Personal Experience: the time I forgot I was in a Windows DOS shell and re-ran Windows. Couldn't for the life of me figure out why it was so much slower than normal till I quit the second session of Windows to discover I still had another session. Oops... --- Jim Gaynor - AgVAX System Manager - Academic Computing - Ohio State University VMS:<gaynor@agvax2.ag.ohio-state.edu> UNIX:<gaynor@magnus.acs.ohio-state.edu> Disclaimer : All opinions expressed here are mine and only mine. So there! Witty Quote: "Shoot him now! Shoot him now!" - Daffy Duck, "Rabbit Seasonings"
rjc@geech.gnu.ai.mit.edu (Ray Cromwell) (06/28/91)
In article <1991Jun27.073542.442@neon.Stanford.EDU> torrie@cs.stanford.edu (Evan Torrie) writes: >rjc@geech.gnu.ai.mit.edu (Ray Cromwell) writes: > >>If it has >>to redraw everything, it may start to get annoying if you switch alot. > > Yes, in which case I use the 21" monitor, and have everything open at >the same time. :-) That's nice, if you can afford it, but I find it still doesn't solve the problem. No matter how big the screen is, I like to have shell windows/ text editors/comm programs open up to full size. This cuts down on scrolling and allows me to see more of what I am editing at once. That's why I like having a full screen shell on one screen, and a full screen comm program on another (like I have now) I can switch quickly between them with one keypress or via the mouse (pressing the left and right buttons at the same time). No matter how much you give a user, he will find a way to use it up, and want more. (This applies to ram, cpu power, screen real estate, etc) Windows help maximize screen real estate but too many on one screen starts to slow switching between them down. Screens don't have this problem. >-- >------------------------------------------------------------------------------ >Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu >"I didn't get where I am today without knowing a good deal when I see one, > Reggie." "Yes, C.J." -- / INET:rjc@gnu.ai.mit.edu * // The opinions expressed here do not \ | INET:r_cromwe@upr2.clu.net | \X/ in any way reflect the views of my self.| \ UUCP:uunet!tnc!m0023 * /
jcav@quads.uchicago.edu (john cavallino) (06/28/91)
In article <1991Jun27.195750.29163@zardoz.eng.ohio-state.edu> gaynor@agvax2.ag.ohio-state.edu writes: >In article <1991Jun27.161530.14821@midway.uchicago.edu>, jcav@quads.uchicago.edu (john cavallino) writes: >>?????? The grayed icon is purely user-interface feedback, to let you know >>that the application is running but hidden. It hasn't anything at all to >>do with re-entrancy. > >Correct, to an extent. The grayed icon is to show that the program is >running (whether or not the app is hidden makes no difference). But...it's not gray unless the application is hidden. >And you're right, the grayed icon doesn't have anything to directly do >with re-entrancy. It's visual feedback, to show the user that the >program is already running and that (here's the kicker) -because- it's >already running, you can't run it again. > >Get it? It's visual feedback that the program can't be run, -because >it's already running-. Ohhhh... I get it. You're referring to the icon of an active application, as displayed on the Finder desktop. I thought we were talking about the icon in the System 7 Application menu. Picked Nit: the Mac User-Interface Term for what you're referring to is a "hollow" icon, not a "grayed" icon. >On the Amiga WorkBench or in MS Windows, the icon of a running app >undergoes no change. Why? Because apps are re-entrant there. I can >have the same application running two or three time if I like. The problem on the Mac is that the OS Resource Manager is not re-entrant. Many apps are in fact multi-launchable, but they have to reside on a shared file-server and be launched on different Macs. :-( -- John Cavallino | EMail: jcav@midway.uchicago.edu University of Chicago Hospitals | USMail: 5841 S. Maryland Ave, Box 145 Office of Facilities Management | Chicago, IL 60637 B0 f++ c+ g+ k s+(+) e+ h- pv (qv) | Telephone: 312-702-6900
rjc@geech.gnu.ai.mit.edu (Ray Cromwell) (06/28/91)
In article <1991Jun27.161530.14821@midway.uchicago.edu> jcav@quads.uchicago.edu (john cavallino) writes: >In article <1991Jun27.155751.28356@zardoz.eng.ohio-state.edu> gaynor@agvax2.ag.ohio-state.edu writes: >>Same thing on the Mac, essentially. "Hide" will remove all the app's >>windows and gadgets, but there will still be an entry on the System >>Menu. (The System Menu is a pull-down menu on the far right of the >>menubar that lists all active apps, and contains the hide/restore >>commands). Also, the icon that represents the application will still >>be "grayed". (Mac apps aren't re-entrant, so a running app will have >>its icon dimmed). ^^^^^^ ^^^^^^^^^^ > >?????? The grayed icon is purely user-interface feedback, to let you know >that the application is running but hidden. It hasn't anything at all to >do with re-entrancy. But does the Mac have "pure" applications and support for them at all? I find this to be a major multitasking feature, as I can run multiple copies of a 200-500k App without using extra memory. The same code and data space is used, so the only extra memory that the other running copies take up is their stack, screen memory, and global/static data(which has to be copied and initialized on startup.) Resident applications/code also runs _very_ fast. There is no delay between running and startup. Its faster than loading from harddisk or ramdisk since no loading/filesystem routines are called. Resident/ sharable code is one of the reasons the Amiga, even the 512k Amiga, can run lots of programs at once or multiple copies of programs. >-- >John Cavallino | EMail: jcav@midway.uchicago.edu >University of Chicago Hospitals | USMail: 5841 S. Maryland Ave, Box 145 >Office of Facilities Management | Chicago, IL 60637 >B0 f++ c+ g+ k s+(+) e+ h- pv (qv) | Telephone: 312-702-6900 -- / INET:rjc@gnu.ai.mit.edu * // The opinions expressed here do not \ | INET:r_cromwe@upr2.clu.net | \X/ in any way reflect the views of my self.| \ UUCP:uunet!tnc!m0023 * /
slau@slau.lrcd.com (Stephen Lau) (06/28/91)
In article <14300@pasteur.Berkeley.EDU> navas@cory.Berkeley.EDU (David C. Navas) writes: >In article <lron.5182@easy.lrcd.com> lron@easy.lrcd.com (Dwight Hubbard) writes: >Well, this is a safer topic than any other I seem to have picked up, so >I'll offer a partial answer. :) That's what I think :) > > Benefits: (for clipping to window) > Only that window will have it's graphic rendering halted, no other > window would be affected, and other programs wouldn't appear to > "freeze" > > It's more consistent with the idea that the menu belongs to the window. > > Problems: > The window may not be large enough to display the menu. What about using popup menus?? You don't have to go to the top to select functions, and you don't have to worry about the window not large enough to display the menu. > >>-Dwight Hubbard INTERNET: lron@easy.lrcd.com - >>-Kaneohe, Hawaii USENET : ...!uunet!easy!lron - > ^^^^^^^^^^^^^^^ Lucky guy. ^^^^^^^^^^ Are you kidding?? Have you try buying some stuff in Hawaii?? :) -- ============================================================================ To err is human, to really screw things up, you need a MS-DOS machine. *--------------------------------------------------------------------------* |Stephen Lau UseNet: uunet!easy!slau!slau | |Honolulu, Hawaii Compuserve: 72557,3652 | | GEnie: C.LAU1 | | Plink: Amiganoid | | Internet: lauch@wiliki.eng.hawaii.edu | *--------------------------------------------------------------------------*
navas@cory.Berkeley.EDU (David C. Navas) (06/28/91)
In article <1991Jun27.115950.24857@Sugar.NeoSoft.com> peter@Sugar.NeoSoft.com (Peter da Silva) writes: >In article <lron.5182@easy.lrcd.com> lron@easy.lrcd.com (Dwight Hubbard) writes: >> Good explanation, but you happen to have any Idea why the damn menus are in >> screen title bar instead of the title bar for the window were they belong?? > >Because they don't belong either place. They should remain invisible until >selected with the menu button, and pop up under the mouse with the last >selected option already active. Weeell. That's one opinion of course. For the beginner user (which neither of us are) there really isn't enough visual clueing as to whether menus exist or not. Witness, if you will, poor Joe user confused the first time he fires up dpaint and hits his right mouse button. >That's not a benefit of putting the menus in the window title bar. That's a >benefit of drawing the menus through layers.library. You could do that with >the current menu sysyem as well. It'd just slow them down a bit. Well, except that in the case of rendering them to the screen a layer needs to be created. Question: do you create a layer for each menu-item list, or one to hold the whole bunch?, etc. In a window, the layer already exists. But... >> Problems: >> The window may not be large enough to display the menu. >No problem, just use scrolling menus. Bzzzt. :) What if the window isn't *wide* enough? You won't be able to read the text. Scrolling isn't a bad idea, though, for the vertical problem. >I suspect it'd be possible to write a handler like PopUpMenu that'd do >the job. Go for it. Sorry, I'm busy with something else right now. :) Also, there are some serious intuition-type conflicts that I'm not convinced PopUpMenu has solved. The menu system on the Amiga sucks. I think the folks at Cmdre know that, its a matter of allocation of resources. Certainly it seemed to be one of jimm's laments, although I think he seemed to be dreading attacking the problem. :) [Intuition's state machine was already broken....] David Navas navas@cory.berkeley.edu 2.0 :: "You can't have your cake and eat it too." Also try c186br@holden, c260-ay@ara and c184-ap@torus
tappek@infonode.ingr.com (J. Kurt Tappe) (06/28/91)
>Well, that shows what a wonderfully intuitive box the Amiga is... Foul!! Come on... Whatever you might think of the Amiga, windows are a VERY easy concept of the Amiga GUI to understand. Easier, in my opinion, than Multifinder/System 7.0. (and, before you assume I'm a Mac neophyte, I use both Amiga and Mac *heavily*) Thanks for no more wisecracks. Kurt -- From daemon Tue Jun 25 21:07 CDT 1991 >From JKT100%PSUVM.PSU.EDU Tue Jun 25 21:06:55 1991 remote from infonode Return-Path: <JKT100@PSUVM.PSU.EDU> Received: from [128.118.56.2] by infonode.ingr.com (5.61/1.910401)
tappek@infonode.ingr.com (J. Kurt Tappe) (06/28/91)
philip@pescadero.Stanford.EDU (Philip Machanick) writes: >In article <1991Jun27.005059.11450@neon.Stanford.EDU>, espie@ibis.Stanford.EDU (Marc Espie) writes: >> and since we can't push windows off the screen (we could use that), >> this helps A LOT in uncluttering >> your workspace. IMHO, this is even better in most cases. It takes me much less >> time to flip through several screens than to rearrange window >> their own screens. >For once, a Mac vs Amiga discussion is not turning into another >silly "my computer is better than yours war". Amen. And I think it's agreed on both sides that we're missing indicators to tell the user that there are screens or windows behind the ones we are viewing. I'd love to see this on BOTH the Amiga and Mac. On the mac, I often have large windows that completely cover small ones, and I hate to move them to get at the ones underneath because the Desktop saves the new position unless I put them back! On the Amiga, I often have 4-6 screens open at once, and there is no quick way to jump directly to a certain one without flipping thru all the others. Mods to both systems needed! :-) Kurt -- From daemon Tue Jun 25 21:07 CDT 1991 >From JKT100%PSUVM.PSU.EDU Tue Jun 25 21:06:55 1991 remote from infonode Return-Path: <JKT100@PSUVM.PSU.EDU> Received: from [128.118.56.2] by infonode.ingr.com (5.61/1.910401)
tagreen@lothario.ucs.indiana.edu (Todd Green) (06/28/91)
>>?????? The grayed icon is purely user-interface feedback, to let you know >>that the application is running but hidden. It hasn't anything at all to >>do with re-entrancy. > >Correct, to an extent. The grayed icon is to show that the program is >running (whether or not the app is hidden makes no difference). I believe you are talking about two different icons. The original poster is refering to the sicn (ics?) that gets grayed when you hide an application and not the icon (icl?) itself. Which _does_ have alot to due with whether or not the app is hidden (but still running). Also in reference to an earlier post there is no need on the Mac to continually "peek" at the application to see if it's finished rendering or doing whatever. There is a thing called the notification manager which most/some programmers take advantage of that can flash a small icon (or a sound or an alert box) notifying you that some process was completed. An excellent example of this is Mandlezot by Dave Platt. Of course that still doesn't stop me from checking on the progress from time to time if I'm bored ;). Todd -- Internet: tagreen@bronze.ucs.indiana.edu NeXTMail: tagreen@lothario.ucs.indiana.edu BitNet: tagreen@iubacs.bitnet
lsr@Apple.COM (Larry Rosenstein) (06/28/91)
In article <25668@well.sf.ca.us> farren@well.sf.ca.us (Mike Farren) writes: > >Where is it kept, then? Last time *I* looked, file types were definitely >resources, and thus *had* to be in the resource fork. Has this changed File types are (have always been) a property of the file, just like it's modification date. -- Larry Rosenstein, Apple Computer, Inc. lsr@apple.com (or AppleLink: Rosenstein1)
rjc@geech.gnu.ai.mit.edu (Ray Cromwell) (06/28/91)
In article <1991Jun27.232602.22983@bronze.ucs.indiana.edu> tagreen@lothario.ucs.indiana.edu (Todd Green) writes: > >>>?????? The grayed icon is purely user-interface feedback, to let you know >>>that the application is running but hidden. It hasn't anything at all to >>>do with re-entrancy. >> >>Correct, to an extent. The grayed icon is to show that the program is >>running (whether or not the app is hidden makes no difference). > >I believe you are talking about two different icons. The original >poster is refering to the sicn (ics?) that gets grayed when you hide >an application and not the icon (icl?) itself. Which _does_ have alot >to due with whether or not the app is hidden (but still running). > >Also in reference to an earlier post there is no need on the Mac to >continually "peek" at the application to see if it's finished >rendering or doing whatever. There is a thing called the notification >manager which most/some programmers take advantage of that can flash a >small icon (or a sound or an alert box) notifying you that some >process was completed. An excellent example of this is Mandlezot by >Dave Platt. Of course that still doesn't stop me from checking on the >progress from time to time if I'm bored ;). This is sort of like the Amiga's DisplayBeep() function which flashes all screens. I think it's more attention getting than the Mac's flashing icon, but the flashing icon idea sounds cooler. The problem is, what if you've ran things from a shell instead of from the GUI/Workbench? There won't be an icon to flash. Oh well, we can always used the animated pointer trick. (DisplayBeep() is very annoying, it's meant that way to get your attention. It flashes the entire screen (on my screen colors) yellow/bright white for a period of atleast a second. DisplayBeep can be patched to use a sample (like a beep, siren, etc) >Todd > >-- >Internet: tagreen@bronze.ucs.indiana.edu >NeXTMail: tagreen@lothario.ucs.indiana.edu >BitNet: tagreen@iubacs.bitnet -- / INET:rjc@gnu.ai.mit.edu * // The opinions expressed here do not \ | INET:r_cromwe@upr2.clu.net | \X/ in any way reflect the views of my self.| \ UUCP:uunet!tnc!m0023 * /
jcav@quads.uchicago.edu (john cavallino) (06/28/91)
In article <1991Jun27.235411.16654@mintaka.lcs.mit.edu> rjc@geech.gnu.ai.mit.edu (Ray Cromwell) writes: >In article <1991Jun27.232602.22983@bronze.ucs.indiana.edu> tagreen@lothario.ucs.indiana.edu (Todd Green) writes: >>Also in reference to an earlier post there is no need on the Mac to >>continually "peek" at the application to see if it's finished >>rendering or doing whatever. There is a thing called the notification >>manager which most/some programmers take advantage of that can flash a >>small icon (or a sound or an alert box) notifying you that some >>process was completed. An excellent example of this is Mandlezot by >>Dave Platt. Of course that still doesn't stop me from checking on the >>progress from time to time if I'm bored ;). > > This is sort of like the Amiga's DisplayBeep() function which flashes >all screens. I think it's more attention getting than the Mac's >flashing icon, but the flashing icon idea sounds cooler. The problem is, >what if you've ran things from a shell instead of from the GUI/Workbench? >There won't be an icon to flash. Oh well, we can always used the >animated pointer trick. > > >(DisplayBeep() is very annoying, it's meant that way to get your >attention. It flashes the entire screen (on my screen colors) yellow/bright >white for a period of atleast a second. DisplayBeep can be patched to >use a sample (like a beep, siren, etc) The Mac Notification Manager can optionally, in addition to flashing the icon, play an arbitarary sound and/or display an alert box. It also puts a little diamond next to the entry in the Application menu of the process that wants your attention, so you know where to go to respond. -- John Cavallino | EMail: jcav@midway.uchicago.edu University of Chicago Hospitals | USMail: 5841 S. Maryland Ave, Box 145 Office of Facilities Management | Chicago, IL 60637 B0 f++ c+ g+ k s+(+) e+ h- pv (qv) | Telephone: 312-702-6900
lsr@Apple.COM (Larry Rosenstein) (06/28/91)
In article <1991Jun21.181522.26401@sequent.com> cseaman@sequent.com writes: > >This topic epitomizes my main beef with the Mac 'philosophy'. Any user >with a lick of common sense isn't even going to TRY to 'drag-and-drop' a >file into an application, unless they believe (or at least suspect) that >the application will know what to do with it. The 'Mac way', however, >credits the user with the intelligence of a rock. It not only condones >ignorance on the part of the user, it encourages and perpetuates it. You're right that this is a philosophical decision. But your wrong as to the reason for it. The reason is not because we don't give the user any credit for intelligence. The reason is that most users shouldn't have to worry about document types and what applications can handle what types. The system should do that. There's no point in having a word processor open a graphics document. At best it will put up a message saying it can't open the document; at worst it will display garbage. >'Drag and drop in the Finder allows the user to avoid the step of >launching an application...' Pshaw. 'Drag-and-drop' in the Finder Drag and drop allows the user to override the built-in mechanism for selecting a application to open a given document. It also opens the way for small desktop utilities. In a limited way, it allows 3rd parties to add capabilities to the Finder. You make the mistake of thinking that all users have your understanding of what goes on inside a computer. There are a lot of highly intelligent people who happen not to have CS degrees. -- Larry Rosenstein, Apple Computer, Inc. lsr@apple.com (or AppleLink: Rosenstein1)
kdarling@hobbes.catt.ncsu.edu (Kevin Darling) (06/28/91)
rjc@geech.gnu.ai.mit.edu (Ray Cromwell) writes: > But does the Mac have "pure" applications and support for them at all? > I find this to be a major multitasking feature, as I can run > multiple copies of a 200-500k App without using extra memory. [Sidenote: Kev's Rule #2 which everyone breaks -- use common terminology for features, not funky CBM/Mac names!! Eg: use "reentrant", not "pure".] Ray: Well, yeah, I mean yeah... but it took _years_ before we started seeing very many reentrant/resident apps on the Amiga. It sure wasn't common at first! True story: about two dozen CoCo/OS9 owners trooped down to see the A1000 when it hit our town. We thought the Ami graphics were awesome, of course. We were all dying to buy one right then and there. UNTIL we tried to bring up another incarnation of the editor, and it didn't have enough room to LOAD another copy. "What!??" we all yelled, "You mean there's a 68000 in there and the bozos didn't even write reentrant code for it??!" That was enough to convince us all that the Amiga was really a C64 in disguise :-) So because of that bogosity, and the MSDOS-ish pathnames, we all left the store. No sales to us then. For that matter, it wasn't too long ago that even _suggesting_ that Amiga programmers write reentrant code, was a surefire flame topic on most nets. "Why?" they'd ask. "Who needs to run more than one copy of each program at one time?" Arrgh. In other words, Amiga history itself is awful weak to be dumping on the (was singletasking) Mac for not using reentrant code. Give the Mac a few more years of multitasking; then you can rag them :-). cheers - kev <kdarling@catt.ncsu.edu> PS: if anyone's interested, Rule #1 is: don't use Amiga part numbers in discussions with other machine owners, unless you explain what they are! (example: "Well, my Amiga has an A2091".) Confuses the whole net.
mikeh@touch.touch.com (Mike Haas) (06/28/91)
In article <102@ryptyde.UUCP> dant@ryptyde.UUCP (Daniel Tracy) writes: >talking about interchange formats, documents. The interchange format docs >on the Macintosh don't NEED a resource fork and couldn't care less if they >had one! Our bitmap, drawing, text, formatted text, movie, sound, etc. >don't need resources, although they can be transfered into one (some of >them). You can just as easily use them on other machines. So what is >the interchange advantage of the Amiga? Wrong. Almost all mac software incessantly uses resources. Formatting for text (fonts, bitmaps, etc) are in FONT resources, graphic bitmaps in PICT resources, programs in CODE resources, on and on and on. You only get to save something without resources if the specific application allows you to save in special formats. Usually, you are then rendered incompatible with other mac stuff. So, mac files CAN SOMETIMES be used on other platforms and RTF-formatted WP documents are a good example of this. But in the standard dual-fork format, you play hell getting these sent to another platform for use. there are currently 3 standards in use for "serializing" the dual-forks Macbinary, Macbinary II, and Applesingle (apple's 'offishul' standard). My company, which provides x.400 mail service to the OSI community is experiencing problems with the existance of multiple "standards". Even if we support all 3 (whew!...the work!), we can't know what format a particular recipient's software will support! Believe me, the dual-fork mac format causes MANY MANY interoperability problems. Most revolve around the fact that the 2 forks have to be combined into one entity to transmit over a given medium. This is fine as long as things stay proprietary (like appletalk), but the very second you mention "interoperability" or "open systems" you're hosed! Since PC, UNIX, AMIGA etc. files are already just single entities, this is not a problem. Just ship it to the other machine. The foriegn software just has to interpret the data that's there...it doesn't have to figure out how to "decode" it.
rjc@geech.gnu.ai.mit.edu (Ray Cromwell) (06/28/91)
In article <1991Jun28.015423.21346@ncsu.edu> kdarling@hobbes.catt.ncsu.edu (Kevin Darling) writes: >rjc@geech.gnu.ai.mit.edu (Ray Cromwell) writes: >> But does the Mac have "pure" applications and support for them at all? >> I find this to be a major multitasking feature, as I can run >> multiple copies of a 200-500k App without using extra memory. > >[Sidenote: Kev's Rule #2 which everyone breaks -- use common terminology >for features, not funky CBM/Mac names!! Eg: use "reentrant", not "pure".] > >Ray: Well, yeah, I mean yeah... but it took _years_ before we started >seeing very many reentrant/resident apps on the Amiga. It sure wasn't >common at first! ARP Ares and the arp commands have existed for a long time now. (3 years?) Almost all the Matt Dillon stuff has/is always reentrant. For about, what 2 years? Lattice has been able to produce reentrant code. AmigaDOS 1.3 Copyright 1988 contained the resident command and the pure bit. I'd say resident commands have been around for awhile, I sure have been using them for a long time. Not to mention all AmigaDOS libraries and devices are pure, which cuts down on executable size and the need for link libraries. [Story of Coco OS/9 deleted]. -- / INET:rjc@gnu.ai.mit.edu * // The opinions expressed here do not \ | INET:r_cromwe@upr2.clu.net | \X/ in any way reflect the views of my self.| \ UUCP:uunet!tnc!m0023 * /
peterk@cbmger.UUCP (Peter Kittel GERMANY) (06/28/91)
In article <1991Jun27.195750.29163@zardoz.eng.ohio-state.edu>, gaynor@agvax2.ag.ohio-state.edu writes: > And you're right, the grayed icon doesn't have anything to directly do > with re-entrancy. It's visual feedback, to show the user that the > program is already running and that (here's the kicker) -because- it's > already running, you can't run it again. > > Get it? It's visual feedback that the program can't be run, -because > it's already running-. > > On the Amiga WorkBench or in MS Windows, the icon of a running app > undergoes no change. Why? Because apps are re-entrant there. I can > have the same application running two or three time if I like. Hmm, I fear, this again is *not* re-entrance. As far as I know, this term only deals with the same piece of code used by more than one task, like in a shared Amiga library. If you just launch an Amiga program twice, its code is twice in RAM (as long as this code is not concentrated in a library), so I don't think this has anything to do with re-entrancy. (Grr, can't crosspost to the Mac Newsgroup...) -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
dant@ryptyde.UUCP (Daniel Tracy) (06/28/91)
Responding to the following: "Ok for a word. But to select a greater area, why not just click at the beginning (*ONCE*) and drag the mouse to the end? Many Amiag programs do it this way. Is there really always needed a double-click?" You can select a word by double-clicking, you can select any contiguous amount of text by dragging, and you can put the insertion point at the beginning of a document (or wherever) and then click somewhere else while the shift key is down and everything between the two positions will be selected.
dant@ryptyde.UUCP (Daniel Tracy) (06/28/91)
Responding to the following:
> The MAC does NOT have multiple screen capability. It has software
No, instead it has one huge virtual display. Different, but not inferior.jbickers@templar.actrix.gen.nz (John Bickers) (06/28/91)
Quoted from <1991Jun27.053909.23571@neon.Stanford.EDU> by torrie@cs.stanford.edu (Evan Torrie): > jbickers@templar.actrix.gen.nz (John Bickers) writes: > > Some files have an extra piece of junk on the front, while others > You're talking about MacPaint format pictures (I remember the same .MAC > files on the local boards), which are simply B&W bitmaps with limited Yeah, though there seems to be a color version too. These are the ones that get uploaded to boards non-Mac machines access too, so it makes them look like the standard the Mac presents to the rest of the world. The IFF format dates back to '85, just a year after these .MACs. It is still the standard format, since it can handle extensions for 24-bit, etc. > Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Endless variations, make it all seem new" - Devo. ***
jbickers@templar.actrix.gen.nz (John Bickers) (06/28/91)
Quoted from <127@ryptyde.UUCP> by dant@ryptyde.UUCP (Daniel Tracy):
[quoting someone else]
> "Oh, Amiga DOES NOT need a lot of desktop space compared to Mac, as we have
> screens, which a lot of Mac users still not quite understand..."
>
> Give me a break. On my dinky 9" screen (Mac SE) I have a Virtual 2-page
> display. The screen scrolls automatically according to the active window,
Perhaps, but so does the Ami. I believe there are several PD hacks
to manage the Workbench like this.
> 75%. And despite this, I can STILL use what I see (press button, switch
> windows, etc) normally.
And there is at least one hack to make Workbench run in HAM mode!
You can STILL use what you see, in all 4096 colors!
Ha. Real useful. :) I prefer being able to switch screens compared to
using a "virtual" display. Faster, and more "to the point".
--
*** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz ***
*** "Endless variations, make it all seem new" - Devo. ***dant@ryptyde.UUCP (Daniel Tracy) (06/28/91)
Responding to the following: "This is getting more and more to match the ``sheets of paper'' paradigm, and since we can't push windows off the screen (we could use that), this helps A LOT in uncluttering your workspace." Another replacement for this on the Mac is that the Multitasking Icon menu has the Hide Application command (always, in every program) to hide all entities of that program (including windows). It's useful.
dant@ryptyde.UUCP (Daniel Tracy) (06/28/91)
Responding to the following: "When a Mac app is hidden, does it still run/render, and more importantly, how long does it take for it to reopen it's display? If it has to redraw everything, it may start to get annoying if you switch alot." Yes, it does continue to run. You can switch back to it by choosing it under the "Cooperative Multitasking Icon" menu on the right side of the menu bar. This brings its windows up again. Of course the window has to be redrawn, but I don't know on what "level" the redraw is taking place.
gblock@csd4.csd.uwm.edu (Gregory R Block) (06/29/91)
From article <4918.tnews@templar.actrix.gen.nz>, by jbickers@templar.actrix.gen.nz (John Bickers): > Perhaps, but so does the Ami. I believe there are several PD hacks > to manage the Workbench like this. Skip that, go with 2.0. HUGE workbenches. 16384x16384 on mine, and then use some of the Commodities. Let's see. 16384/640=25.6, and since my 1084 is about a foot wide, that's 25.6 feet wide, by... 16384/400=40.96, x9", gives me 25.6 feet by 30.72 feet. Kind of puts the Mac to shame, dontcha think??? :) -- Socrates: "I drank WHAT????" LMFAP: "Next time you see me, it won't be me." Wubba: "A dream is nothing more than a wish dipped in chocolate and sprinkled with a little imagination." (From my poem, "A Dream") -Wubba
NJ_GOKEMEIJE@FANDM.BITNET (06/29/91)
>From: IN%"tappek@infonode.ingr.com" "J. Kurt Tappe" 28-JUN-1991 13:02:00.77 > >>philip@pescadero.Stanford.EDU (Philip Machanick) writes: [ MORE ELABORATE STUFF DELETED ] >Amen. And I think it's agreed on both sides that we're missing >indicators to tell the user that there are screens or windows >behind the ones we are viewing. I'd love to see this on BOTH >the Amiga and Mac. On the mac, I often have large windows that >completely cover small ones, and I hate to move them to get at >the ones underneath because the Desktop saves the new position >unless I put them back! On the Amiga, I often have 4-6 screens >open at once, and there is no quick way to jump directly to >a certain one without flipping thru all the others. >Mods to both systems needed! :-) > >Kurt With system 7.0 on the MAC you can hide all other applications except the current one, which will clean the desktop, and you can choose the applications from the icon-menuitem-list-thingie in the right in the menubar. And more and more programs have an menuitem called windows, which allows you to directly go to the window you want. Off course you can still loose windows behind others, but it is a step in the right direction. On the AMIGA there is a public domain utility that creates a window orso, that allows you also to directly choose what screen you want to go to. That is also a step in the right direction. Unfortunately I think it is kinda big, so I don't use it on my 1 MEG A500. (50 K orso is a wild guess) Hope it helps, Nils Gokemeijer (NJ_GOKEMEIJE@FandM.bitnet) O O O O \ \ \ \ There is more in life _\_______\_______\_______\______ then CREW, ~~~~~~~____F_and_M_CREW________________~~~~~~~~ but not much! / / / / / / / / O O O O
arctngnt@amiganet.chi.il.us (Bowie J Poag) (06/29/91)
Not only multiple virtual pages on the Amiga, but 2.0 will alow multiple virtual scrolling pages (eek) ....Yah know, your Workbench 2.0 screen will be a virtual size of mabye 1280 X 960, meanwhile, your spreadsheet or wordprocessor with a 1536 X 1024 virtual size.. I know...because thats what my 2.0 workbench is set to now! "Think John Hinkley would be impressed if Reagan shot Jodie Foster?" - Me =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nothin like a good single-tasking, single-processor based beep-box like an IBM to liven things up 'round the office! -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Direct all bomb threats and assorted hate-mail to arctngnt@amiganet.chi.il.us
awessels@ccwf.cc.utexas.edu (Allen Wessels) (06/29/91)
In article <14292@goofy.Apple.COM> lsr@Apple.COM (Larry Rosenstein) writes: >There's no point in having a word processor open a graphics document. At >best it will put up a message saying it can't open the document; at worst it >will display garbage. Of course, that doesn't keep Microsoft Word from opening MacPaint documents (and interpreting them correctly.) >You make the mistake of thinking that all users have your understanding of >what goes on inside a computer. There are a lot of highly intelligent >people who happen not to have CS degrees. What I think many CLI advocates and/or Mac bashers forget is the number of people out there who have a hard time with computers. The Mac may not have the "down to the metal" power of the Amiga, but a skilled user can use a pair of "pliers" to get a lot of different jobs done. Wrenches are probably better in the final analysis, but a good set of pliers can do wonders. And most people who need to can use 'em.
nguyent@balboa.eng.uci.edu (Thien Nguyen) (06/29/91)
I have one complaint about workbench 2.0 on the Amiga. They should make dragging and putting the icons in the drawers like the Mac. When you have several icons to put in a drawer sometimes, it's hard to know which directory I am putting the icons in. The directories should get selected or something...
mykes@amiga0.SF-Bay.ORG (Mike Schwartz) (06/29/91)
In article <1991Jun27.192905.29011@zardoz.eng.ohio-state.edu> gaynor@agvax2.ag.ohio-state.edu writes: >In article <127@ryptyde.UUCP>, dant@ryptyde.UUCP (Daniel Tracy) writes: >>Give me a break. On my dinky 9" screen (Mac SE) I have a Virtual 2-page >>display. The screen scrolls automatically according to the active window, >>WP cursor position, or mouse cursor. > >But "Joe MacUser" doesn't have this. Your virtual 2-page monitor >requires a third-party extension to the Macintosh System Software, >whereas the multiple virtual screens of the Amiga are part of the OS. > >Please, this has been a great thread thus far - this is the first >semi-imflammatory response thus far (that wasn't smileyed). Let's >keep it that way, not turn it into a "oh yeah?" "sez you!" thread... > Amiga OS 2.0 supports a scrolling workbench larger than the screen. It is part of the OS, and NOT some third part add-on product. -- **************************************************** * I want games that look like Shadow of the Beast * * but play like Leisure Suit Larry. * ****************************************************
metahawk@aix01.aix.rpi.edu (Wayne G Rigby) (06/29/91)
In article <1991Jun27.154807.28286@zardoz.eng.ohio-state.edu> gaynor@agvax2.ag.ohio-state.edu writes: > >Admittedly, you get the same "functionality" of screen-flipping with >the Hide feature in System 7. But the multiple virtual screens >provide more apparent room. It's hard to quantify, but it is my >opinion (as someone who's used both Macs and Amigas) that being able >to flip or drag "virtual" screens is more useful than app hiding. I >mean, let's be honest here. I know -I'd- rather have more screen >space - virtual -or- real. As an observation from someone who doesn't own an Amiga or a Mac, but who has played with both for a while, including AmigaDOS 2.0 & System 7.0, I find the Amiga multiple screens much more convenient than the Macintosh's flat display. The Amiga's WorkBench can do anything the Mac's desktop can, and it has the ability to have more such screens behind it, especially with 2.0's public screens. The Mac just has the one screen that you see, whereas an Amiga has several that reach back deeper into the monitor and can be slid around like HUGE windows (each with its own command bar) to give a more 3D effect to the workspace. It IS much like working with several different papers at a real desk, except these pages are much more powerful and interactive than the average sheet of paper. >Hey, to the folks who were talking about AmigaDOS 2.0 - is that thing >out of beta yet? I saw a beta about a year ago, and was -very- >impressed. It was supposed to out RSN back then... :-( Where have you been? It's been out of beta for a long time. They're already up to 2.03, and developers have 2.04. >--- >Jim Gaynor - AgVAX System Manager - Academic Computing - Ohio State University >VMS:<gaynor@agvax2.ag.ohio-state.edu> UNIX:<gaynor@magnus.acs.ohio-state.edu> >Disclaimer : All opinions expressed here are mine and only mine. So there! >Witty Quote: "Shoot him now! Shoot him now!" - Daffy Duck, "Rabbit Seasonings" "Hello? Is there anybody in there? Wayne Rigby "Just nod if you can hear me." Computer and Systems Engineer - Pink Floyd (A delightful blend of EE and CS) Rensselaer Polytechnic Institute Yes, C-128's still live! metahawk@rpi.edu
peter@Sugar.NeoSoft.com (Peter da Silva) (06/29/91)
In article <1428@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: > If you just launch an Amiga > program twice, its code is twice in RAM (as long as this code is not > concentrated in a library), Or unless the program was written to be PURE, and was made resident. -- Peter da Silva. `-_-' <peter@sugar.neosoft.com>. 'U` "Have you hugged your wolf today?"
arctngnt@amiganet.chi.il.us (Bowie J Poag) (06/30/91)
In article <286BBBC1.27644@orion.oac.uci.edu>, nguyent@balboa.eng.uci.edu (Thien Nguyen) writes: > > >I have one complaint about workbench 2.0 on the Amiga. They should make >dragging and putting the icons in the drawers like the Mac. When you have >several icons to put in a drawer sometimes, it's hard to know which >directory I am putting the icons in. The directories should get selected >or something... Uhhhh, they already have that. :) "Think John Hinkley would be impressed if Reagan shot Jodie Foster?" - Me =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nothin like a good single-tasking, single-processor based beep-box like an IBM to liven things up 'round the office! -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Direct all bomb threats and assorted hate-mail to arctngnt@amiganet.chi.il.us
torrie@cs.stanford.edu (Evan Torrie) (06/30/91)
gblock@csd4.csd.uwm.edu (Gregory R Block) writes: >Skip that, go with 2.0. HUGE workbenches. 16384x16384 on mine, and >then use some of the Commodities. Presumably, the screen has to be stored in memory. 16384 x 16384 even at 1 bit/pixel = 32MB RAM. A bit excessive? >Let's see. 16384/640=25.6, and since my 1084 is about a foot wide, >that's 25.6 feet wide, by... 16384/400=40.96, x9", gives me 25.6 feet >by 30.72 feet. Kind of puts the Mac to shame, dontcha think??? :) Not really. QuickDraw supports a coordinate space of 65536 x 65536. If you had enough memory, supposedly you could create a virtual screen this big. At 72 dpi, that's 23 m x 23 m. -- ------------------------------------------------------------------------------ Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu "And remember, whatever you do, DON'T MENTION THE WAR!"
torrie@cs.stanford.edu (Evan Torrie) (06/30/91)
jbickers@templar.actrix.gen.nz (John Bickers) writes: > The IFF format dates back to '85, just a year after these .MACs. It > is still the standard format, since it can handle extensions for > 24-bit, etc. The PICT format dates back to '84. It is still the standard format, since it can handle extensions for 24-bit, etc. -- ------------------------------------------------------------------------------ Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu "And remember, whatever you do, DON'T MENTION THE WAR!"
rjc@geech.gnu.ai.mit.edu (Ray Cromwell) (06/30/91)
In article <14318@pasteur.Berkeley.EDU> navas@cory.Berkeley.EDU writes: >Weeell. That's one opinion of course. For the beginner user (which neither of >us are) there really isn't enough visual clueing as to whether menus exist >or not. Witness, if you will, poor Joe user confused the first time he >fires up dpaint and hits his right mouse button. Is our society so illiterate that noone can RTFM anymore? I mean sheesh, whenever I get a new stereo/vcr I read the manual so I know what its features and caveats are. Using the right mouse button in paint programs is far easier to paint with than having to hit a hotkey/gadget/menu item to switch draw modes. If a user is so stupid that he can't read the manual then he doesn't deserve a computer. " When drawing in FooPaint, the right mouse button no longer functions normally. The right mouse button now erases pixels. To choose menu items you must point the mouse to the top of the screen and press the right mouse button." >Also, there are some serious intuition-type conflicts that I'm not convinced >PopUpMenu has solved. > >The menu system on the Amiga sucks. I think the folks at Cmdre know that, its >a matter of allocation of resources. Certainly it seemed to be one of jimm's >laments, although I think he seemed to be dreading attacking the problem. :) > >[Intuition's state machine was already broken....] I've been looking at the PopUpMenu source and thinking of solutions, but the problem isn't simple. Idea #1: Get rid of the LockIBase and instead only lock the window's layer. Render the menu's into the Window's rastport. Problems: Menu's will be clipped at the Window's border. Menu's will overwrite the border pixels on non GZZ windows Only one window will have rendering blocked. What happens if the task that owns the window decides to CloseWindow() and exit? The Window structure/layer might be invalidated while I'm rendering into it. Idea #2: Create a new layer for the menus Problems: Slow rendering fragments memory more Bonuses: Even the active window which the menu is attached too can still render Problem: Since the task is no longer blocked from rendering, it is free to close it's window, free the menu strip, and exit while I have the menu's up. Imagine the horrors when I try to send a MENUPICK msg to an invalid msg port. This still doesn't solve the problem of drawing window outlines and icons. Do you suggest we call a MoveLayer() and move the whole window like the NeXT when dragging? Sure it would look smooth on an A3000, but on an A500 MoveLayer() is horrible. And having layers for each Icon? YUCK! That would be horrible comparing the way Amiga icons smoothly drag (vs the Mac dragging an outline) Sorry, I must disagree. This is _NOT_ a good thing for the A500/2000. The Amiga's interface is responsive because of the special cased ways icons/bobs/menus and outlines are handled. And it's only a minor nitpick. If you don't like it, put a shell window on every screen, most Apps have their own screen anyway and the problem disappears. Unless you suggest C= compile a special 68020/30 version of the OS with layers/clipping/slective locking for everything. I'd agree. Actually, I think menus suck period. It takes to long to select a menu item. Hotkeys and gadgets are better. >David Navas navas@cory.berkeley.edu > 2.0 :: "You can't have your cake and eat it too." >Also try c186br@holden, c260-ay@ara and c184-ap@torus -- / INET:rjc@gnu.ai.mit.edu * // The opinions expressed here do not \ | INET:r_cromwe@upr2.clu.net | \X/ in any way reflect the views of my self.| \ UUCP:uunet!tnc!m0023 * /
rjc@geech.gnu.ai.mit.edu (Ray Cromwell) (06/30/91)
Horrible hack idea #3 for PopUpMenus:
SetFunction CloseWindow() and related functions and make sure
the current Window structure doesn't get pulled out from
beneath our feet while were diddling with it.
I made a comment in c.s.a.programmer about PopUpMenus being buggy.
Well I FTPed the newest version to see it it was fixed. It worked for
5 hours and after posting the last msg, I hit F1 to zoom one of my
Conman windows and got a guru (8109 I believe). I'm not touching
PopUpMenu for a long time. My Amiga was GURUless for about 3 weeks.
(The only time I ever get GURUs is when trying out PD hacks, or
when I'm programming[caused by me])
PopUpMenu's is a nice hack, but something like this should be done at
the OS level.
In the spirit of Mike S.
***************************************************
*I want Menu's that look like Motif but play like *
*AmigaDOS. *
***************************************************
--
/ INET:rjc@gnu.ai.mit.edu * // The opinions expressed here do not \
| INET:r_cromwe@upr2.clu.net | \X/ in any way reflect the views of my self.|
\ UUCP:uunet!tnc!m0023 * /navas@cory.Berkeley.EDU (David C. Navas) (06/30/91)
In article <1991Jun29.232917.28817@mintaka.lcs.mit.edu> rjc@geech.gnu.ai.mit.edu (Ray Cromwell) writes: >In article <14318@pasteur.Berkeley.EDU> navas@cory.Berkeley.EDU writes: >>Weeell. That's one opinion of course. For the beginner user (which neither of >>us are) there really isn't enough visual clueing as to whether menus exist >>or not. Witness, if you will, poor Joe user confused the first time he >>fires up dpaint and hits his right mouse button. > > Is our society so illiterate that noone can RTFM anymore? I mean sheesh, >whenever I get a new stereo/vcr I read the manual so I know what its features You know, it's attitudes like these that restrict computers to such a small audience. Personally, I think you should have stuck with your PC. Shoot, why give the user any clue at all, keep him in a text screen. Sheesh, indeed. Perhaps our society has BETTER THINGS TO DO than RTFM? >draw modes. If a user is so stupid that he can't read the manual then >he doesn't deserve a computer. If a programmer doesn't program in a clear, concise, intuitive way, his programs don't deserve to make any money. What I'd like to know is how many ovens Americans have compared to how many Americans know how to cook? >" When drawing in FooPaint, the right mouse button no longer functions >normally. The right mouse button now erases pixels. To choose menu items >you must point the mouse to the top of the screen and press the right mouse >button." "When drawing in FooPaint, the right mouse button no longer functions. To get your menus, please hit SHIFT_ALT_CTRL-M-E-N-U while humming the Star Spangled Banner." "This brand new GTE lightbulb will last longer than your house. To install, please turn power off, pull out Tab A from socket 1, pulling perpendicular to Tab B. Carefully insert socket extender 2 onto Tabs A and B, being careful to match Tab A with Female connection 2A. Insert lightbulb assembly into socket extender. Connect vaccuum assembly to glass cover. Turn on vaccuum assembly, and when vaccuum indicator reads positive, quickly move glass cover over lightbulb assembly, making sure that no air accidentally leaks into glass cover. Weld glass to assembly and turn power back on. Warrantee does not extend to incorrectly assembled lightbulb packages." I don't think so, that's why consistency in the user interface is so important. If you think these are silly cases, I'll dig out the directions old GE refrigeration units used to have. This was only a close approximation :) I'm not arguing the case that's it's easier to draw with two buttons for two pens, just that menus should be clued -- IE at the top of the window, OR you can use a SHIFT-RIGHT_BUTTON anywhere in the window, or something like that. In the best case -- YOU THE USER get to choose.... >>Also, there are some serious intuition-type conflicts that I'm not convinced >>PopUpMenu has solved. >[stating problem isn't simple] You are right, it is not easy. >Idea #1: >Idea #2: Neither is ideal, as you point out. > This still doesn't solve the problem of drawing window outlines >and icons. Do you suggest we call a MoveLayer() and move the whole >window like the NeXT when dragging? Sure it would look smooth on an No, why would I suggest something like that? >A3000, but on an A500 MoveLayer() is horrible. And having layers >for each Icon? YUCK! That would be horrible comparing the way Amiga >icons smoothly drag (vs the Mac dragging an outline) Where are you coming up with this? > Sorry, I must disagree. This is _NOT_ a good thing for the A500/2000. Really, I'm not sure who you are disagreeing with, but it's not me. >The Amiga's interface is responsive because of the special cased ways >icons/bobs/menus and outlines are handled. And it's only a minor nitpick. If your machine hangs, it is NOT a minor problem. There are two possible ways out: 1: Intuition gets rewritten with hooks to run custom menu code. 2: Use Workbench timeout approach. [By the way, even RJ thinks that his Gel code sucked...] > Actually, I think menus suck period. It takes to long to select a menu >item. Hotkeys and gadgets are better. Yeah, Ray, should have stuck with that PC. I suppose you like the way those WP strips hang over your function keys, or have you memorized all 40 functions? The idea with menus is rather simple -- they are out of the way when you don't want them, and they are on screen when you do want them. The same cannot be said of gadgets (which are always there) or hotkeys (which are never on screen). Combining too many features into one key can be deadly "F10?, drat, I meant SHIFT F10." And crowding a zillion gadgets onto the screen makes your Amiga look like the cockpit of the shuttle. I tell you what, why don't you go use TECO for awhile. If you're happy with that, I can't help you :), otherwise we can have a nice discussion about what "user interface" means. David Navas navas@cory.berkeley.edu 2.0 :: "You can't have your cake and eat it too." Also try c186br@holden, c260-ay@ara and c184-ap@torus
peter@Sugar.NeoSoft.com (Peter da Silva) (06/30/91)
In article <1991Jun29.205207.5681@neon.Stanford.EDU> torrie@cs.stanford.edu (Evan Torrie) writes: > jbickers@templar.actrix.gen.nz (John Bickers) writes: > > The IFF format dates back to '85, just a year after these .MACs. It > > is still the standard format, since it can handle extensions for > > 24-bit, etc. > The PICT format dates back to '84. It is still the standard format, since > it can handle extensions for 24-bit, etc. Oh? Including audio samples, musical scores, animations, MIDI tracks, and so on? -- Peter da Silva. `-_-' <peter@sugar.neosoft.com>. 'U` "Have you hugged your wolf today?"
rjc@geech.gnu.ai.mit.edu (Ray Cromwell) (06/30/91)
In article <14332@pasteur.Berkeley.EDU> navas@cory.Berkeley.EDU writes: >In article <1991Jun29.232917.28817@mintaka.lcs.mit.edu> rjc@geech.gnu.ai.mit.edu (Ray Cromwell) writes: >>In article <14318@pasteur.Berkeley.EDU> navas@cory.Berkeley.EDU writes: >>>Weeell. That's one opinion of course. For the beginner user (which neither of >>>us are) there really isn't enough visual clueing as to whether menus exist >>>or not. Witness, if you will, poor Joe user confused the first time he >>>fires up dpaint and hits his right mouse button. >> >> Is our society so illiterate that noone can RTFM anymore? I mean sheesh, >>whenever I get a new stereo/vcr I read the manual so I know what its features > >You know, it's attitudes like these that restrict computers to such a small >audience. Personally, I think you should have stuck with your PC. Shoot, >why give the user any clue at all, keep him in a text screen. Sheesh, indeed. (I don't, and havenever owned a PC., so there. :-p) >Perhaps our society has BETTER THINGS TO DO than RTFM? Perhaps our society has better things to do than read? When software is distributed I think users should read the instruction manual. >I'm not arguing the case that's it's easier to draw with two buttons for two >pens, just that menus should be clued -- IE at the top of the window, OR >you can use a SHIFT-RIGHT_BUTTON anywhere in the window, or something like >that. In the best case -- YOU THE USER get to choose.... As far as I know, lots of paint programs have selectable menu bars. (Turn them on of off) Most of them have a paint toolbox at the top of the screen with menu bar. Ok, if your willing to justify screen real estate I guess you could put a "click here for menus you dummy" at the top of the screen. >>>Also, there are some serious intuition-type conflicts that I'm not convinced >>>PopUpMenu has solved. >>[stating problem isn't simple] > >You are right, it is not easy. > >>Idea #1: >>Idea #2: > >Neither is ideal, as you point out. > >> Sorry, I must disagree. This is _NOT_ a good thing for the A500/2000. > >Really, I'm not sure who you are disagreeing with, but it's not me. I'm disagreeing with the fact that Menus shouldn't lock rendering, on the A500 locking is more efficient. >>The Amiga's interface is responsive because of the special cased ways >>icons/bobs/menus and outlines are handled. And it's only a minor nitpick. > >If your machine hangs, it is NOT a minor problem. There are two possible >ways out: > > 1: Intuition gets rewritten with hooks to run custom menu code. Might make DIG harder. > 2: Use Workbench timeout approach. ??? >[By the way, even RJ thinks that his Gel code sucked...] I think the Gel code sucks too, it's too slow. It bogs down the entire machine just running a simple Gel object. >> Actually, I think menus suck period. It takes to long to select a menu >>item. Hotkeys and gadgets are better. > >Yeah, Ray, should have stuck with that PC. I suppose you like the way those >WP strips hang over your function keys, or have you memorized all 40 functions? Where do I ever said I own a PC or ever owned one? I think the Menu paradigm sucks, there must be something better, like pop-up toolboxes/gadgets or atleast pop-up menus are better than normal menus. I hate having to move the mouse to the top of the screen to select a function! >The idea with menus is rather simple -- they are out of the way when you don't >want them, and they are on screen when you do want them. The same cannot >be said of gadgets (which are always there) or hotkeys (which are never >on screen). But menus take mouse gymnastics to activate. >I tell you what, why don't you go use TECO for awhile. If you're happy with >that, I can't help you :), otherwise we can have a nice discussion about >what "user interface" means. I use Emacs, do I win a prize? I'd be glad to discuss user-interfaces. I just thing the standard menus that the Mac/Amiga use are cumbersome sometimes for something like a mouse. A two button light-pen/touch screen would be much cooler. Touch the titlebar, then touch a menu item. But using the mouse for heavy duty menu work can be nerve racking sometimes. The WIMP interface isn't the be-all of interfaces. I simply think something better, more adaptable to a mouse can be worked out. (Pop-up menus are a step in the right direction. I think pop-up menus should be toggleable so that sometimes they stay on the screen when you release the mousebutton and go away when you click the mouse button again.) >David Navas navas@cory.berkeley.edu > 2.0 :: "You can't have your cake and eat it too." >Also try c186br@holden, c260-ay@ara and c184-ap@torus -- / INET:rjc@gnu.ai.mit.edu * // The opinions expressed here do not \ | INET:r_cromwe@upr2.clu.net | \X/ in any way reflect the views of my self.| \ UUCP:uunet!tnc!m0023 * /
navas@cory.Berkeley.EDU (David C. Navas) (06/30/91)
Now we're getting someplace useful. :) In article <1991Jun30.015828.5393@mintaka.lcs.mit.edu> rjc@geech.gnu.ai.mit.edu (Ray Cromwell) writes: >In article <14332@pasteur.Berkeley.EDU> navas@cory.Berkeley.EDU writes: >>In article <1991Jun29.232917.28817@mintaka.lcs.mit.edu> rjc@geech.gnu.ai.mit.edu (Ray Cromwell) writes: > (I don't, and havenever owned a PC., so there. :-p) Used only for demo. :) > >>Perhaps our society has BETTER THINGS TO DO than RTFM? > > Perhaps our society has better things to do than read? When >software is distributed I think users should read the instruction manual. And I think that users should be able to get as much performance out of a program WITHOUT the manual, but when they get stuck, the manual should be helpful (which, sigh, they rarely are. But they're usually stuck on paper....). > As far as I know, lots of paint programs have selectable menu bars. Precisely, so that when you start it up, you know what's what. >(Turn them on of off) Most of them have a paint toolbox at the top of the >screen with menu bar. Ok, if your willing to justify screen real >estate I guess you could put a "click here for menus you dummy" at the top of >the screen. Yep, probably what I would argue. Actually, I'd argue that the current menu paradigm is really hosed. Especially on the Amiga, and it's getting worse on the Mac, too. > I'm disagreeing with the fact that Menus shouldn't lock rendering, on the >A500 locking is more efficient. Okay, give this one a shot then. Amiga brings up menus. *WHILE* menus are up, layer is created beneath where the menus are. Layers gets reset so that menu now reside entirely within layer, hidden layers are given the swapped bitmapped images, back, and LayerInfo is unlocked. Woila, user response didn't suffer, and we get something which doesn't *keep* layers locked. Icons, etc. are a completely separate problem, and should *definitely* lock the screen. OR we need to add greater abilities to those Bobs... [like every other system has to do with mouse pointers cause they don't have Sprites, natch.] > I think the Gel code sucks too, it's too slow. It bogs down the entire >machine just running a simple Gel object. Here's hoping in 2.1... > Where do I ever said I own a PC or ever owned one? I think the Menu It's a wicked lie. :) >paradigm sucks, there must be something better, like pop-up toolboxes/gadgets >or atleast pop-up menus are better than normal menus. I hate having to >move the mouse to the top of the screen to select a function! Menus are good for things which are consistent across apps. File:Open/etc., Edit:Cut/Paste/etc.... And, of course, we want tear off menus. I agree with the popup menus, they are much better suited for a lot of needs. >>The idea with menus is rather simple -- they are out of the way when you don't >>want them, and they are on screen when you do want them. The same cannot >>be said of gadgets (which are always there) or hotkeys (which are never >>on screen). > > But menus take mouse gymnastics to activate. Righto, detachable, tear-off menus. Very nice. Even nicer if you could reduce them to an icon (button). Even better to have the user be able to customize how his menu system works, of course. >>I tell you what, why don't you go use TECO for awhile. If you're happy with >>that, I can't help you :), otherwise we can have a nice discussion about >>what "user interface" means. > > I use Emacs, do I win a prize? Well, actually, you do. Out of the editors tested way back when, it was one of the best (especially for a Glass TTY interface). Of course, one of the reasons you use Emacs over TECO is that Emacs is way nicer to use, eh? {Yes, yes, emacs was written via TECO way back when) > I'd be glad to discuss user-interfaces. I just thing the standard menus >that the Mac/Amiga use are cumbersome sometimes for something like a mouse. Could be. That's why EVERY menu operation should have a keyboard equivalent. Especially for editors, where moving your hand to the mouse takes awhile. You wouldn't need to use your mouse, then. But for the casual user, he/she wouldn't need to remember dozens of shortcuts. >A two button light-pen/touch screen would be much cooler. Touch the >titlebar, then touch a menu item. But using the mouse for heavy >duty menu work can be nerve racking sometimes. The WIMP interface Well, WIMP is better than 24 line terminals, but it's got a ways to go... I disagree about the lightpen though. It'd take longer to use a lightpen (pick it up, mvoe to location, push, move, push). Especially for someone who works out and likes to be able to relax his arms on the keyboard. Would hate to pick up my arms :) >isn't the be-all of interfaces. I simply think something better, more >adaptable to a mouse can be worked out. Well, possibly. There are only so many things you can do with the mouse. And Amiga programs do generally have poor UI's, it's improving with 2.0 though. Don't you hate working out the quirks with file requesters: double-click or single-click to change to a directory? Can you use the arrow keys to move between selections? Or string gadget entry? >(Pop-up menus are a step in the right direction. I think pop-up menus >should be toggleable so that sometimes they stay on the screen when you >release the mousebutton and go away when you click the mouse button >again.) I've always liked to be able to "pin" my menus to the work area. ESPECIALLY when testing. Can't tell you how many race conditions you can find that way.... Some of them were quite, ummm, interesting. Programmable interfaces. That's what I want. Intuition has a *long* way to go for something like that, though. Too bad.... David Navas navas@cory.berkeley.edu 2.0 :: "You can't have your cake and eat it too." Also try c186br@holden, c260-ay@ara and c184-ap@torus
torrie@cs.stanford.edu (Evan Torrie) (06/30/91)
peter@Sugar.NeoSoft.com (Peter da Silva) writes: >> The PICT format dates back to '84. It is still the standard format, since >> it can handle extensions for 24-bit, etc. >Oh? Including audio samples, musical scores, animations, MIDI tracks, and so >on? No, that's the movie format, which can sync all of the above. -- ------------------------------------------------------------------------------ Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu "I didn't get where I am today without knowing a good deal when I see one, Reggie." "Yes, C.J."
torrie@cs.stanford.edu (Evan Torrie) (06/30/91)
rjc@geech.gnu.ai.mit.edu (Ray Cromwell) writes: >In article <14332@pasteur.Berkeley.EDU> navas@cory.Berkeley.EDU writes: >>Perhaps our society has BETTER THINGS TO DO than RTFM? > Perhaps our society has better things to do than read? When >software is distributed I think users should read the instruction manual. Our society does have better things to do than read, especially if the reason for reading is just because someone has decided to use some kinky type of interface, which matches nothing else available. > Where do I ever said I own a PC or ever owned one? I think the Menu >paradigm sucks, there must be something better, like pop-up toolboxes/gadgets >or atleast pop-up menus are better than normal menus. I hate having to >move the mouse to the top of the screen to select a function! Why don't you just assign command keys to the menu items you use a lot? Then, while you're learning, you can scan the menus with your mouse, but for heavy duty work, you just settle back to your command keys. >>The idea with menus is rather simple -- they are out of the way when you don't >>want them, and they are on screen when you do want them. The same cannot >>be said of gadgets (which are always there) or hotkeys (which are never >>on screen). > But menus take mouse gymnastics to activate. But gadgets take up screen space, while hotkeys take mental gymnastics to be able to remember every one of them when you're an infrequent user. >duty menu work can be nerve racking sometimes. The WIMP interface >isn't the be-all of interfaces. I simply think something better, more >adaptable to a mouse can be worked out. Well, how about a voice interface? "Edit, Cut". -- ------------------------------------------------------------------------------ Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu "I didn't get where I am today without knowing a good deal when I see one, Reggie." "Yes, C.J."
barrett@iastate.edu (Barrett Marc N) (06/30/91)
In article <arctngnt.1685@amiganet.chi.il.us> arctngnt@amiganet.chi.il.us (Bowie J Poag) writes: >In article <286BBBC1.27644@orion.oac.uci.edu>, nguyent@balboa.eng.uci.edu >(Thien Nguyen) writes: >> >> >>I have one complaint about workbench 2.0 on the Amiga. They should make >>dragging and putting the icons in the drawers like the Mac. When you have >>several icons to put in a drawer sometimes, it's hard to know which >>directory I am putting the icons in. The directories should get selected >>or something... > > > > > >Uhhhh, they already have that. :) Not "they" don't, if you are talking about the Amiga. What Mr. Poag was referring to was the way that, on a Macintosh, the destination icon highlights if you drag one or more icons around the desktop. The Amiga has nothing even closely resembling this, and dragging icons around the Amiga's Workbench becomes a guessing game as to where the icon will end up once you release it, especially if you are dragging multiple icons, large icons, or both. > >"Think John Hinkley would be impressed if Reagan shot Jodie Foster?" - Me >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >Nothin like a good single-tasking, single-processor based beep-box like an IBM >to liven things up 'round the office! >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >Direct all bomb threats and assorted hate-mail to arctngnt@amiganet.chi.il.us -- ------------------------------------------------------------- / Marc Barrett -MB- | BITNET: XGR39@ISUVAX.BITNET / / ISU COM S Student | Internet: XGR39@CCVAX.IASTATE.EDU / ------------------------------------------------------------
sho@gibbs.physics.purdue.edu (Sho Kuwamoto) (06/30/91)
torrie@cs.stanford.edu (Evan Torrie) writes: > Well, how about a voice interface? "Edit, Cut". Well, I know you were only somewhat serious when you suggested this, but I want to point out the negatives anyway. * You will have problems in situations (like computer labs) where many computers are close together. * Voice commands force you to memorize the commands before using them. This (to me) is the main benefit of using menus. From Inside Macintosh VI: "Users rely on recognition, not recall [...] People don't have to remember anything the computer already knows, such as which commands are available." If you want to use voice commands IN ADDITION to menu commands, I don't see how that improves the status quo. In this case, we're not talking about voice vs. menus... we're talking about voice vs. keyboard shortcuts. I don't know about you, but I'd rather hit a key sequence than say, "cut." I'm sure the person working on the computer next to me feels the same way. Voice commands might be useful one day in the future when natural language parsers, voice recognition, and other AI things (about which I have little knowledge) are more advanced. If a businessman can ask the computer questions like: "If we lay off 1500 employees and cut margins across the product line by 5%, how would that affect our bottom line?" and expect a reasonable answer, then *obviously* voice input will be natural and useful. Until then... -Sho -- sho@physics.purdue.edu
jbickers@templar.actrix.gen.nz (John Bickers) (06/30/91)
Quoted from <1991Jun29.205207.5681@neon.Stanford.EDU> by torrie@cs.stanford.edu (Evan Torrie): > jbickers@templar.actrix.gen.nz (John Bickers) writes: > > The IFF format dates back to '85, just a year after these .MACs. It > > is still the standard format, since it can handle extensions for > The PICT format dates back to '84. It is still the standard format, since > it can handle extensions for 24-bit, etc. Except that it is NOT the standard format. If it were a genuine standard, then why are the pictures exported to other platforms by local Mac owners in a different Macintosh format, rather than PICT? Pick one: (a) the .MAC was the standard format, but now things have changed. And thus dies the "still the standard format". (b) the .MAC is a non-standard format that people used because they didn't know better. Says a lot for the quality of such "standards" on the Mac. The Ami paint software I've seen can't save in anything BUT IFF. Point (b) is similar to the line of reasoning re the clipboard, btw. > Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Endless variations, make it all seem new" - Devo. ***
sho@gibbs.physics.purdue.edu (Sho Kuwamoto) (07/01/91)
jbickers@templar.actrix.gen.nz (John Bickers) writes: > Pick one: > > (a) the .MAC was the standard format, but now things have changed. And > thus dies the "still the standard format". > > (b) the .MAC is a non-standard format that people used because they > didn't know better. Says a lot for the quality of such "standards" > on the Mac. The Ami paint software I've seen can't save in > anything BUT IFF. Pardon me, but I've been using and programming the mac for six years, and I have never heard of the .MAC format. Can anyone tell me what it really is? Is it a MacPaint file? Is it a PICT file? EPS? TIFF? Let me give you a run-down: MacPaint: Created early-early-early for use by the MacPaint program. Stores b/w bitmaps of a specific size (1 page) with a little compression. PICT: Standard picture file also from early-early-early. PICT files contain a bunch of opcodes which must be incredibly difficult for other machines to decipher. The simple ones are instructions like "draw a rectangle here." Complicated ones are more mac specific. On the mac, a programmer just has to call DrawPicture() and it decodes the picture for him. Creating a PICT file is equally trivial. PICT files have been extended to cover 24-bit images, JPEG compression, automatic dithering (used when 24 bit images are shown on an 8 bit screen, for example), and so on. EPS: Encapsulated PostScript. Bascially just PostScript + a little extra information like a bounding rectangle for the picture. Useful for programs that do fancy PostScript tricks and for trading with IBM owners. TIFF: Never used it myself, but it's an image format that people use a lot for scanned images. I imagine it's because PICT files are bigoted and work best with 72dpi images. I think TIFF files can also be shared with IBM owners. The last two formats are industry-driven standards. EPS and TIFF exist because there are certain ways in which the PICT format is deficient. The MacPaint format is almost never used these days. It became a standard a long time ago for the reason that the MacWrite format became a standard: MacPaint and MacWrite were given away free with each mac. From what little I know about it, IFF seems very powerful. I imagine there are areas in which it outshines the PICT format. However, I don't think you can fault the PICT format for being inextensible. I also don't think you can argue that the PICT format is not a standard on the mac. Every modern paint program that I know of allows you to import and export PICT files. PICT resources (exactly the same as PICT files) are used to transfer pictures through the clipboard. I know of no modern word processor which doesn't accept pictures. Perhaps someone can tell me more about IFF and tell me why it is better than PICT. Is it really so powerful that EPS files would not be useful? I'm not even sure what kind of object-based drawing commands IFF can contain. Can IFF specify a picture as being, "one rectangle from here to here, a line, a squiggly, and a polygon filled with this pattern." -Sho -- sho@physics.purdue.edu
torrie@cs.stanford.edu (Evan Torrie) (07/01/91)
sho@gibbs.physics.purdue.edu (Sho Kuwamoto) writes: >torrie@cs.stanford.edu (Evan Torrie) writes: >> Well, how about a voice interface? "Edit, Cut". >* You will have problems in situations (like computer labs) where many > computers are close together. Yep, although there's a lot of work being done on directional microphone technology, and filtering out speakers other than the user. >* Voice commands force you to memorize the commands before using them. > This (to me) is the main benefit of using menus. From Inside > Macintosh VI: I would suggest still having the menus, but being able to navigate by voice, e.g. "Edit" - the Edit menu drops down, showing Undo, Cut, Copy Paste etc. Then "Cut" chooses the Cut command. Sort of like Word 4.0's keyboard menu walking. You should also be able to use voice for non-menu commands, such as palettes of tools, clicking and dragging etc. Since everyone is now writing their applications with Apple Events for every one of their program's commands (:-)), it should be trivial to hook up a voice recognition system for a particular program. > > If you want to use voice commands IN ADDITION to menu commands, I > don't see how that improves the status quo. In this case, we're not > talking about voice vs. menus... we're talking about voice vs. > keyboard shortcuts. I don't know about you, but I'd rather hit a > key sequence than say, "cut." I'm sure the person working on the > computer next to me feels the same way. Give the user the choice. This is another one of those "medley" situations. Sometimes I might find speaking faster, sometimes I might find using the mouse faster, and sometimes I might like to use the keyboard. It can't hurt to add another option (especially for those who have limited options already [e.g. disabled users]). >Voice commands might be useful one day in the future when natural >language parsers, voice recognition, and other AI things (about which I >have little knowledge) are more advanced. If a businessman can ask the >computer questions like: > "If we lay off 1500 employees and cut margins across the > product line by 5%, how would that affect our bottom line?" Hmmm. I wonder whether Sculley used something like this :-) >and expect a reasonable answer, then *obviously* voice input will be >natural and useful. Until then... I think it can be very useful in the meantime, (especially since what you describe is still a long way off). -- ------------------------------------------------------------------------------ Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu "Cold is God's way of telling us to burn more Catholics" - Lady Whiteadder
mmoore@ux.acs.umn.edu (Malcolm Diallo Moore) (07/01/91)
In article <1991Jun27.235411.16654@mintaka.lcs.mit.edu$ rjc@geech.gnu.ai.mit.edu (Ray Cromwell) writes:
$
$(DisplayBeep() is very annoying, it's meant that way to get your
$attention. It flashes the entire screen (on my screen colors) yellow/bright
$white for a period of atleast a second. DisplayBeep can be patched to
$use a sample (like a beep, siren, etc)
$
$--
$/ INET:rjc@gnu.ai.mit.edu * // The opinions expressed here do not \
$| INET:r_cromwe@upr2.clu.net | \X/ in any way reflect the views of my self.|
$\ UUCP:uunet!tnc!m0023 * /
Yeah yeah yeah I know this is the wrong newsgroup to post it but I saw it here
and I ain't wasting any more bandwith than I have to so.
Is there a program I could put in my startup-sequence that would patch
DisplayBeep()? Better yet is there a program that you can change (either in
menu or on CLI) the sound made when DisplayBeep() is called?
ADthanxVANCE.
Malcolm "Get Wit The Program" Moore
(mmoore@ux.acs.umn.edu)
Whaddaya want, a biscuit?awessels@ccwf.cc.utexas.edu (Allen Wessels) (07/01/91)
In article <5395@dirac.physics.purdue.edu> sho@gibbs.physics.purdue.edu (Sho Kuwamoto) writes: >Pardon me, but I've been using and programming the mac for six years, >and I have never heard of the .MAC format. Can anyone tell me what >it really is? Is it a MacPaint file? Is it a PICT file? EPS? TIFF? It has been probably 6 years since I've seen a reference to .MAC files. They are just MacPaint files. I'd never heard that there was that much of a problem with them other than stripping out the header info. I'm amazed that it was even brought up.
peter@Sugar.NeoSoft.com (Peter da Silva) (07/01/91)
In article <14318@pasteur.Berkeley.EDU> navas@cory.Berkeley.EDU writes: > Weeell. That's one opinion of course. For the beginner user (which neither of > us are) there really isn't enough visual clueing as to whether menus exist > or not. Witness, if you will, poor Joe user confused the first time he > fires up dpaint and hits his right mouse button. That's dPaint's problem. > Well, except that in the case of rendering them to the screen a layer needs > to be created. That's a given, and a good reason to keep the current menu implementation. > Bzzzt. :) What if the window isn't *wide* enough? You won't be able to read > the text. Who says the text of the menu is limited to the width of the window? It isn't on Microsoft Windows. > Also, there are some serious intuition-type conflicts that I'm not convinced > PopUpMenu has solved. Well, it hasn't triggered any of them for me yet. > The menu system on the Amiga sucks. I don't agree. It's no worse than on the Mac. The only think the Mac has over it is scrolling menus, and that's an implementation detail... can be fixed without changing the interface. -- Peter da Silva. `-_-' <peter@sugar.neosoft.com>. 'U` "Have you hugged your wolf today?"
peter@Sugar.NeoSoft.com (Peter da Silva) (07/01/91)
In article <1991Jun30.015828.5393@mintaka.lcs.mit.edu> rjc@geech.gnu.ai.mit.edu (Ray Cromwell) writes: > A two button light-pen/touch screen would be much cooler. Touch the > titlebar, then touch a menu item. But using the mouse for heavy > duty menu work can be nerve racking sometimes. You don't like mice, and you prefer light pens? Ever hear of Gorilla Arm? Actually, the Amiga menu bar makes sense for single-sensor mechanisms like a touchscreen, light pen, or *single button* mouse. Which is where this whole discussion started: *De-Macifying* the Amiga. Removing Mac kludges like menu bars from the interface... > (Pop-up menus are a step in the right direction. I think pop-up menus > should be toggleable so that sometimes they stay on the screen OpenLook has something like that: each menu has a little pushpin icon that you can select to stick the menu to the screen. -- Peter da Silva. `-_-' <peter@sugar.neosoft.com>. 'U` "Have you hugged your wolf today?"