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

Re: Utilities

    Date: Tue, 20 Nov 90 11:15 PST
    From: Mabry Tyson <TYSON@ai.sri.com>

    I've been working on other stuff recently so I haven't had a chance to
    respond to this until now

	Date: Mon, 12 Nov 90 12:42 EST
	From: Dennis L. Doughty <doughty@fuji.ila.com>

	    Date: Wed, 7 Nov 90 20:09 PST
	    From: TYSON@sunset.ai.sri.com (Mabry Tyson)

	    Thanks a lot for your reply!  

	What was wrong with using (CLIM:PORT frame)?

    I missed that (it wasn't documented).

Yeah, it will be.

	What was wrong with CLIM:ENABLE-FRAME or CLIM:DISABLE-FRAME?

    The documentation for ENABLE-FRAME and DISABLE-FRAME make them seem to
    do something else.  My interpretation of the documentation is that if
    a frame is disabled, the user will not be able to get to it via his
    window system.  Once it is enabled, it may still be buried below many other
    windows.  He may have to manually bury other windows in order for it to
    be visible.

    All I want to do is to bring the (active) frames to the top of the user's
    window system so they are readily available for being used.  When I bury
    the frame, I don't want to prevent him from using the frame, just get it
    out of his way.

Ok.  Typically an application doesn't do that sort of thing ("Get
me out of the way") but rather relies on the user interacting
with the window manager.  A typical X application, for example,
wouldn't have a button marked "bury," the user would invoke the
a window manager menu to bury it.  Of course, if what you're
writing is more like a window manager than an application, then you
need access to this functionality.  It should probably be exported.

	There is a function CLIM:WINDOW-CLEAR which does the above.  Probably not
	the best name...

    I would have thought WINDOW-CLEAR (which doesn't seem to be documented)
    would be a lower level function that didn't touch output-records.

Yes, the name is poor.  In CLIM 1.0 WINDOW-CLEAR will be flushed in
favor of using the lower level primitives for repainting, such as
REPAINT-SHEET, and one generic function called CLEAR-OUTPUT-HISTORY
(or perhaps -RECORD) which will work on both output records and
CLIM streams.

	1) You call PRINC and WRITE, which don't work to CLIM streams because
	there's no stream integration between standard CL streams and CLIM
	streams.  Use [CLIM:]FORMAT ~A or ~S, which we've made basically
	"compatible."  In the Genera version of CLIM, this is less of an issue
	because Symbolics worked on this quite a bit.  It will, however, continue
	to be an issue for the near term in other Lisps.

    My I suggest that the CLIM documentation specifically point out this
    difficulty.

Actually, there was documentation about this issue around page 55
of the Reference Manual in an earlier version -- it appears to have
gotten lost.  We'll restore it for the real release and add it to
the errata.

	If you say :own-window T you'll get the AVV in its own window.  If you say 
	:OWN-WINDOW '(:right-margin hspace :bottom-margin vspace) you'll get that amount
	of additional space (where hspace and vspace can be the same things you'd
	pass off as :INTER-LINE-SPACING or :INTER-COLUMN-SPACING to
	FORMATTING-TABLE).

    Good.  It certainly isn't documented that way.  As I recall, I probably checked
    the arglist of ACCEPTING-VALUES and didn't see that.  But I'll have to try
    it out.

Yep.  I wasn't attempting to imply that you should have been able
to figure that out from the documentation, just that there is
already a mechanism to do what you want.

	If you're going to be dependent on resources, you should probably be
	dependent upon the resources already in CLIM (ci::defresource, etc.)
	because they, at least, are portable.

    Thanks.  Obviously that wasn't documented..

We are working on a better resource implementation now that may
make it into Release 1.0.  If it does, it'll be documented.

0,,
Follow-Ups:
Main Index | Thread Index