harrow@exodus.DEC (Jeff Harrow NCSE TWO/E92 DTN=247-3134) (05/13/85)
Someone responded to my original appreciation of Music Work's
modification to the Control Panel's volume control by indicating that
"... (such was a prime example of how NOT to do something, since they
could have monitored the setting of the Control Panel's volume control,
making their's unnecessary) ..."
Well, although I don't represent Music Works, I can certainly understand
why a user of the program might enjoy having a volume control instantly
available while running the application, rather than having to fire up
the Control Panel, since different musical selections might require
volume modification.
But, the entire point of my comment was lost: Regardless of the "right
or wrongness" of using your OWN volume control (not to be determined
here), once that decision was made, their treatment of the "removal"
from the Control Panel was WELL DONE!!!! and shows some of the
inventivness and personal expression available on the Mac!
Jeff
Work address:
ARPAnet: HARROW%EXODUS.DEC@decwrl.ARPA
Usenet: {allegra,Shasta,decvax}!decwrl!dec-rhea!dec-exodus!harrow
Easynet: EXODUS::HARROW
Telephone: (617)858-3134
USPS: Digital Equipment Corp.
Mail stop: TWO/E92
1925 Andover St.
Tewksbury, MA 01876gus@Shasta.ARPA (05/14/85)
> Someone responded to my original appreciation of Music Work's > modification to the Control Panel's volume control by indicating that > "... (such was a prime example of how NOT to do something, since they > could have monitored the setting of the Control Panel's volume control, > making their's unnecessary) ..." > > Well, although I don't represent Music Works, I can certainly understand > why a user of the program might enjoy having a volume control instantly > available while running the application, rather than having to fire up > the Control Panel, since different musical selections might require > volume modification. > > But, the entire point of my comment was lost: Regardless of the "right > or wrongness" of using your OWN volume control (not to be determined > here), once that decision was made, their treatment of the "removal" > from the Control Panel was WELL DONE!!!! and shows some of the > inventivness and personal expression available on the Mac! Unfortunately, this sort of hack can never be "well done" no matter how inventive of correct that actual code is. The fact is that MusicWorks makes the prior assumption that you will use THEIR control panel with it. Since DA's are "pluggable," and not part of the application, this is an invalid assumption in the general case. In my previous posting, I was not implying that I was against having a volume control within your program, especially when that program deals directly with sound. I was stating that there was no reason to disable the regular volume control in the control panel. Both can live in harmony IF you just take the time to read the IM documentation. It is easy for your own application to monitor the volume control in between calls to desk accessories and update it's private dial. The converse is trickier, and probably bet left alone. (a lot depends on how the control panel handles things that go on behind its back.) In any case, existing code NOT inside your application should not be modified in production software. This includes non-standard systems, or systems with less than the complete array of seven (now eight) desk accessories.
ech@spuxll.UUCP (Ned Horvath) (05/14/85)
The attitude at least one correspondent takes -- read the volume control out on every DA close, or even every systemclick -- is a bit naive. The nature of DAs as "asynchronous processes" makes it impossible to take account of EVERYTHING they might do to you. As a more extreme example, I am working on an application that maintains a DeskTop image. If you run the Extras DA you can delete a file. Does this suggest that I should rescan all volume directories on every system click, just in case Extras or something like it removed a file? Has anybody tried doing this to FileVision (which retains 'back to...' in the file menu)? Take a still more extreme example: postulate a DAMover DA. Such a DA MIGHT remove a DA from the System file. So, I guess I had better reconstruct the apple menu on every system click as well. What have I missed? An irresponsible DA may clobber the System Font or one of my application fonts on a system click... How well will your last program run if some asynchronous process shoots out its temp files on the fly? Or overwrites them? Do you recalculate checksums on everything before you trust the data in the file? You see the problem. When is a "user-friendly" system allowed to give up in the face of a hostile user? =Ned=
gus@Shasta.ARPA (05/15/85)
> The attitude at least one correspondent takes -- read the volume control out > on every DA close, or even every systemclick -- is a bit naive. The nature > of DAs as "asynchronous processes" makes it impossible to take account of > EVERYTHING they might do to you. No, but it IS possible to take care of the common cases. Only the control panel sets the volume control, and then only after a systemclick... > As a more extreme example, I am working on an application that maintains a > DeskTop image. If you run the Extras DA you can delete a file. Does this > suggest that I should rescan all volume directories on every system click, > just in case Extras or something like it removed a file? Has anybody tried > doing this to FileVision (which retains 'back to...' in the file menu)? I don't know about FileVision, but the finder does just this. The new (4.1) finder does it better. It is now perfectly legal for DA's to create and destroy files (besides system, finder, and desktop) behind the finder's back. How do you think that DA's such as notepad and scrapbook can create initial files? > Take a still more extreme example: postulate a DAMover DA. Such a DA MIGHT > remove a DA from the System file. So, I guess I had better reconstruct the > apple menu on every system click as well. What have I missed? An > irresponsible DA may clobber the System Font or one of my application fonts > on a system click... The key word here is irresponsible. Obviously, a buggy or misfeatured DA will cause problems. It is not unreasonable for DA's to be responsible for not mucking around with active resources. A DA mover DA should patch the apple menu itself. > How well will your last program run if some asynchronous process shoots out > its temp files on the fly? Or overwrites them? Do you recalculate > checksums on everything before you trust the data in the file? A delete file DA should not touch open files. All temp files should remain open when in use, and should have reasonable names like 'Undofile' If a user still manages to delete the file, he's asking for it, but you can do that to practically any program on any machine. > You see the problem. When is a "user-friendly" system allowed to give up > in the face of a hostile user? In general, you should only expect things to happen that can happen with the standard 8 DA's. To this I add two things - Adding a menu in the menu bar, and deleting unopened files. (files are already created as mentioned above.) Also, you should not store things in strange places such as in free blocks of memory, and you should not store private copies of system data structures such as menu lists. It is not unreasonable for a DA to go and change the DA and font menus from under you if all you did was issue an AddResMenu to create them. If people would take the time to write applications that are friendly to DA's (those with long menu bars aren't) and DA's that are friendly to applications, (those that take more than 8K and don't abide by system conventions aren't) then many problems would be aleviated.
hestenes@sdcsla.UUCP (Eric Hestenes) (05/23/85)
> > Someone responded to my original appreciation of Music Work's ... > > But, the entire point of my comment was lost: Regardless of the "right > > or wrongness" of using your OWN volume control (not to be determined > > here), once that decision was made, their treatment of the "removal" > > from the Control Panel was WELL DONE!!!! and shows some of the > > inventivness and personal expression available on the Mac! > > Unfortunately, this sort of hack can never be "well done" no matter how You missed the original author's point entirely. Regardless of whether the fix was good or bad in terms of software engineering, the patch was most certainly good in terms of the user interface, because the authors went way out of their way to make sure that the change was visible to you. Because the change was so overtly visible to you, you might infer that the software was changed. Without important contextual clues like this one might never know that a patch/kludge had been made. Importantly, though the authors made a software design choice to create a separate tool, they provided a clue to this choice. You may question the design choice in terms of software engineering, but the the act of leaving a clue is unquestionably sound, and constitutes a form of documentation. If only all hacks had similar contextual support. Why do we so often overlook the human machine interface? Eric Hestenes Institute for Cognitive Science, C-015 UC San Diego, La Jolla, CA. 92093 (619)452-6220 Please copy replies to: ARPA: sdcsla!hestenes@nprdc other: ucbvax!sdcsvax!sdcsla!hestenes -- Eric Hestenes Institute for Cognitive Science, C-015 UC San Diego, La Jolla, CA. 92093 (619)452-6220 ARPA: sdcsla!hestenes@nprdc or hestenes@nprdc
pector@ihuxw.UUCP (s. pector) (05/29/85)
I recently read a review of MusicWorks(TM) in either Personal Computing or Popular Computing (5/85 or 6/85 issue; sorry about the confusion, but I saw all of the above and can't remember which had the review). According to the review, Marc Canter (primary author of MusicWorks, he did all the music related stuff) put the volume control in his program because the Control Panel volume control was NOT adequate for sound quality with his program (although it works just fine with ConcertWare(TM)). The torn apart volume control in the Control Panel was supposed to be a dig at Apple (at least that was what the article called it). By the way, Canter is president of the little company (a trio of programmers including himself) in Chicago that did MusicWorks and had Hayden do the marketing and distribution. In Iconcepts MacAzine's 4/85 issue, Canter says that an enhanced and improved version of MusicWorks for the 512K Mac will be available in the next few months. Also, he says that a program called VideoWorks will come out soon. The end goal he has is to allow people to make music videos using their Macs! Scott Pector