sho@gibbs.physics.purdue.edu (Sho Kuwamoto) (05/20/91)
I like the way the title bar gets grayed out on color systems for windows which aren't foremost. I'd like it better if the content region would behave the same way for windows belonging to background applications. It might be difficult to do (current contents would probably be grayed automatically for speed, subsequent updates would have to be munged to gray everything that's drawn) but it would emphasize the differences between layers. It could be argued that we should de-emphasize the differences between programs. A window is a window, and we can cut and paste between them. However, I find that novices can have trouble figuring out which program is running. I teach a class in a room full of macs, and my students get confused when an application has no open windows. They sometimes forget to quit the application. Even worse, they later try to run the program by double-clicking, and find that no window appears. They see the Finder window on top, and think that nothing's happened. Worse yet, our programs are set to multi-launch, so the application icon doesn't gray out when the program is running. They double click, the zoomrect zooms out, it zooms back in, and they think something's wrong. A better solution might be to send a new appleEvent to programs which are double-clicked. Come to think of it, I suppose we could even re-use 'oapp'. The required behavior would be to open a new blank window if there are no open documents. This way, double-clicking an application would have the same behavior whether or not the program was currently running. A blank document would be created if appropriate. You could still switch to the program without opening a new document by using the application menu. It's not what we're used to, but it seems to me much more consistent. Opinions? -Sho -- sho@physics.purdue.edu
gilbertd@cricket.bio.indiana.edu (Don Gilbert) (05/20/91)
In article <5134@dirac.physics.purdue.edu> sho@gibbs.physics.purdue.edu (Sho Kuwamoto) writes: ... >They sometimes forget to quit the application. Even worse, they later >try to run the program by double-clicking, and find that no window >appears. They see the Finder window on top, and think that nothing's >happened. Worse yet, our programs are set to multi-launch, so the ... I agree complete with this problem of no windows on frontmost applications being very confusing to novices (even experienced users at times). I have started putting a routine in all my programs that puts a small, pretty "about" window up when my app is frontmost, if no document windows are open. I'd recommend such as a Human Interface addition to all developers. Don -- Don Gilbert gilbert@bio.indiana.edu biocomputing office, biology dept., indiana univ., bloomington, in 47405