cb29+@andrew.cmu.edu (Chad Kavanaugh Bisk) (03/19/90)
Folks, I have been using and administering a NeXT System (v1.0) for several months now and I thought I would share some of my findings with the net community. The NeXT I am using is not my own, and as I will be graduating soon, I am thinking of purchasing one. However, there are several things which stop me: --------------- Problems that keep me from buying one right now ------------- - 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. - 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. - 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). 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. - 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. - 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. For an example of this problem, move the Directory Browser near the top of the screen and hit a text key. The browser opens a name expansion window off the top of the screen and you can't move it to get to the close box. - An alert for one application should not necesarily obscure the windows of another application, since I could be using that other application to help with the first applications problem. Any given alert need only make sure it is not obscured by a window in it's Application group. - 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. - A three button mouse with a useful interaction policy is required. The default may be to have all buttons do the same thing, but there should be a preference option for: In text, left button sets the cursor, middle button brings up menus, and right button selectes region from cursor to current pointer postition. In title bars, its move window, push window to background, pop window to foreground. In resize bars, its resize, push, pop. In the background its Workspace menus, current selected application's menus, and a windows list menu that lets you select some window that's been buried under twelve other windows without moving all twelve windows around. There should be preferences for each of the previous possibilities. ---------------- Bugs ----------------- - 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. - Preferences doesn't reset the values of Speaker volume (left and right), Screen brightness, or Screen Dimming Delay to the right levels each time you log in. - In IB test mode, double clicking on the big test switch when another program has the focus and has its menus posted causes IB to post its menus without aquiring the focus. Thus there are now two sets of menus on screen and the other program still has the main focus. - Quotations has a bug in it in that when you have a /LocalLibrary/References that is an empty directory, in addition to the standard /NextLibrary/References, the program fails with a fatal error dialog box claiming it can't open /LocalLibrary/References/OxfordQuotations//.index/index. The correct behavior seems to be that it should just ignore this directory and use the /NextLibrary/References directory. Also, since the subdirectory OxfordQuotations didn't even exist in /LocalLibrary/References, the program shouldn't even have looked there in the first place. - The uudecode mail alias allows a user to place a file anywhere in the file system. - The version of Display PostScript shipped with v1.0 has several problems: - If you install your own fonts, and try to use them at sizes where bitmap fonts have been written for other fonts, DPS sometimes grabs the bitmap of the wrong font, instead of generating the new font at the same size. - 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. - It is very slow at generating text in a spiraling pattern. Is it trying to image the whole character set even though only one character will be needed at that particular angle? - Helvetica Medium on screen has trouble with spacing for certain characters. Consider, "heat-122" has no spaces in it even though it looks like it does. - The text insertion bar (hereafter referred to as the cursor) does not always look like it's in the right place. - /bin/file is buggy. It repeatedly seg faults on NeXT applications like /NextApps/Preview and many apps likely to be found in /LocalApps (Cassandra, NX_VOID, Tools, communicae). It also doesn't know much about NeXT file types like .snd .wn and so on. - Menu clicking, when enabled, on a floating icon does nothing instead of bringing up the menu. - WriteNow has trouble opening files owned by someone else (root) when the protection bits are -rw-r--r--, but it doesn't have trouble if its -r--r--r--. A dialog box complaining about not being able to lock the file comes up and asks you to either open a copy or abort. Since I can't write to the file anyway, it should just open it read-only with the same name, instead of opening a copy with the name Default-1. At least this should be the default option on the dialog box. - Sometimes, when I double click on an application, two of them start. I may be clicking once too many, but even a triple click should only start one instance of an application. - In the Librarian, if you bring up the seperate Find panel after searching for a man page and try to search for a word by entering a word (in the Find panel) and hitting Return, it won't accept further hits on return unless you click in the Find text field even though the Find panel's title bar is black and the Digital Librarian window's title bar is grey. Since the Find panel still has the major input focus and it has a button with a return symbol on it, it should accept subsequent returns. Either that, or the button should lose the return symbol after the first find to correctly reflect its true status. --------------------- Problems ---------------------- - Choosing help from Mail brings up a browser for the mail help topics. Unfortunately, it also brings any other windows being directly managed by the Workspace to the foreground, too. This is indicative of a larger problem. Applications that maintain multiple windows on behalf of other clients (e.g. the Browser being used by Mail as its help interface) should manage those windows in a seperate manner from it's own, windows. There should be the concept of a window's Application Group and operations on this Application Group, like ReceiveInputFocus() that apply to all windows in a group, regardless of ownership. - 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. - There is no documentation or man page for /bin/ws. - The Workspace Manager needs a "Full Screen Refresh" option. - The ~/Unix directory seems to be completely useless. Any files in ~/Unix could just as well go in ~/ since there is, as yet and hopefully in the future, no namespace collision. - When the Workspace browser has five columns and one's home directory is two levels deep (e.g. /usr/usr0/cb29), it places the listing of the home directory in the fourth column instead of the third column, thus knocking the root directory off the left side of the browser. The correct behavior should be to get as much of the tree as possible displayed while having a user settable, minimum number (default of one) of empty columns at the right for expanding into. - /usr/adm/sulog is not maintained. --------------------- Suggestions ------------------- - There should be a preference for how dim the screen gets when it dims. - There should also be a way to set these preferences for the login window (perhaps as root's preferences?). - 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. - One directional resizable windows should be supported. this would allow resizing width but not height, or vice versa. This could allow info panels that have srollable text regions to be expanded vertically without messing up their fixed width header areas (e.g. /NextDeveloper/Demos/Chess). This may already exist, but I haven't seen much use of it. - In Edit, there should be a preference for whether selected text should be replaced or added to by typing. This would be enhanced by an option to have the second button set the current region from the cursor to the pointer. Also it would be nice if there were a preference to have Ctrl-a and Ctrl-e go to the beginning and end of the selected region, if one exists. the differences here are more than style; writing needs a no replacement selection policy and editing needs a replacement selection policy. Also, double clicking on a word and typing its replacement is good, but triple click and type and you've lost your paragraph. Perhaps there should be a preference for max-selected-region-replacement. - In text, there should be a preference for whether triple clicking should select by line, sentence, or paragraph. Also, I don't think WriteNow even has triple clicking. - There should be two slider bars for controlling mouse reactivity. One would control the scaling curve and the other would control speedup. this would be in addition to the four buttons for default levels. Also, when changing the values in the preferences database by hand, there should be a way to have them read in immediately. - Menu clicking, if enabled, in the root window (the background) should bring up the Workspace menu. - When the "other" mouse button is set to bring up menus, there should be a way to disable root menus from appearing automatically. This would free up some valuable screen space. - The Edit application should indicate if you have unsaved changes. This can be very easily displayed in the title bar with some marking character, like an asterisk. Ideally, this would act like the gnu-emacs status indicator in the left side of the status bar. Perhaps most of the status bar could be replicated in the title bar. - The Edit application needs to support more of the Gnu Emacs cursor manipulation keys. - The Workspace Browser needs a button or two for going to commonly accessed directories, especially $HOME. Maybe an icon with a picture of a house on it could be used for $HOME. Maybe there could even be multiple Icon wells for placing directories you want to go to in. There is plenty of space in the rightmost column above and below the selected files icon well. This would be sort of like the Macintosh DA Boomerang. - This brings up the idea of having more than one icon well for selecting icons. This would greatly facilitate moving or copying by dragging in the following manner. You select your target directory, drag its icon into the "target" icon well, just below the "selected" icon well. Now you select one or more other files from another directory and drag the icon representing them onto the target directory icon which is sitting in the "target" icon well. Then you clear the well. - Alternatively, or maybe in addition, you could have a "holding" icon well that would just hold things until they are needed. This way you could select what you want to be moved, move it into the "holding" icon well, go back and select the target directory, and then drag the contents of the holding well onto the "selected" icon well which would now have the target directory's icon in it. - Disk space usage quotas need to be implemented for user directories. - Scripts should be provided for cleaning out files, on a one time only basis, that may grow unchecked (e.g. /usr/adm/messages). At least a list of files that one should consider pruning or removing when space gets tight could be provided. - The Icon Dock should be more functional: - There should be a preference for which corner it appears in. - There should be a preference for which way the dock flows, in reference to the NeXT Icon anchor. - There should be a preference for which way you can drag it. You might even want to allow draging along all four edges of the screen. - 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. This could be especially useful for editing in multi-window documents. Candidate key shortcuts would be select-next-window-in-application, and seelct-next-application. - 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. - The keyboard needs some way to incline itself further, like extensible feet. Do not use posts that you have to take off the keyboard to get it to set flat, like DEC keyboards have. Then you have to keep track of where the feet went. - In Interface Builder test mode, after hiding your test interface, double clicking on the test switch icon should only expose the interface, not exit test mode. This makes sure that your test interface handles expose events correctly. The quit menu entry is there to exit test mode, so the current behavior is redundant. - If you're wishy-washy, trying to access Command-Shift characters can leave the keyboard shift-locked unless you Shift-Command it (note the order). This happens if you Command-Shift-Shift-something because you couldn't find the key you were hunting for while you held down the Command-Shift. A better choice for AlphaLock would be LeftShift-RightShift or maybe Alternate-Shift or maybe even a user settable preference. - There should be a way to unplug the speaker in the monitor unit to allow installation in a public cluster without allowing noisesome disturbances. The headphone jack should still work. This could be done in software if there were a way to have a root settable preference lock the WindowServer into mute mode where the external speaker is off, but the headphones are still on. - There should be meta-key support for gnu-emacs under Terminal, preferably the Alternate key (not the Command key) as it doesn't generate the propper Alternate character set in Terminal anyway. - Terminal and Shell should be merged (and probably rewritten) into a new program that supports the features of both and implements a full VT100. - Scroll bars, Cut&Paste - Full vt100 or vt102 emulation - multiple sessions (as in Shell) - It would be nice if Terminal and Shell (or their replacement) gave feedback during resize or had some facility for reporting the current number of rows and cols completely visible in a given window. This is usefull for stty row and col setting over telnet in Terminal. - The "old-fashioned" Unix databases should be maintained so that programs like finger and last will work propperly, especially information about who's on console. - Scroll bars on text windows should indicate where the cursor is and the extent of any selections. The Andrew Toolkit (ATK) from CMU (which is on the X11R4 tape in the contrib section) has an excellent implementation of this. This can also be extrapolated to any scroll-view that has a cursor and/or selectable region. Also, applications with interesting marks or notes or alerts can mark the slider area with the approximate position of the item. Even page breaks could be indicated with this method, at the application's discretion. - 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. This is exactly what subdirectories were made for. What's wrong with /NeXT/Apps and /NeXT/Library, and so on. The same argument could be made for /LocalApps and /LocalLibrary (for which there should be an option to have them in /usr/local/Apps and /usr/local/Library or elsewhere). - There should be search paths (in the form of UNIX process environment variables as well as the defaults database) in the Workspace Manager for Apps and for Library items. The same could be useful to the WindowServer, especially for Fonts. In particular, the Workspace's search path for applications should be user modifiable. In genereal, any program or application that expects certain files to live in a certain directory or list of directories should have search paths (again, in the form of UNIX process environment variables as well as the defaults database). - 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. - 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. This would enhance the software base and enlarge the spread (and hopefully, use) of shareware software. There is certainly a decent volume (albeit of varying quality) of stuff available on the ARPA net alone. - The make supplement imake (or something better) should be included with and integrated in to the NeXT System. - More support and better integration for file types .wn .rtf .txt .ps .eps .tiff for viewing, editing, and interchanging. It would be nice if there were an editor/viewer for each of these and a translator that could translate each to each directly, as best as possible. Yes, this would require 2^n interfaces. For some (though maybe not all) it could be worth it. - Upgrades to better OD drives should be available. This will be a fast growing field where technology will double storage capacity and halve access time every two or three years, and NeXT owners should be able to keep up with this trend (provided their pockets are deep enough). The current system board seems to hinder this process as the control chips are on the mother board and not a seperate card. - A slot adapter card that allows current, Macintosh style (10 MHz) NuBus cards to be used, perhaps via the NeXT NuBus chip, with the NeXT system. This would be a stub card that would plug into one of the four slots in the back-plane and would have a slot adapter on the outside edge allowing a Mac NuBus card to plug right in. - The Delete key should be labeled as a Backspace key and send an actual backspace character. - The cut-copy-&-paste operations should act on a kill-ring that could hold more than one item at a time. - If a scroll bar is tall enough, it should place a second pair of up-down arrows at the other end of the scrollbar so you don't have to mouse all the way over to the other end and back. There should be prefences for how tall that limit is and whether it should happen at all (default no and half screen height). ------------------------------------------ Kudos --------------------------------------------- - The screen "looks nice". Kudos to the time put in to make each and every aspect of the interface incredibly visually pleasing. - /bin/ls takes advantage of extra columns. Kudos to getting this right. -- Chad K. Bisk -- cb29@andrew.cmu.edu -- NeXT Mail: cb29@peru.andrew.cmu.edu
robertl@bucsf.bu.edu (Robert La Ferla) (03/19/90)
Good suggestions. Here's more concerning Digital Webster: FEATURE SUGGESTIONS 1. Add foreign language dictionaries/thesaurus for French, Spanish, Italian and German. This would open up a whole new use for the NeXT. Are you listening NeXT? 2. An online Encyclopedia with pictures! This should really be a separate OD available for a nominal price. 3. More pictures please! Digital Webster is a good resource for clip-art but it needs more pictures. For instance, I was looking for pictures of primates (man/monkey/chimpanzee/gorilla) for which there should be pictures for and was surprised that there were none to be found. 4. An online Atlas. 5. Webster has pronounciations for every word. How about a voice synthesis or digitized pronounciation for every word? Maybe all of these suggestions could be bundled in an Educational OD. BUGS/PROBLEMS 1. Most of the TIFF files in /NextLibrary/References for the Webster pictures are in (what seems to be) an old TIFF format. Icon has problems opening them but Digital Webster doesn't. __ / \ / __/_ /___/ __ /_ __ __ / INTERNET: robertl%bucsf@bu-it.bu.edu / \ '_' /_/ |_- / ' / BITNET: mete0pc@buacca.bu.edu
jgreely@oz.cis.ohio-state.edu (J Greely) (03/19/90)
In article <Qa110ba00VRhM0dF16@andrew.cmu.edu> 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. <snicker> 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)
lacsap@mit-amt.MEDIA.MIT.EDU (Pascal Chesnais) (03/20/90)
Lighthouse Design has put together a compilation disk of freely distributable software. Their table of contents is extensive, and includes X server for the NeXT. MIT's Project Athena has no plans that I know of to go into the OD distribution business, nor have I heard any plans from the X consortium front about including the XNeXT stuff. There is no fixed plans that I know of about a future XNeXT release in the immediate future. A quick three button comment for XNeXT you can enable the second button in Preferences, and then when you need the third button (like for the xterm paste) press *both* buttons at once.... It usually works, most of the time. pasc -- Pascal Chesnais, Research Specialist, Electronic Publishing Group Media Laboratory, E15-348, 20 Ames Street, Cambridge, Ma, 02139 (617) 253-0311 email: lacsap@plethora.media.mit.edu (NeXT)
jacob@gore.com (Jacob Gore) (03/20/90)
/ comp.sys.next / cb29+@andrew.cmu.edu (Chad Kavanaugh Bisk) / Mar 18, 1990 / > - The Delete key should be labeled as a Backspace key and send an > actual backspace character. No way. Both VT100 and Emacs use Delete (ASCII 127) as the rubout character. The Text object, by default, uses Delete to delete selected text. Jacob -- Jacob Gore Jacob@Gore.Com boulder!gore!jacob
rees@dabo.ifs.umich.edu (Jim Rees) (03/20/90)
You forgot to mention that they misspelled "Philippines" in the introduction chapter of on-line Webster.
mark@Jhereg.Minnetech.MN.ORG (Mark H. Colburn) (03/20/90)
In article <JGREELY.90Mar19022202@oz.cis.ohio-state.edu> J Greely <jgreely@cis.ohio-state.edu> writes: >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). Something an awful lot like this has already been designed and developed by a computer manufacturer. It's very interesting and shows a level of forethought which is not very common among computer vendors these days. The current implementation is useable and flexible and rather unique. If you think about it, it rather solves a number of problems which haved faced the GUI marketplace of late. -- Mark H. Colburn If you don't make money off of it, Open Systems Architects, Inc. it had better be either a religious mark@Minnetech.MN.ORG experience or a hobby. - Lance Cooper
kevin@cunixf.cc.columbia.edu (Kevin Harris) (03/21/90)
In article <ROBERTL.90Mar19005309@bucsf.bu.edu> robertl@bucsf.bu.edu (Robert La Ferla) writes: >Good suggestions. Here's more concerning Digital Webster: > >FEATURE SUGGESTIONS > >1. Add foreign language dictionaries/thesaurus for French, Spanish, >Italian and German. This would open up a whole new use for the NeXT. Are >you listening NeXT? > [2-4 deleted for space reasons only.] >5. Webster has pronounciations for every word. How about a voice >synthesis or digitized pronounciation for every word? Wow, what is you combined the above two ideas and made a "talking textbook" for foreign languages? Might take up some room when you get into conversation, but it seems feasable. |Kevin A. Harris - or - kevin@cunixf.cc.columbia.edu | |119th & Broadway; Rm. 212 "Hardware: The parts of a computer system | |New York, N.Y. 10027 that can be kicked." |
cyliao@eng.umd.edu (Chun-Yao Liao) (03/23/90)
In article <ROBERTL.90Mar19005309@bucsf.bu.edu> robertl@bucsf.bu.edu (Robert La Ferla) writes: >Good suggestions. Here's more concerning Digital Webster: > >FEATURE SUGGESTIONS > [all suggestions deleted, please refer to original post] I am 99.44% agree with all the suggestin Robert described in his earlier article. The rest .56% may be that I might have more suggestions, but are not in my mind right now. -- |I want Rocket Chip 10 MHz, Z-Ram Ultra II, UniDisk 3.5 | cyliao@wam.umd.edu | |I want my own NeXT, 50MHz 68040, 64Mb RAM, 660Mb SCSI, | Chun Yao Liao | | NeXT laser printer, net connection. | Accepting Donations!| /* If (my_.signature =~ yours) coincidence = true; else ignore_this = true; */