wcs) (07/25/89)
In article <1143@ssp15.idca.tds.philips.nl> jos@idca.tds.PHILIPS.nl (Jos Vos) writes: = In article <228@psgdc> rg@psgdc.UUCP (Dick Gill) writes: = >..... Of course, noone should expect that the Unix [WordPerfect] = >implementation will deliver the same responsiveness, color and .. = Why not? The reason can't be that no fast UNIX workstations = with enough color-graphics capabilities exist........ = Anyway, WP is one of the first succesfull PC packages that has made = the step to UNIX. Congratulations. Who follows? A year ago, a project I was on was evaluating UNIX wordprocessors that also ran on DOS. WordPerfect was being done at the time (may have been betas?), a garage-shop made Arrow which was really nice and came from the UNIX side first, and there was Samna, which I tried out personally. I'm going to comment about Samna's implementation and use that to make some general comments about why it may be easier to do a good editor on a PC than on terminals. [ Disclaimer: You've heard disclaimers before. This is one of them. ] Samna *reeked*. Some of its problems were because it was their first UNIX implementation, and may be fixed by now, but some were just inherent. A critical problem is that Samna is an old editor, and the original implementations were made to fit on small PCs, with overlays and stuff that us old-timers remember doing on PDP-11s, and to adapt to the modern world (or even the semi-modern 640K) would be a major re-implementation for them, restructuring *everything*. Samna is a character-oriented editor with several lines of menu at the top of the screen, which are context-sensitive and tend to change with about every other command-letter you type. I don't remember if it was modeless or mode-explicit, but when you were typing something it assumed was a command the cursor would go to top-of-screen and write stuff there, which is rational. Unfortunately, it couldn't do windows right, and constantly had to redraw the entire screen from cursor down. This was exacerbated by the fact that the menu at the top kept changing from two lines to three, causing everything on the page to shift down by one line (dumb) which it did by redrawing instead of insert/delete line (real dumb), even though the terminfo description included insert/delete line. At 19200 it was too slow to be useful; I'd rather use ed. On the console of the PC (16 MHz AT&T 6386) the screen could scroll characters at about 100,000 baud equivalent, and Samna was still ugly. <end insult-the-product mode> One basic difference between PC/Workstations and terminals is the difference in speeds of direct access vs. communication. On a terminal, the way to gain efficiency is by calculating the minimum set of commands to change the screen from what it was to what you want. On a workstation, the screen is right there in the frame buffer, and it's much faster to just write characters where you want them than to think about each location at least three times. Sometimes you know what the optimization is, as when the user types <INSERT LINE>, so you call a subroutine that does that, but usually you just redraw. This makes it very hard to move a PC-oriented product to the UNIX/terminal world, because the assumption that to change the screen you just write to it tends to be all-pervasive, even in well-written modular code. In particular modular routines for screen-handling are probably much lighter-weight than Curses. In Samna's case, the original was probably written in assembler, and the modularity was mostly done to make things fit, though they've used it well to add features. They apparently never used an insert-line module; I assume they just called the copy-line routine N times, resulting in N little calls to curses, each redrawing a line. Another difference between MS-DOS PCs and UNIX terminal system is that PCs have a lot more keys than the traditional terminal, and you can use these to improve the human-factors aspects significantly. The modes-versus-modeless argument really tends to mean "How can I tell a command from input text", which is easy when you have a lot of Function and Arrow keys; the ^F key is always a ^F, because there's a forward-arrow-key to use for forward-cursor commands. Input is always ASCII, while terminal scan codes give you a lot of out-of-band options like control-alt-rightshift-F3, even if Wordstar does use the ^K key as a function key. Some of these arguments go away when you're talking about genuine workstation word processors for UNIX, such as Interleaf and Frame, and Interleaf has been ported to PCs (big hulking ones only, but PCs.) But most UNIX products are oriented toward character-oriented terminals, where WYSIWYG means you only get monospace ASCII; there are some products like CrystalWriter and WordMarc what live in this environment, but it's pretty limiting. To make money in the software business, you either need to have a large market for a low-priced product, or a high-end product that can support high prices if your market is small. The high end of the UNIX text processing market is people who already have troff or TeX, with zillions of powerful features that few of the high-end PC systems can duplicate, where users know that what they work with on their terminals will never come close to what their laser printers can draw. A character-based WYSIWYG system like CrystalWriter can do drafts of straight text and produce nroff-code output, but if you're doing mathematical equations your ASCII terminal doesn't have the character set you need, and even a 132-column mode terminal won't let you draw really hairy tables. (You know the type, where you're using 6-point landscape to make it all fit in a page with lots of T{ T} and weird boxed sections.) For that matter, Microsoft Word on a Macintosh won't let you create a complex table as easily as tbl. Maybe Interleaf or Frame will. But the low end market for UNIX WP's isn't big enough, because most of us roff-users get too frustrated by a system that can't keep track of numbered lists on the fly, so we keep using vi/emacs+TeX/*roff. It's tough to do a cheap low-end product, because the roff-users and PC-market raise the functionality standards for the low end, because it's harder to build a great product for terminals than PCs, because (until recently) a UNIX development shop cost more than a PC development shop, and because you just *know* that three months after you ship Foo-Writer, some college student will use it, like it, and write an Electric-Foo-Writer Gnu Emacs mode which she'll post to comp.sources.misc. It will be slower than your product, but it will have more features, and on a 386-box the speed will be ok. The alternative channel is for a "big" company to port an existing system from PCs or VMS, which they may be able to do cheaply, or for some major market player (SCO, AT&T, IBM, SUN ..) to sell a word processor powerful enough to pay for but cheap enough to buy when you're already buying their UNIX or their 386 hardware. Most of us have tried, but the fact that this discussion keeps coming up is evidence that none of the products has gotten significant market penetration. -- # Bill Stewart, AT&T Bell Labs 2G218 Holmdel NJ 201-949-0705 ho95c.att.com!wcs # also cloned at 201-271-4712 tarpon.att.com!wcs # ... counting stars by candle light ....
woods@eci386.uucp (Greg A. Woods) (07/27/89)
In article <2557@cbnewsh.ATT.COM> wcs@cbnewsh.ATT.COM (Bill Stewart 201-949-0705 ho95c.att.com!wcs) writes: > [.....] They apparently never used an insert-line > module; I assume they just called the copy-line routine N times, > resulting in N little calls to curses, each redrawing a line. [ This is an aside, not really related to the thread.... ] What's wrong with making special effort to determine how the various versions of curses keep their in-core screen images, and writing to that buffer, just like you write to a PC-screen buffer? This has it's problems, but it means you can skip the crud on top of curses that fills the buffer in the first place. For that matter, skip all of curses, and just use the termcap/terminfo routines to read the existing database, and re-implement the curses screen buffering/optimization scheme. There's simply no excuse for sending that much data out a port, except pure lazyness. It all depends upon what you are starting with. You can easily use all of curses if the editor portion of your code is structured like the guts of vi. > Another difference between MS-DOS PCs and UNIX terminal system is > that PCs have a lot more keys than the traditional terminal, and you > can use these to improve the human-factors aspects significantly. I seriously doubt it. The smart terminals people buy today, and even in the recent past, almost always have more than 10 function keys. Even my VT-100 has 14 function keys, plus cursor keys. The difficult thing to find consistently is a meta (alt) key. I won't mention that terminals usually have far better keyboard layouts... > Input is always ASCII, while terminal scan codes give you a lot of > out-of-band options like control-alt-rightshift-F3, even if Wordstar > does use the ^K key as a function key. Yes, this is the real problem with moving some applications from the PC to a terminal. Of course, I always been quite disgusted with applications that used the scan codes anyway. There are much better paradigms than <CTRL-ALT-RIGHTSHIFT-F3>. Over use of multi-key combinations shouts "POOR USER INTERFACE DESIGN!". As you said (in the paragraphs I've deleted), even though there's a lot of noise being generated, the market really isn't big enough to be worth while. I strongly suggest what's required is a good text editor, with some of the editing features of the best word processors. Since I find Jove does more than I need, I'm at a bit of a loss when it comes to identifying the requirements perceived by those who design things like WordPerfect. Once the text has been input, wrapping troff or TeX around the paragraphs is a reasonably simple task. Even someone who can barely operate a typewriter can be taught to enter text in such a way to not increase the effort required to format lists and tables and such. Once you've got them that far, a couple more hours and they can put the troff/TeX requests in themselves. I've personally taught several people this skill, and have even managed to teach them vi or emacs as well. WYSIWYG is a definite no-no in Unix land. Even going so far as attempting a real-time simulation like WordPerfect tries, costs far too much in CPU and I/O. The simple emacs clones (like Jove) are resource intensive enough. The one thing which might have an impact would be cheap graphics terminals, be they X-Window, or BLIT style. At home I have a DMD5620, and I can set up troff to proof to a window every time I save my file. It should be quite easy for someone with sufficient motivation and knowledge to write a programme like 'proof' for MS-DOS. You might even be able to get all of layers running on a PC, though even VGA resolution is only satisfactory for useful windowing. There certainly are enough PC's out there that would make good terminals. -- Greg A. Woods woods@{eci386,gate,robohack,ontmoh,tmsoft,gpu.utcs.UToronto.CA,utorgpu.BITNET} +1-416-443-1734 [h] +1-416-595-5425 [w] Toronto, Ontario CANADA