JWANKERL@UTCVM.BITNET ("Josef W. Wankerl") (11/30/89)
A friend of mine (and publisher of GS+, a gs specific magazine here in the Chattanooga area) has been writing a NDA which could use a menu bar - maybe in the info bar area. But he hasn't been able to make it work using only a minimal amount of code. I thought that TaskMasterDA would handle it, but he says that it won't. Is there an easy way to do this? /**********************************************************************\ |* Joe "Gonzo" Wankerl |*| The views expressed here are *| |* BITNET => JWANKERL@UTCVM |*| not necessarily yours... *| |* |*| ...but they should be. *| \**********************************************************************/
mattd@Apple.COM (Matt Deatherage) (11/30/89)
In article <8911300611.AA17058@apple.com> JWANKERL@UTCVM.BITNET ("Josef W. Wankerl") writes: >A friend of mine (and publisher of GS+, a gs specific magazine here in >the Chattanooga area) has been writing a NDA which could use a menu >bar - maybe in the info bar area. But he hasn't been able to make >it work using only a minimal amount of code. I thought that >TaskMasterDA would handle it, but he says that it won't. Is there an >easy way to do this? > >|* Joe "Gonzo" Wankerl | [Rest of signature deleted; I will keep my own counsel about what should and should not be my opinion.] If you mean "handle" as in it will put the menu bar there, track it and tell you what selection was made, the answer is "no". The reason is similar to the reason TaskMaster can't automatically update windows for you (IOW, you don't pass an update routine to it) - it has no idea of what you want to do. If you mean "handle" as in "I have an Info Bar procedure which draws the menu bar, then TaskMaster should tell me when there's a click in the menu bar so I can call MenuSelect and then act on the menu choice", the answer is "yes." Strategies for this are discussed in Apple IIgs Technical Note #3. Even easier is a pop-up menu as a control, which TaskMasterDA will handle for you. All you'll have to do is check to see which control was selected, and when it's the pop-up, go get the current selection from the control record. -- ----------------------------------------------------------------------------- Matt Deatherage, Apple Computer, Inc. | "The opinions expressed in this tome Send PERSONAL mail ONLY (please) to: | should not be construed to imply that Amer. Online: Matt DTS | Apple Computer, Inc., or any of its ThisNet: mattd@apple.com | subsidiaries, in whole or in part, ThatNet: (stuff)!ames!apple!mattd | have any opinion on any subject." Other mail by request only, please. | "So there." -----------------------------------------------------------------------------
roberth@microsoft.UUCP (Robert Hess) (12/07/89)
Joe Wankerl asked the original question: || ...an NDA which could use a menu bar... Is there an easy way to do || this? To which Matt Deathridge responded: | ...the answer is "yes." Strategies for this are discussed in Apple IIgs | Technical Note #3. | | | Even easier is a pop-up menu as a control, which TaskMasterDA will | handle for you. All you'll have to do is check to see which control was | selected, and when it's the pop-up, go get the current selection from | the control record. Menu's in an NDA are easy, although people don't use them very often (actually not at all, as far as I have seen) I do have code for a 'minimum' NDA for TML Pascal that illustrates this. Anybody who wants it, please eMail me and I'll eMail it back to you, no sense clogging up the forum. ...and what follows is a 'personal' style opinion hopefully nobody will take offense... Unless there is a trick to make a pop-up menu look almost exactly like a pulldown menu in an NDA, I personally would recommend against people putting a pop-up in their info bar (with some exceptions). I have seen an NDA that uses this shortcut to have 'menuness' in their application, and I personally don't care for how it looks (the same application used different colors for the window border and such, which also looked unappealing). People are used to having menus at the top of their applications. They know how to use them, and they recognize them when they see them. If you want to diverge from this, it should be for *good* reasons, not just because it is easier to code. Maintain the 'look and feel' of the Apple Interface, it is there for a reason. I have also seen people using the 'square' button type rather then the 'round' button type in their applications (includeing Apple's sample apps) I feel that this too is an improper practice. Buttons are round. That is what people are used to seeing. Sure, us programmers and experienced users who are comfortable with the apple can recognize all sorts of weird controls, and use them instantly, and aren't scared to experiment. But I have tutored new users, who *need* to have a consistant user interface, and are *scared* when they don't recognize something. Change the shape, position, usage of a control, and they are lost. - Robert __________________________________________________________________________ ##### ####### | Robert B. Hess, Microsoft Corp., Redmond, WA ###### ####### |----------------------------------------------------- ####### ####### | roberth@microsof.uu.net #### ##### #### | {decvax, uunet, uw-beaver}!microsof!roberth #### ### #### |_____________________________________________________ "...my opinions are strictly my own, and not those of my employer..."
mattd@Apple.COM (Matt Deatherage) (12/08/89)
In article <9338@microsoft.UUCP> roberth@microsoft.UUCP (Robert Hess) writes: >Joe Wankerl asked the original question: > >|| ...an NDA which could use a menu bar... Is there an easy way to do >|| this? > >To which Matt Deathridge responded: > >| ...the answer is "yes." Strategies for this are discussed in Apple IIgs >| Technical Note #3. >| >| >| Even easier is a pop-up menu as a control, which TaskMasterDA will >| handle for you. All you'll have to do is check to see which control was >| selected, and when it's the pop-up, go get the current selection from >| the control record. > >...and what follows is a 'personal' style opinion hopefully nobody will take >offense... > >Unless there is a trick to make a pop-up menu look almost exactly like a >pulldown menu in an NDA, I personally would recommend against people >putting a pop-up in their info bar (with some exceptions). I have seen >an NDA that uses this shortcut to have 'menuness' in their application, >and I personally don't care for how it looks (the same application used >different colors for the window border and such, which also looked >unappealing). People are used to having menus at the top of their >applications. They know how to use them, and they recognize them when >they see them. If you want to diverge from this, it should be for >*good* reasons, not just because it is easier to code. Maintain the >'look and feel' of the Apple Interface, it is there for a reason. > You can misspell my name, but don't put words in my mouth. I scream as loudly and as long as anyone about human interface inconsistencies. I was not meaning to recommend a pop-up in an info bar (which would not be easy to do anyway; you can't put controls in the Info Bar because it's not in your port, it's in the Window Manager's port). I was suggesting using a pop-up menu within the NDA window area as a good alternative to having a menu bar in the NDA for just a couple of menus. In fact, the pop-ups as opposed to a separte (or even separate) menu bar are actually preferable according to the HIG, which doesn't even allow for multiple menu bars. >I have also seen people using the 'square' button type rather then the >'round' button type in their applications (includeing Apple's sample >apps) I feel that this too is an improper practice. Buttons are round. >That is what people are used to seeing. Sure, us programmers and >experienced users who are comfortable with the apple can recognize all >sorts of weird controls, and use them instantly, and aren't scared to >experiment. But I have tutored new users, who *need* to have a >consistant user interface, and are *scared* when they don't recognize >something. Change the shape, position, usage of a control, and they are >lost. > I will agree that unless you have some reason to use square, drop-shadowed buttons in your program, please don't. They look just like pop-up menus and cause a lot of confusion - far more than you benefit from having a "neat" looking button. >- Robert -- ----------------------------------------------------------------------------- Matt Deatherage, Apple Computer, Inc. | "The opinions expressed in this tome Send PERSONAL mail ONLY (please) to: | should not be construed to imply that Amer. Online: Matt DTS | Apple Computer, Inc., or any of its ThisNet: mattd@apple.com | subsidiaries, in whole or in part, ThatNet: (stuff)!ames!apple!mattd | have any opinion on any subject." Other mail by request only, please. | "So there." -----------------------------------------------------------------------------
mmunz@pro-beagle.cts.COM (Mark Munz) (12/10/89)
In-Reply-To: message from roberth@microsoft.UUCP >Unless there is a trick to make a pop-up menu look almost exactly like a >pulldown menu in an NDA, I personally would recommend against people >putting a pop-up in their info bar (with some exceptions). [ some stuff deleted ] >People are used to having menus at the top of their >applications. They know how to use them, and they recognize them when >they see them. If you want to diverge from this, it should be for >*good* reasons, not just because it is easier to code. Maintain the >'look and feel' of the Apple Interface, it is there for a reason. Sorry, I just had to laugh. If you look over on the Macintosh side of the world, you'll find that menus that are attached to Window Title bars are quite common. (MicroSoft's Word has buttons and pull down menus all over the place, including the Ruler) While it is good to try and conform to the Apple Interface, let us not forget that it too is not perfect, and must evolve. And unless you're willing to let Apple control the Interface guidelines completely, I say keep experimenting. When folks don't like the interface, they say so, and the author either lives with bad press or makes it better. --Mark Munz
mattd@Apple.COM (Matt Deatherage) (12/11/89)
In article <13980.chatter.infoapple@pro-beagle> mmunz@pro-beagle.cts.COM (Mark Munz) writes: > >Sorry, I just had to laugh. If you look over on the Macintosh side >of the world, you'll find that menus that are attached to Window Title >bars are quite common. (MicroSoft's Word has buttons and pull down >menus all over the place, including the Ruler) > Word's menus are this bizarre combination of pull-downs and pop-ups. The menu pulls down (or "pops down") from a fixed location, but it doesn't have a menu title - it pulls down from a box that contains the last selection, just like a pop-up's box contains. I find it weird. >While it is good to try and conform to the Apple Interface, let us >not forget that it too is not perfect, and must evolve. And unless >you're willing to let Apple control the Interface guidelines completely, >I say keep experimenting. When folks don't like the interface, they >say so, and the author either lives with bad press or makes it better. > >--Mark Munz Right. Apple can't possibly anticipate all the user interface needs unless Apple were writing all the software, which it's not. However, Apple does ask that if you have to do something really strange that you write in through AppleLink (DTS can help you find the right places) and *ask* for help so that you do what you do consistently with the rest of the desktop, and so that perhaps other programs can use the new mechanism in the future as part of the interface. For example, those who had to put up a modal dialog (requiring action before the program can proceed) but had to do so in a movable window so other parts of the desktop could be seen had a problem. Those who didn't ask for help made regular looking windows that couldn't be put behind other windows and in general didn't behave like a window should. Those who did ask for help got a new "movable modal dialog" definition, with a new Macintosh WDEF already available on AppleLink (we're working on the IIgs version). The interface is a living thing, and Apple's not the only one that can help it grow. Apple just referees and keeps the standards. -- ----------------------------------------------------------------------------- Matt Deatherage, Apple Computer, Inc. | "The opinions expressed in this tome Send PERSONAL mail ONLY (please) to: | should not be construed to imply that Amer. Online: Matt DTS | Apple Computer, Inc., or any of its ThisNet: mattd@apple.com | subsidiaries, in whole or in part, ThatNet: (stuff)!ames!apple!mattd | have any opinion on any subject." Other mail by request only, please. | "So there." -----------------------------------------------------------------------------
blochowi@rt5.cs.wisc.edu (Jason Blochowiak) (12/13/89)
In article <13980.chatter.infoapple@pro-beagle> mmunz@pro-beagle.cts.COM (Mark Munz) writes: > [ A whole lotta stuff that I deleted ] >I say keep experimenting. When folks don't like the interface, they >say so, and the author either lives with bad press or makes it better. What scares me is that the NDA in question is (I think) WriteIt! by Chris Haun (I think I got the name right, but no guarantees), who's the guy that's writing Design Master (which Byteworks says they're going to publish). If Design Master has the same level of professionality to the UI, I think that we're in trouble... WriteIt's primary merit is that it exists, and appears to be bug free. Btw, has anyone looked into his code enough to figure out how he handles loading/unloading TextEdit (and the support tools)? It would seem that he broke the "Golden NDA rule" into a few billion small pieces... >--Mark Munz -- Jason Blochowiak - blochowi@garfield.cs.wisc.edu or jason@madnix.uucp "Education, like neurosis, begins at home." - Milton R. Sapirstein
mmunz@pro-beagle.cts.COM (Mark Munz) (12/14/89)
In-Reply-To: message from mattd@Apple.COM >The interface is a living thing, and Apple's not the only one that can help >it grow. Apple just referees and keeps the standards. Most replies usually start with flames.. but I'd like to just say.. well put. Obviously, Apple doesn't mind us "playing" with interface ideas -- they just want to make sure we don't do something like: > Yes.. the ol' IBM prompt!! --Mark Munz
dlyons@Apple.COM (David A. Lyons) (12/15/89)
[somebody writes] >Unless there is a trick to make a pop-up menu look almost exactly like a >pulldown menu in an NDA, I personally would recommend against people >putting a pop-up in their info bar (with some exceptions). [...] >Maintain the 'look and feel' of the Apple Interface, it is there for >a reason. Mark Munz writes: >Sorry, I just had to laugh. If you look over on the Macintosh side >of the world, you'll find that menus that are attached to Window Title >bars are quite common. (MicroSoft's Word has buttons and pull down >menus all over the place, including the Ruler) Note that the original recommendation (attribution lost) was against putting POP-UP menus in info bars, not against regular pull-down menus. I agree--a "bar" of pop-ups would be weird & have no advantage over a bar of pull-downs. -- --David A. Lyons, Apple Computer, Inc. | DAL Systems Apple II Developer Technical Support | P.O. Box 875 America Online: Dave Lyons | Cupertino, CA 95015-0875 GEnie: D.LYONS2 or DAVE.LYONS CompuServe: 72177,3233 Internet/BITNET: dlyons@apple.com UUCP: ...!ames!apple!dlyons My opinions are my own, not Apple's.