CLIM mail archive
[Prev][Next][Index][Thread]

CLIM: Lucid vs Franz (2 problems); MAKE-TEXT-STYLE (doc); PRESENT during command

    Date: Thu, 25 Oct 90 22:42 PDT
    From: TYSON@sunset.ai.sri.com (Mabry Tyson)

    We just got the Lucid version of CLIM and I tried out the code I had
    been running under the Franz version but I immediately hit a difference.
    I found that the file that was working on Franz ran into an error when
    being loaded (after compilation, of course) under Lucid.

    I was using the undocumented BUILD-COMMAND function (copying how the menu
    is built in CAD-DEMO) and when Lucid tried to load something of the form

    (define-menu-group FOOBAR
       (("FOO" :command (build-command 'COM-FOO))))

    when COM-FOO had not yet been defined, it complained that NIL couldn't be
    applied or funcalled.  It was in the function 
    INVOKE-COMMAND-NAME-PARSER-AND-COLLECT-INTERNAL inside BUILD-COMMAND.

    When I put that form after the definition of COM-FOO, then it loads without
    warnings.

For reasons which I have never understood, DEFINE-MENU-GROUP evaluates the
BUILD-COMMAND call at load time.  I always thought this was guaranteed to
cause failure, but didn't have a test case.

    This first part is really not a complaint but more of an FYI.  I don't know
    if it shows that one implementation or the other is acting differently than
    the other in any important way, but it might.

It fails under Genera as well.  I can't understand how it could possibly work
in any implementation.  For now, put it after all the commands are defined,
and we will figure out if we should just document that restriction or (better
yet) fix it.

    Stylistically, I much prefer the scroll bars in the Franz CLIM applications
    to the ones in Lucid.  Also, the Close-Application button (or whatever it is)
    in Franz looks much better.  The one in Lucid looks like someone displayed
    it wrong.

I don't know about the scroll bar problem, but the close-application button
problem has to do with a problem with displaying pixmaps which I haven't been
able to reproduce (if it's the thing I think it is: the close button comes
out looking like "][" instead of "[]", right?).  Is the scroll bar perhaps
suffering from a similar display error?

    -------------------------------------------------------------------------------
    Presentation of pathnames in Lucid such as ~/.emacs comes out as
	    /home/dr3/tyson/NIL.emacs
    That problem doesn't show up on Franz.

This is probably a bug in Lucid's implementation of PARSE-NAMESTRING or
NAMESTRING.  Try (NAMESTRING (PARSE-NAMESTRING "~/.emacs")) in each lisp to
see what it does.  Under Genera (the only Lisp I have here at the moment),
you get a pathname object with a name of "" and a type of "emacs"; I bet
under Lucid you get a pathname with name NIL and with the correct type, and
then NAMESTRING does PRINC (or equivalent) on the way out.

    ------------------------------------------------------------------------------
    6.7.1 (Using Text Styles) references MAKE-TEXT-STYLE but it doesn't seem
    to be defined or documented elsewhere.

I thought I had corrected that in the documentation, but I see I didn't.  The
correct name is INTERN-TEXT-STYLE.  PARSE-TEXT-STYLE takes as its single
argument a list of (FAMILY FACE STYLE) instead of three separate arguments.

    -------------------------------------------------------------------------------
    Bill sent me patches 12 and 13 so I could accept multi-line inputs.  
    In general, it has worked.  However, there is a slight display problem that
    shows up.  If I have a command (invoked by a menu) whose body is
	    (present (accept 'multi-line-sentence :stream stream :prompt "Sentence")
		    'multi-line-sentence
		    :stream stream)
    (STREAM is an interactor frame), then everything goes find until the PRESENT
    executes.  At that time, it overwrites the echoed input of the user (which
    was also overwritten by my parser for multi-line-sentence).  However, it
    seems to screw up on the vertical spacing.  In particular the second (but
    not the third,...) line of any multiline sentence gets blurred vertically
    because the overprinting isn't registered vertically.  (It may be that if you
    aren't at the bottom of the interactor, and scrolling, that more lines may
    be screwed up.)

    If you don't do that PRESENT, then the next COMMAND: prompt overwrites the
    second line of the input sentence (and third...).

    Note that if I am doing a normal ACCEPT, say of an integer, and then a PRESENT,
    the output overwrites what the user typed in.  Eg,
	    (accept 'integer :stream stream)
	    (present "This is a test" 'string :stream stream)
    inside the body of a command (at least when invoked by a menu).

A couple of things seem wrong here:

1.  You shouldn't have to re-present the input for it to not get overwritten.

2.  Presenting multiple-line strings fails to look the same as it did when
    the input editor was done printing it.

I'm out of my league on these, I'm afraid.  Dennis?

0,,
Main Index | Thread Index