CLIM mail archive
[Prev][Next][Index][Thread]
CLIM problems ...
Date: Fri, 26 Jun 1992 15:23+0100
From: unido!gatech!cc!buff
Some observations about CLIM behavior under Genera 8.1.1 running the latest
released CLIM 1.1. First, CLIM is pretty great overall, except for the
following frays around the edges - some of which make our application look
pretty ugly.
In general, I agree with you that CLIM has some problems with UIs that
have to have real *product* quality. However, you should consider the
few people implementing it in quite a short time.
We have a standalone piece of the larger application we are writing which we
can make available to show almost all of the behaviors detailed below.
However, we have not had the time to write nice little pieces of example code
for each of these behaviors. If you want the standalone code, please advise
(it's less than 1200 lines of code).
Even 1200 lines of code need their time to be scanned, tested, and (if possible)
corrected.
----------
1) When accept'ing a string (at least), CLIM apparently treats newlines
differently for _writing_ and _erasing_ text, causing a string with newlines
in it to erase "too high" and blow away previous lines, as well as drawing its
_last_ line on top of whatever was there before (because it's underlying erase
erased the line before it)
For example:
Line 1: part of a string
Line 2: continuation of the string
Line 3: more stuff in the string
Line 4: current extent of string
If my cursor is at the end of Line 3 and I <ctrl>-p to Line 2 and type any
character, Line 2 is whited-out above Line 3 (i.e. all but the final "ng" of
Line 2) and as new text is typed in this display behaviour doesn't change,
except for the characters in Line 2 that will now appear after the end of Line
3 (i.e. if you are adding characters to the line, the line appearing as it
should begins to be displayed after (and above) the end of Line 3).
The white-out is (we think) when a piece of text is changed you must erase the
old version and draw the new version. Drawing the new version is correct. But
erasing the old-version occurs a line to high. That means text before the
area that is being redrawn is erased (as described above) and the text at the
bottom of the string being redrawn does not get properly erased, and if
there's any change to this last piece of text, you get muliple images
overlayed.
Also, if you type two returns (or more) in a row, the first descends the
proper amount, but each additional return only moves the cursor down by a
pixel. Under certain conditions, when the whole string has to be redrawn, then
white-out is still displayed incorrectly, but the mulitiple carriage returns
are displayed correctly, causing the appearence of the string to change.
Tied in with this problem is the scrolling problem (see below).
It doesn't seem outrageous that this should work, seeing as DW is able to do
it just fine - i.e. (dw:accept 'string) has none of these problems.
2) CLIM accept on strings permits the user to write enough string to scroll
off the bottom end and allows the user to go _down_ off the end of the screen
with cursor keys, but will not scroll back _up_ when the user goes back up the
string. This is not to say I can't move the cursor to the logical beginning of
the string, but that CLIM doesn't show it to me. So, should I reposition the
cursor to the beginning of the string, the screen doesn't reflect that move,
but if I type a character, the whole string is redisplayed (from the top to the
bottom) leaving me looking at the bottom of the string and my cursor one
character from the beginning of the string - i.e. the display jumps around a
ton, but always leaves me looking at the end of the string, not at what I'm
typing.
3) CLIM has this funkee scrolling problem where if things scroll past the end
and it then has to scroll back during the display of the same thing, parts of
that thing get trashed. Example: if CLIM is presenting a single object and
it goes beyond the right window margin, it scrolls horizontally to show the
end of the object. BUT, if during the display the cursor goes back to the left
margin, then CLIM scrolls back to show that part of the object. So far, so
good. However, the stuff that was scrolled off of the screen to the left
doesn't get redisplayed, and instead you have a blank white column there.
I think I did fix this bug for the NON-Silica version of CLIM, and sent
the bug to Scott McKay, of Symbolics, Inc. I don't know for sure what will happen
to the fix. If there are no copyright problems, you can ask Scott to send
the source of the modified function around. If you've got some time left,
it's better to wait for the next release.
5) Scrollbars are not consistent. They often do not respond to the size of
presented objects until those scrollbars are modifed by the user. If you
present something in a window that doesn't fit, so it scrolls, the scroll bars
indicate that you are looking at the entire object, even though you're not,
until you use the scroll bar to scroll - then they correct their display and
are correct after that.
I also said something to this point in this mailng list:
As a quick fix, use CLIM::REDISPLAY-DECORATIONS.
6) You cannot attach a documentation string to a menu item in a command table
that is a call to a nested menu; CLIM's default of "COMMANDNAME Menu"
overrides the documentation.
6A) No way to change the character style for a particular item in a top level
menu, as you can in clim:menu-choose. A similar syntax to clim:menu-choose for
top-level menus would be nice.
You're able to specify an arbitrary function in our application frame definition
that is to be used to display a command menu.
7) with-drawing-options :clipping-region doesn't seem to work as expected. We
expect that any activity that generates output in the window outside of the
region will have its output clipped. However, when using a combination of
filling-output and indenting-output correctly but using the wrong parameters
so that some of the text got sent outside the clipping region, the text got
printed. There's nothing to indicate that clipping-region will apply to
presented text, however, given that drawing-options include other parameters
that do apply to text (:text-style), nor do we find any obvious delineation
between text output and other graphic output in CLIM, we assume this is the
appropriate way to clip textual output.
8) with-activation-characters we would expect to work very similarly to
(syntax may not be exactly right, but you get the idea):
(defmacro with-act-char ((additional-characters &key (override nil)) &body body)
`(let ((*standard-activation-characters*
(if override additional-characters
`(,@*standard-activation-characters*
,@additional-characters))))
,@body))
It doesn't. It seems to have no effect on the activation characters. We hacked
in something like the above and it all worked fine.
It does not work correctly, that's true. You can contact Symbolics Software Support
to report the bug. The easier the bug is to fix, the better. (Maybe you should provide your
version of the macro with-actication-characters.
But note that you have the options :activation-characters and
:additional-activation-characters to accept, which should work, though.
9) There's no way to find out the view used to put a particular presentation
on the screen.
As I understand it, views are used to specialize present methods.
Note that you don't have a :view option to with-output-as-presentation, because
the body of such a macro call is lexically specified, i.e., fixed. Consequently,
a :view option would be senseless.
This reason can alo be used as an argument to motivate the non-existance of a
slot "view" in tha class "presentation", resp. "standard-presentation", because
once the presentation is generated, it is not important anymore, which present
method was chose to create it.
If you want to know about such a thing, you will have to add a subclass to
"standard-presentation" with such an additional slot, you have to fill
manually in your present methods.
Main Index |
Thread Index