grunau_b@husc4.UUCP (02/03/87)
Why is it that on the ST, the standard for scrolling text is a screen separate from GEM, whereas on the Mac one always does one's scrolling inside windows? I ask this, because it seems clear to me that the ability to have the menu bar available at all times is very useful -- consider for instance being in Uniterm, and you want to check the time. You may of course at any time press HELP and you will get a GEM screen with menu bar, from which you may choose a desk accessory that will tell you the time. But the crucial point is that you must then RETURN to the scrolling screen, and LOSE the clock. When you are using a terminal emulator on the Mac, you can have the alarm clock ticking away up in a corner at all times, clearly a highly useful feature. I assume there is something to this that is more than mere convention. Degas does it this way, the VT52 emulator does it this way (choosing one desk accessory does not normally preclude using another or even interacting with another application -- why then does the VT52 DA work like this? Degas uses this double-screen method, perhaps for similar reasons (though this may have simply been a design decision). I have one hypothesis: I remember vaguely reading somewhere that the ST (paradoxically) has two modes -- text and graphics -- and that in text mode, you get automatic scrolling features but cannot do text, whereas in text mode you can have text but do not get automatic scrolling, etc. I say paradoxically, because the ST (like the Mac and Amiga) are supposed to be ALWAYS in graphics mode -- certainly the ST video interface does NOT support true text mode in the fashion of IBM. Try comparing Hercules text mode to the ST -- you can go into an editor on the IBM, hold down the PageDn key, and watch whole pages of text flash by AS FAST AS THE KEY REPEATS. Try this on the ST -- you will hear the key repeating, but the screens of text will be drastically behind. So I am not at all clear on what the purpose of this alleged text mode is, if it lacks hardware support and the speed that text mode usually provides (one of the reasons people think Microsoft Windows is so slow is that it runs in graphics mode on the IBM). Even colour displays on the IBM, while slower than Herc. mono, are vastly faster than the ST's text-plotting. I am hoping the blitter chips with make text plotting/scrolling much more pleasant. Can anyone clear this up for me? Is there a restriction in GEM/TOS that is nonexistent on the Mac that forces one to do scrolling on separate screens without the menu bar, or is it just a preference not to code GEM-specific applications? Are my impressions on text/graphics mode accurate, and will the blitter chip speed up text plotting as I assume it will? Thanks much, JJMG grunau@husc4.UUCP ..or.. seismo ---- \ rutgers------- !husc6!husc4!grunau / decvax!ihnp4
holloway@drivax.UUCP (Bruce Holloway) (02/04/87)
If you go through the normal GEMDOS console output calls, it emulates a VT52 terminal, which, true to form, scrolls the entire screen at once (and they evidently didn't put scrolling regions into their emulation). But if you go through the VDI, it doesn't emulate anything, so you must handle scrolling yourself. And slow scrolling/character update is the bane of any completely graphics oriented computer, Macintosh, Amiga, ST... any of them. I would have appreciated a text mode. -- ....!ucbvax!hplabs!amdahl!drivax!holloway My balogna has a first name, it's Jimbob. My balogna has a second name, it's Boltwangle. But it prefers to be called Jim.
Peck@RADC-MULTICS.ARPA.UUCP (02/09/87)
The reason I have found for not scrolling the text in windows is that
the GEM system doesn't support text very well.
By not very well, I mean, it doesn't do scrolling for you, it doesn't handle
window wraparound at the end of a line, and its generally not text
orientated (unfortunately). After using GEM for awhile and trying to do
things with it, you come to the startling conclusion that GEM was taken
from some programmer's scratch directory somewhere after he through it
away. In general, things are done very strangely.
Anyway, uniterm, the vt52 emulator and others (not degas though)
completely ignore GEM and go through the BIOS which is a collection of
lowlevel system subroutines that either are the drivers or communicate
with the drivers. (I'm not sure, but someone will say for sure.) It
turns out that the BIOS video driver takes VT52 escape codes for cursor
control, screen clearing, etc. That's why it was so easy to make a vt52
emulator.
I don't know if anyone has actually tried to write code for a terminal
emulator in GEM, but if they could get a text-window management package
together that's speedy enough......
According to _Programmer's Guide to GEM_ by Balma and Fitler, sez on
page 180:
"It' importaint to note that GEM is very weak on text processing
functions: that is, functions which display blocks of text and manage
selection, insertion, and deletion of this text. Apple's Macintosh, for
example. provides Text Edit Record functions to manipulate the entry,
selections, and display of large chunks of text; these kinds of
functions are not available from within GEM. To develop a GEM word
processing application, for example, you must provide your own functions
to manage the display of blocks of text. Discussion of the development
of these functions is beyond the scope of this text."
Naturally, they don't say where to go to find a bigger scope either...
rodneyoyster@uwmacc.UUCP (02/11/87)
In article <bleh@RADC-MULTICS.ARPA> Peck@RADC-MULTICS.ARPA (Rodney) writes: > > The reason I have found for not scrolling the text in windows is that >the GEM system doesn't support text very well. ... > According to _Programmer's Guide to GEM_ by Balma and Fitler, sez on >page 180: > "It' importaint to note that GEM is very weak on text processing >functions: that is, functions which display blocks of text and manage >selection, insertion, and deletion of this text. Apple's Macintosh, for >example. provides Text Edit Record functions to manipulate the entry, >selections, and display of large chunks of text; these kinds of >functions are not available from within GEM. To develop a GEM word >processing application, for example, you must provide your own functions >to manage the display of blocks of text. Discussion of the development >of these functions is beyond the scope of this text." > Naturally, they don't say where to go to find a bigger scope either... How about starting with _Inside the MacIntosh_ (or whatever it's called)? You can find it in two volumes on the shelves of your neighborhood chain bookstore. [What follows has no particular meaning: Now, I could have just stopped this message right here, but the news software won't let me post this short message because there is more included text than new text. I know, I could fool the well-written and robust check simply by changing all the '>'s above into some other character; but that would be giving in, in a small way, to the those fools who don't seem to know much about user psychology. Will the new > included check actually cut down new volume? I doubt it; people will either pad out their short messages with garbage (who, me? :-), or they'll change the '>' as noted above. Oh, I'm sure there'll be few people who actually realise that they don't actually need to include the whole previous text, but I don't believe it'll be a significant factor. There. Was that enough?] --