mystone@caen.engin.umich.edu (Dean Yu) (03/05/89)
As I'm sitting here staring at the small icon in the upper right hand corner of the screen, I'm thinking it looks really scrunched, and a better job could probably be done. So here's my suggestion for spiffing it up in future releases of MultiFinder. As far as I can tell, MultiFinder puts that icon in the menubar by just taking the application's ICN#, and plotting it to a reduced rectangle. Since it has to find this icon through the BNDL resource anyway, it'd be almost no effort at all for developers to put an sicn resource into the BNDL. MultiFinder can then plot this small icon in the menubar instead of a compacted version of the full sized icon. This way, developers can design their own icons that show that their application is running under MultiFinder, and people, or rather, *I* don't have to look at this ugly thing in the corner of my screen... So whadya think? Phil? Erich? ______________________________________________________________________________ Dean Yu | E-mail: mystone@caen.engin.umich.edu University of Michigan | Real-mail: Dean Yu Computer Aided Engineering Network | 2413 Kelsey House ===================================| 600 E Madison "These are MY opinions." (My | Ann Arbor, MI 48109 employer doesn't want them. |========================================== Actually, they don't really care | what I think. But President | This space intentionally left blank. Duderstadt does...) | ------------------------------------------------------------------------------
goldman@apple.com (Phil Goldman) (03/06/89)
In article <41d593be.14e0d@robocop.engin.umich.edu> mystone@caen.engin.umich.edu (Dean Yu) writes: > As I'm sitting here staring at the small icon in the upper right hand > corner of the screen, I'm thinking it looks really scrunched, and a better > job could probably be done. So here's my suggestion for spiffing it up in > future releases of MultiFinder. > As far as I can tell, MultiFinder puts that icon in the menubar by just > taking the application's ICN#, and plotting it to a reduced rectangle. Since > it has to find this icon through the BNDL resource anyway, it'd be almost > no effort at all for developers to put an sicn resource into the BNDL. > MultiFinder can then plot this small icon in the menubar instead of a > compacted version of the full sized icon. This way, developers can design > their own icons that show that their application is running under MultiFinder, > and people, or rather, *I* don't have to look at this ugly thing in the corner > of my screen... > So whadya think? Phil? Erich? I think this is a wonderful idea. The one (minor) problem is simply agreeing on an id policy that the Finder will also use. The more difficult case is how to handle color icons, if at all. In any case, I think you will see at least small icon support in the next version of MF. If you can't wait, I believe there is an INIT called Aesthete (or something similar) by David Dunham that will accomplish the same. -Phil Goldman Apple Computer
amanda@lts.UUCP (Amanda Walker) (03/07/89)
Speaking of bundles, it would also not be very hard to put in 'cicn' bundles into applications, and have the finder use them. cicns even have masks & b/w versions, so they are a complete superset of ICN#s... -- Amanda Walker, InterCon Systems Corporation amanda@lts.UUCP / ...!uunet!lts!amanda / 703.435.8170 -- Those whom the gods would destroy they first teach COBOL.
dent@unocss.UUCP (Dave Caplinger) (03/07/89)
From article <41d593be.14e0d@robocop.engin.umich.edu>, by mystone@caen.engin.umich.edu (Dean Yu): > ... > and people, or rather, *I* don't have to look at this ugly thing in the corner > of my screen... > So whadya think? Phil? Erich? > Better still, why not do away with the ugly thing altogether, and put the menubars for seperate applications in the windows themselves, scrollable in a way similar to the recently posted MenuScroll INIT...? Maybe I shouldn't bring this up again. :-) Naw, what the hell. Can anyone think of any reason (that cannot be worked around in a satisfactory manner) for not doing this type of thing to replace MultiFinder? If you've seen DECwindows, you probably know what I'm talking about... if not, I mean replacing the "Switcher-style" method of changing the menu bar from context to context, and putting the menubars of applications in the application's main window (or perhaps better yet, give each application their own "virtual screen" in which they can place their "pallete" windows wherever they like. Thus, Finder doesn't have to figure out which window is the "main" one, but simply gives them a whole (virtual) screen to them- selves. Then, you don't have to worry about overlapping the pallete windows, and "hiding" the whole set is easy since it's only one real window on the desktop instead of more than one (as it is currently in MultiFinder).) Perhaps I'm not making too much sense... Ah well, flame away then.. -/ Dave Caplinger /------------------+----------------------------------- Microcomputer Specialist | Internet: unocc07@zeus.unl.edu "Computing and Data Communications" | UUCP: uunet!btni!unocss!dent University of Nebraska at Omaha | Bitnet: UNOCC07@UNOMA1 Omaha, NE 68182 | or dc3a+@andrew.cmu.edu
kent@lloyd.camex.uucp (Kent Borg) (03/21/89)
In article <700@unocss.UUCP> dent@unocss.UUCP (Dave Caplinger) writes: >Better still, why not do away with the ugly thing altogether, and put the >menubars for seperate applications in the windows themselves, scrollable >in a way similar to the recently posted MenuScroll INIT...? I don't know what MenuScroll INIT does (we don't get binaries here, someone send me a copy :-), but I have been watching some new Macintosh users trying to master a fairly new Macintosh II here at work. I also watch new Macintosh users at The Boston Computer Society's Resource Center. I start to see some of the problems with the current Macintosh user interface. MultiFinder might be one of the best kludges ever written, but the user interface isn't what it should be. Users will close their window, appreciate the warning about saving their document, see their floppy on the desktop, eject it, and walk away. Makes perfect sense. The problem is that the application is still running, taking up memory, and the floppy holding the application is now `off line', but still mounted and sitting on the desktop. The problem is that users want to open and close *documents*. They will sometimes consent to opening an application when they want to start a new document, but they would otherwise rather not worry about the detail of whether an application is running or not. Why should they? MultiFinder already allows users to double click a document for an application which is already running. The concept of running an application is already obscure, why not obscure it the last amount? Why this pedantic distinction between putting an application on disk and having it in RAM? How many Macintosh users even know what RAM stands for or why (after all, ROM is just as Random Access)? As we head toward interprocess communication--Macintosh-style, where the *user* decides who talks to whom and the *user* mixes and matches features--applications will begin to lose their importance. The user will think in terms of the data and what can be done to it. The silly idea of only doing things from within a single application will start to disappear. Hot links will make the clipboard look terribly old fashioned and quaint. As for menus at the top of windows, I think I like them and I think Apple agrees. Have you seen the Knowlege Navigator video? Did you see the second, less futuristic companion? It had colored menu bars at the top of the windows on a very large CRT. Kinda like McSink or big QuicKeys windows. Seemed significant to me... Kent Borg kent@lloyd.uucp or ...!hscfvax!lloyd!kent
jimc@iscuva.ISCS.COM (Jim Cathey) (03/29/89)
In article <347@lloyd.camex.uucp> kent@lloyd.UUCP (Kent Borg) writes: >In article <700@unocss.UUCP> dent@unocss.UUCP (Dave Caplinger) writes: >>Better still, why not do away with the ugly thing altogether, and put the >>menubars for seperate applications in the windows themselves, scrollable >>in a way similar to the recently posted MenuScroll INIT...? >As for menus at the top of windows, I think I like them and I think >Apple agrees. Have you seen the Knowlege Navigator video? Did you I _REALLY LIKE_ menus at the top of the screen. I can just 'throw' the mouse up and rest assured in the knowledge that the mouse won't overshoot the menus. A simple fine-tuning gets me to the menu I want. Menu items are wide, but not very tall. Homing in on them vertically would be a real pain. Homing in horizontally has never been a problem. Just an opposing opinion. +----------------+ ! II CCCCCC ! Jim Cathey ! II SSSSCC ! ISC Systems Corp. ! II CC ! TAF-C8; Spokane, WA 99220 ! IISSSS CC ! UUCP: uunet!iscuva!jimc ! II CCCCCC ! (509) 927-5757 +----------------+ "With excitement like this, who is needing enemas?"
jerryg@apple.com (Jerry Godes) (03/30/89)
In article <2430@iscuva.ISCS.COM> jimc@iscuva.ISCS.COM (Jim Cathey) writes: > I _REALLY LIKE_ menus at the top of the screen. I can just 'throw' the mouse > up and rest assured in the knowledge that the mouse won't overshoot the menus. > A simple fine-tuning gets me to the menu I want. Menu items are wide, but not > very tall. Homing in on them vertically would be a real pain. Homing in > horizontally has never been a problem. I agree with you here. You always want to have the menubar in a well defined location, and the top of the screen makes it easier to home in vertically. However, I also like the idea of windows having menus as well. This really comes in handy with big monitors or multiple monitors where moving to the menu bar is very disruptive because of the distance you need to move the mouse. This is really the same reason why I like tear off menus that allow you to put the menu close to the area you are working in. Jerry Godes jerryg@apple.com Communications Product Development Standard Disclaimer: These thoughts are original, no one else knows I have them. In taberna quando sumus, non curamus quid sit humus, sed ad ludum properamus, cui semper insudamus. Carmina Burana - Carl Orff
jtw@wuee1.wustl.edu (Trent Wohlschlaeger) (04/02/89)
In article <2430@iscuva.ISCS.COM> jimc@iscuva.ISCS.COM (Jim Cathey) writes: >In article <347@lloyd.camex.uucp> kent@lloyd.UUCP (Kent Borg) writes: >>In article <700@unocss.UUCP> dent@unocss.UUCP (Dave Caplinger) writes: >>>Better still, why not do away with the ugly thing altogether, and put the >>>menubars for seperate applications in the windows themselves, scrollable >>>in a way similar to the recently posted MenuScroll INIT...? >>As for menus at the top of windows, I think I like them and I think >>Apple agrees. Have you seen the Knowlege Navigator video? Did you >I _REALLY LIKE_ menus at the top of the screen. I can just 'throw' the mouse >up and rest assured in the knowledge that the mouse won't overshoot the menus. >Just an opposing opinion. Another opposing opinion: This is not a BAD idea, if your application has a MAIN window. I consulted on an application for which this was not the case. If the application doesn't have a MAIN window, who decides which window gets the menubar? The programmer? The user? What if the menubar is on an inactive window? More activateWindow glue? Move the menu to the active window? I hope not. This would seem to me to be most confusing. I guess I just don't feel that this is a workable concept for applications with multiple windows. Trent
ra_robert@gsbacd.uchicago.edu (04/15/89)
In article <171@wuee1.wustl.edu>, jtw@wuee1.wustl.edu (Trent Wohlschlaeger) writes... [stuff from other folks about putting menu bars in windows] >Another opposing opinion: > >This is not a BAD idea, if your application has a MAIN window. >I consulted on an application for which this was not the case. > >If the application doesn't have a MAIN window, >who decides which window gets the menubar? The programmer? The user? >What if the menubar is on an inactive window? More activateWindow glue? >Move the menu to the active window? I hope not. >This would seem to me to be most confusing. > >I guess I just don't feel that this is a workable concept >for applications with multiple windows. I heartily agree. One other problem with having menu bars in windows themselves is that windows are resizable. What if you need to access a menu in a slightly (or very much) shrunken window? Do you have to first enlarge the window so that you can access the menu? What a pain. I guess one could somehow have scrolling menubars, but that doesn't seem such a great idea. As an example: people are complaining at times that there isn't enough room on the _screen_ for all their menus in MPW. If menus were moved to windows, it would be that much more cramped. I think we need to see some better solution for menus in general, but putting them in the windows themselves is probably not the answer. Robert ------ ra_robert@gsbacd.uchicago.edu ------ generic disclaimer: all my opinions are mine
tom@iconsys.UUCP (Tom Kimpton) (04/21/89)
In article <2725@tank.uchicago.edu> ra_robert@gsbacd.uchicago.edu writes: >In article <171@wuee1.wustl.edu>, jtw@wuee1.wustl.edu (Trent Wohlschlaeger) writes... > >[stuff from other folks about putting menu bars in windows] > >>[more stuff about putting menu bars in windows] >>If the application doesn't have a MAIN window, >>who decides which window gets the menubar? The programmer? The user? >>What if the menubar is on an inactive window? More activateWindow glue? >>Move the menu to the active window? I hope not. > >I heartily agree. > >One other problem with having menu bars in windows themselves is that windows >are resizable. What if you need to access a menu in a slightly (or very much) >shrunken window? Do you have to first enlarge the window so that you can >access the menu? What a pain. I guess one could somehow have scrolling >menubars, but that doesn't seem such a great idea. > How about if when the mouse is in the area of the menu-bar of a window (no matter how shrunken) the entire menu-bar "pops" up. Then have a slop rectangle around the menu-bar to keep it "open" until you leave that rectangle. Thus if you have your window shrunk down to say one inch square, moving into the top mBarHeight of that window would "pop" up the menu-bar. Perhaps you could have it user configurable as to slop-rect size, and maybe only "pop" up if a modifier key is down. n e w s f o d d e r -- Tom Kimpton UUCP: {uunet,caeco,nrc-ut}!iconsys!tom Software Development Engineer ARPANET: icon%byuadam.bitnet@cunyvm.cuny.edu Icon International, Inc. BITNET: icon%byuadam.bitnet (multi-user acct) Orem, Utah 84058 PHONE: (801) 225-6888
johnmark@Neon.Stanford.EDU (John M. Agosta) (09/01/89)
duggie@Jessica.stanford.edu (Doug Felt) writes: > I believe Object Pascal restricts assignments in one direction but not > the other. I am not sure but I think the assignment is a runtime > restriction, in that code is generated to check the class of the > object being assigned and test this against the class of the variable. Yes, in MacApp beta9 the assignment coercion is checked by code at runtime. This appears to be different than previous versions, coercions that I ported over to beta9 now break into the debugger with a coercion error message. Apparently the debug versions of MacApp applications do significant amount of runtime checking of a host of errors that were not examined before. -johnmark
lsr@Apple.COM (Larry Rosenstein) (09/02/89)
In article <11615@polya.Stanford.EDU> johnmark@Neon.Stanford.EDU (John M. Agosta) writes: > duggie@Jessica.stanford.edu (Doug Felt) writes: > > > > I believe Object Pascal restricts assignments in one direction but not > > the other. I am not sure but I think the assignment is a runtime > > restriction, in that code is generated to check the class of the > > Yes, in MacApp beta9 the assignment coercion is checked by code at > runtime. This appears to be different than previous versions, > coercions that I ported over to beta9 now break into the debugger Object Pascal has always signalled a compile-time error if you try to assign a variable of one class to a variable of a subclass. Such an assignment might not be valid because the object being assigned might not be compatible with the target type. The way to avoid the error is to coerce the object to the target type (or a subclass of the target type). In Object Pascal, the coercion has always generated a run-time check to ensure that it was valid. (This code is generated only when range-checking is enabled in the compiler, so extra code isn't present in final versions of a program.) What I believe has changed in the latest version of MacApp, is that it does more checking to ensure that the objects you are dealing with are valid objects and not uninitialized variables, freed objects, etc. (This is the "object discipline" feature.) What could be happening is that you are trying to coerce a NIL (or freed) object and MacApp is complaining, where it didn't before. I would be interested in finding out what the exact circumstances were. Larry Rosenstein, Apple Computer, Inc. Object Specialist Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1