1. Color on select-file
     Does anyone know of a way to control the colors on the select-file window?
  I am using an associated-window which has a black foreground and white
  background.  I would be satisfied if the select-file matched the
  associated-window colors.  Right now, my select-file pane comes up in
  black foreground and cornflower-blue background (as my nearest guess).  It
  isn't a completely horrible combination but it certainly wouldn't be my
  first choice.

    I notice that Symbolics supports :foreground and :background keywords for
  select-file.  That would be ideal but I would settle for it picking up a
  foreground and background color from the associated window.  Is the only
  control on this through .Xdefaults or the like?  If so, this seems a little
  less than ideal.

No background or foreground resource is specified when creating the
Motif file selection dialog so motif just uses the standard widget
resource lookup mechanism. The blue background and black foreground is
the default motif color scheme. Currently the only way to control this
is to use the Xdefaults mechanism. The resource lookup is done under
the application name/class of "clim"/"Clim" eg

clim*background: gray70

would work.

Unfortunately select-file doesn't appear to be defined in the spec so
there are some portability issues. My feeling is that it should
behave as closely as possible as menu-choose (which is defined).
In the spec menu-choose doesn't take :foreground and :background
initargs. Our implementation takes the color from the associated
window and I think that this is the way we should go for select-file
and in fact all the other dialogs. (eg notify-user etc) I will file an
rfe.

  2. General layout problems
    Is anyone else experiencing problems with the layout algorithms for CLIM
  2.0?  I have an application which has a control menu, main application area
  and a pointer doc pane.  I have an undocumented workaround whereby the
  pointer-documentation can be forced to be just one line.  

What is the workaround? You shouldn't need to do anything special if
you are using :pointer-documentation t in the define-application-frame
- the pointer-doc pane is constrained to being one line. If you have an
example to the contrary please send it.

							   All other attempts
  at definition result in the area being divided roughly in half between the
  work area and the pointer-documentation.  If the window is opened without
  specifying a size at either make-application-frame or at
  define-application-frame time, the window will _initially_ open with the
  pointer-documentation at one line.  If the window is resized at any time: at
  make-application-frame call, at define-application-frame time or by user
  interaction, the single line aspect is lost.  Although I have a workaround
  for the pointer-documentation pane, I still have the problem for other panes
  that we define.  Are users experiencing these problems on Suns as well or is
  this a SGI problem? 

There shouldn't be any difference between the behavior of the Sun and
SGI implementations at this level.

			 If anyone is interested, I have a simple test file that
  can be used for this problem.  

Please send it and I will take a look at it.

-----
Colin Meldrum, Franz Inc.	1995 University Avenue, Suite 275         
<Franz.COM at colin> (internet)	Berkeley, CA 94704                       
uunet!franz!colin (uucp)	Phone: (510) 548-3600; FAX: (510) 548-8253