Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!oz.cis.ohio-state.edu!jgreely From: jgreely@oz.cis.ohio-state.edu (J Greely) Newsgroups: comp.sys.next Subject: Re: Problems with the NeXT System (v1.0) Message-ID: Date: 19 Mar 90 07:22:02 GMT References: Sender: news@tut.cis.ohio-state.edu Reply-To: J Greely Organization: Ohio State University Computer and Information Science Lines: 240 In-reply-to: cb29+@andrew.cmu.edu's message of 18 Mar 90 22:48:07 GMT In article cb29+@andrew.cmu.edu (Chad Kavanaugh Bisk) writes: [all sorts of things, some of which should be familiar to old hands] >- In its present incarnation, the NextStep Window Manager has several >problems: > - There should be a way to give the focus to a window that isn't on >top of all the other windows. This used to exist, and I was disappointed to find it gone in 1.0. > - It needs some way to change window layer ordering (as in X CircleUp >& CircleDown, esp. as implemented in OSF/Motif mwm). At the very least >there must be a way to push a window to the background. I'm still on the "not really interested" side of this issue. The combination of a large screen and the dock gets rid of most uses I'd have for this feature. > - There should be a preference for focus-follows-click (the current >setting) vs. focus-follows-click-or-type (whenever the user clicks or >types the window under the mouse acquires the focus, this is really the >best of both worlds, here) vs. focus-follows-cursor (the traditional X >focus policy) vs. focus-follows-cursor-last-window (just for >kitchen-sink completeness). "Wabbit season!" "Duck season!" This is one where there's never going to be a consensus. I agree with giving users the ability to choose what's most comfortable, but I also recognize that NeXT chose the style that would be most familiar to their audience. My biggest gripe with the NeXT implementation of click-to-type is what happens when you close the active application: nothing. > The problem with just focus-follows click is, for example, in >WriteNow if you click on an unfocussed document in the scroll-bar >region the document will jump to that point as well as acquiring the >input focus. This behavior is very annoying. Annoying, yes, but that's an implementation detail, not a problem with the model. It also seems to be a matter of taste in the current software release. > - There should be a user settable preference for having resize bars on >all four sides of resizable windows (like OSF/Motif mwm resize borders), >and how thick that border should be. I have a feeling that what you *really* want is a completely customizable window system, that starts out looking like it does now, but can be easily (and automatically) tweaked into Motif or a Mac, or anything else the users' fertile minds can think of. I don't think this will come out of a computer manufacturer (not usefully, anyway). > - You should be able to move the window from all four borders, and >maybe even the interior. Otherwise, windows that are created halfway >off the top of the screen can't be moved from where they are originally >placed. Wrong solution to the problem (or, wrong problem for the solution). The way to fix this is to not create windows (and menus) with the useful parts off-screen, which is a place where the current release falls down. >- There should be an option for the default choice in the logout >verification dialog box. There should also be a preference as to >whether the Workspace should even ask for confirmation of logout. Yes, this is a problem, particularly since they changed the default once already (although for a good reason). >- A three button mouse with a useful interaction policy is required. *Required*? I'm not sure I can agree with a statement that strong. Damn useful in certain circumstances, sure, but required? I agree that many applications could make effective use of it, and any advanced users could have a blast, but why should the naive user be presented with them? Personally, I'd like to see real support for *two* buttons. We'll worry about three when they start making effective use of the two they already supply. >- In the login window, there is no way to erase a mis-typed entry in >the password field and start over again. Ctrl-u in the login window >doesn't erase the string entered so far. I think I'd call this one a quibble, not a bug. Delete does the right thing, and Control-U is hardly an intuitive GUI kind of key for "erase current line". >- The uudecode mail alias allows a user to place a file anywhere in the >file system. Doesn't this run setuid uucp, which doesn't quite let it write _anywhere_? Regardless, this should have been stamped out of Unix distributions a long time ago. >- The version of Display PostScript shipped with v1.0 has several problems: > - DPS's generation of fonts is less than optimal, especially at small >sizes. Even at large sizes (128 pt.), diagonal strokes have terrible >jaggies. Adobe's product for the Macintosh (ATM) does a much better job >at this. Well-known problem, which they're improving with every release. ATM is a newer product, and probably owes a great deal of its quality to lessons learned on the NeXT. I would be surprised if 2.0 didn't have much better font handling. >- Menu clicking, when enabled, on a floating icon does nothing instead >of bringing up the menu. I'm having trouble deciphering that one. I think you need to clarify this point (at least to me). >- Each Terminal or Shell thinks it is a seperate login session and >sources .login and .logout. This behavior is incorrect. If need be, a >.Terminal.in and .Terminal.out file could be created for equivalent >functionality, but they should not be login shells. Unfortunately, they *are* login shells, and have to be if normal user configurations are going to work. A better way to accomplish what you want is to make the window system parse a file of environment variables on login, which would make it unnecessary to source .login (for csh users; folks using sh, ksh, or bash can replace .login with their favorite file name). >- There should be a preference for how dim the screen gets when it dims. Yup. Dividing by four is bogus. >- At the option of the application, there should be a zoom button in >the title bar that toggles between normal and full screen size windows. >This would require resizablility. Given the screen size, I don't think that's such a good idea. I recently worked on a Macintosh with a 19 inch screen, and one application had a tendency to want to zoom its windows. Damned annoying to have a 19 inch window that was mostly wasted space. >- In Edit, there should be a preference for whether selected text >should be replaced or added to by typing. Whuffo? It sounds like you want a selected region to act like a large cursor, and I don't see why. >- The Edit application needs to support more of the Gnu Emacs cursor >manipulation keys. I'd rather see emacs get NeXTStep support, but "different squids...". >- Disk space usage quotas need to be implemented for user directories. When did they break the standard Berkeley quota system? I hadn't heard about that one. Of course, it doesn't work for NFS, but what does? >- Scripts should be provided for cleaning out files, on a one time only >basis, that may grow unchecked (e.g. /usr/adm/messages). Funny, I thought those were already installed. Not for every log file, but certainly for the important ones. >- The Icon Dock should be more functional: One can always hope. >- The NextStep Window Manager needs keyboard shortcuts for window >manipulation. This would be for power users who could then do >everything right from the keyboard. I think this one should be generalized to "more support for power users, period". >- The non-integrated front end version of Objective-C should be >included so that we can use it with other C compilers and future >versions of gcc. Supposedly, the ObjC code is to be released to the FSF, to be merged into the GNU distribution at the next convenient point. >- The keyboard needs some way to incline itself further, like >extensible feet. Anyone else use the monitor rollers as a makeshift support for the keyboard? If they weren't there, I'd have to glue rubber feet to the keyboard to get a useful angle out of it. >- There should be a way to unplug the speaker in the monitor unit to >allow installation in a public cluster without allowing noisesome >disturbances. Preferably in software, since I still want to hear beeps from shell applications. >- Terminal and Shell should be merged (and probably rewritten) into a >new program that supports the features of both and implements a full >VT100. This apparently fell low on the priority list while getting 1.0 out the door. I haven't heard what its current status is. >- The directory structure, while it has been improved in many ways, has >been mangled in others. Take, for example, /NextApps, /NextLibrary, >/NextAdmin and so on. You should have seen how it *used* to be! Just be glad they put most things back to normal for 0.9. >- The X window system (if/when v1.0 or later is released) should be >distributed with the NeXT System. At least information on where and how >to get it should be included in the documentation set. Including it is (almost certainly) out of the question, given the space constraints of fitting a release onto an OD. As for mentioning it, well: "if you don't like *our* window system, try brand X". Explaining how to get it is also difficult, unless MIT starts shipping ODs. >- NeXT should make available an optical disk full of public domain, >freeware, demonstration, and shareware that it could distribute (for the >price of OD, production, and handling) as a library. Why should *NeXT* do this? Sure, someone should do something like this, and get a mention in the third-party/developer's book that NeXT sends out. I don't think that NeXT should devote their time to it; I'd rather see them work on finishing their machine. >- The make supplement imake (or something better) should be included >with and integrated in to the NeXT System. GNU make would be a better choice, since they already supply Emacs. >- The Delete key should be labeled as a Backspace key and send an >actual backspace character. Huh? Where will you move the delete key to? And why backspace, when nothing uses it? -- J Greely (jgreely@cis.ohio-state.edu; osu-cis!jgreely)