CLIM mail archive


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)


    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

    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

    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:

    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

    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