Article Title : why.NCDwm Creation Date : unknown Author : ERW, NCD Technical Support Last Update : November 11, 1992 Last Update By : ERW, NCD Technical Support Expiration Rules : none ============================================================================= Why We Did NCDwm Last summer, Engineering, Marketing, representatives from Sales and Administration looked at how we should go about providing a local window manager. After surveying our customer base and the market, we decided on the Motif look and feel. This gave us two options: 1. Port mwm into the terminal. 2. Write our own NCDwm. In making our decision, we make a list of the pros and cons of each approach: 1. Mwm in the terminal + It would have the "Motif" label, which would make it easier to sell. + It would have most of the same features as mwm on the host (you still have to have something equivalent to a launcher to do root menus). + User's resources would work the same. - It would require 1-2 additional megabytes of memory. - Motif is still unstable. People are still finding bugs and the workstation vendors have large staffs devoted to supporting Motif. - Motif and the Xt toolkit on which it is based do not handle out of memory very well. Although this is getting better, it is still a substantial problem that will never go away. - Porting Motif would have taken a lot longer than writing our own version. Time to market was viewed as a major concern. - It would be just as bad as mwm on the host. We'd have to do a fair amount of work anyway to make it look nice on our monochrome products, even with the defaults that Mike Harrigan and co. came up with. But, the act of making it suitable for our customers means that it's no longer "standard" motif.... - We would have to pay royalties (at the time, $40 per unit) to OSF. - Most of the people who would be interested in the local window manager wouldn't be using many of the features of mwm. But, they'd have to pay for them anyway. - Even folks at OSF have said that mwm needs to go on a diet. 2. NCDwm + It would *not* require any additional memory. + It would be available in 2.3 instead of 3.0. This was viewed as a tremendous competitive advantage. + It would be more robust. + It would be faster than mwm. + We could tailor the window manager to make our products look sharp. + We could design the window manager with direct customer feedback on which features they actually wanted. Furthermore, we could make changes as they were requested. - Sales would have to work harder. - Porting local-clients would be a little harder. - We would still need a launcher mechanism for root menus. We're now hearing folks saying "nobody would mind putting in another 1-2 meg of memory; it's only $45-90." However, the primary feedback that Marketing received from its surveys said that memory consumption was a major issue. Customers with 1000 units were not excited by the idea of spending $50,000 to $100,000 just to have the option of using the local window manager. On products that already have the maximum memory installed, all memory used by the local window manager or terminal emulator is memory that can't be used by real applications. More important is the issue of reliability. NCD has made it's reputation as a company that puts quality first. We know that NCDwm is robust; feedback from our customers (which has been actively incorporated from the very beginning) has been extremely positive. We cannot say the same about mwm; we've heard more complaints about mwm than about any other window manager. Although less of an issue, NCDwm is noticably faster than mwm. This is more of an advantage on our low-end products where other window managers can seem sluggish. Similarly, our color support (particularly beginning with 2.4) is more carefully tuned than is Motif, so our user interfaces will be more appealing, and therefore more productive. It is important to keep in mind that the ergonomics of our software is just as important as that of our hardware. On the issue of root menus, until we have an authentication system like Secure RPC or Kerberos in the terminal *and on the host*, there will always have to be a host-side program for executing commands from the root menus. If the competition is using "rsh" (or a VMS equivalent) from the terminal, hit them hard because they are making the customer vulnerable to a large security hole (i.e. anyone could then run a command on their account). Furthermore, remind them that security has been and will always be a major concern at NCD. Since host-side launchers are a problem, we will further reduce the size of the "ncdlauncher" program in 3.0 by moving the menu code into the terminal. The host side will no longer have Motif or Athena widgets or the NCD user interface toolkit built into it. Instead, it will parse the .launchrc file, send a description of the menus to the terminal, and wait for instructions as to which commands to execute for the user. It has been recognized from the beginning that some of our competitors will attempt to criticize us for not using "real" Motif. Fortunately, the issues that they raise are typically smoke, and we have faith that you will be able to dispel them and show the customer that we are truly trying to solve their problems rather than lumping pieces together without regard to how they fit together. In making the decision to start with our own window manager, we recognized that we might need to augment our strategy some day once Motif becomes mature. But, until that time comes, we believe that the approach that we have taken of working *with* our customers to solve their needs in a timely manner has been the best course for them and for NCD.