[1945] in testers
Re: OLH display not wide enough
daemon@ATHENA.MIT.EDU (Chris VanHaren)
Wed May 27 11:53:30 1992
To: kcunning@MIT.EDU
Cc: testers@MIT.EDU, olh-bug@MIT.EDU, lwvanels@MIT.EDU, cavan@MIT.EDU
From: Chris VanHaren <vanharen@MIT.EDU>
Date: Wed, 27 May 92 11:52:27 BST
> [I'm on a VAXstation 3100; could someone check this elsewhere?]
>
> In 7.4, the built-in text window for OLH ("internal viewer") now only
> displays 76/77 characters in its text area, rather than a full 78. ...
Yep, you are right, this can be fixed easily enough. I think I know
what caused the spacing difference -- I'll play with it a while and
see...
> Also, with regard to the text area for OLH, it still doesn't support standard
> cut/paste extension (i.e., extending the selection area using the right mouse
> button). This was also true in the past, but I'm surprised it hasn't been
> fixed yet in the Motif text widget. Are we not toggling some switch right,
> or is this truly not fixed yet?
I'm not sure it'll ever be "fixed". It's not broken, really. You are
implying that xterm's cut&paste bindings are the "standard" -- this was
never the case. There are no UI standards caovering all of X, unlike
the Mac, for example. Each toolkit can implement whatever UI it likes.
Motif chose not to use the same bindings as xterm -- even the Athena
text widget is different from xterm.
We could *make* it work like xterm, however, I was told to port olh to
motif 1.1, and no other changes were spec'ed. Also, I'm not sure I
agree that it should work like xterm, since then it would not work like
any other motif program.
> In covering the OLH issue [see my previous message], I noticed that lots of
> the graphical aspects of the OLH display seem fuzzier in 7.4 than they did in
> 7.3. For example, the toggle square next to the Use External Viewers item on
> the Options menu is not at all as crisp as in 7.3; the elements of all the
> scrollbar displays are also not as crisp; etc.
>
> I'm not sure what this is due to. I suspect it's the support of color
> (rather than just a newer version of Motif), and that what I'm seeing
> is the fuzziness caused by seeing several different colors all
> rendered as black/white on my screen.
>
> Is this effective LOSS of graphical clarity on non-color systems necessary in
> order to support color for higher-end workstations? Can't we compile
> non-color versions of applications for non-color workstation types? (Maybe
> workstations aren't "color" or "non-color" per se, but we can talk realities
> on campus anyway). I'm wondering whether this is an issue that lots of
> applications have to deal with, and what a standard solution might be.
>
> As for OLH, if we can't have different compiled versions, I would like
> to have the color features that make non-color versions fuzzy pulled
> out; I don't want any evident degradation in quality for any current
> users of OLH.
The change in appearance is due solely to the change from motif 1.0 to
motif 1.1. Several other graphical aspects were changed as well. The
ones you point out are the more obvious changes.
This has nothing to do with color vs. black&white. Again, we may be
able to change the look slightly, although it is probably tricky in this
case, and again, it would then make OLH different from all the other
motif1.1 programs, etc. Are the differences really *that* distracting?
Is is something that you think users will care a whole lot about? I
mean, after the initial feeling that "something looks different"?
Compiling a special version for black&white is not really an option --
specifying resources *is* an option, but unfortunately, until we move to
x11r5, there is no easy way to specify different resources for different
display types, and we have decided not to go with x11r5 for this
release, so...
-C.
