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

CLIM philosophy wrt to X.

Sorry for the delay in the follow-up, I just returned from a vacation.
Anyway, I think the discussion so far has for the most part missed the
gist of my query, so I'll restate them.

My concerned is not so much with the addition of new functions/macros,
not yet anyway, rather it is with the higher level decisions about
what CLIM should expect, say and do in different windowing
environments, and how that impact the CLIM user if any.  (Anybody have
stats on the platforms CLIM is on, especially lispm vs
rest-of-the-world?  It seems that Symbolics is still driving the
development & decision process, which is good for the most part (I
would prefer to still be working on a Symbolics, but, that battle has
long been lost), but there doesn't seem to be enough consideration yet
about other Lisp environments, which prolly is because CLIM is still
young, but still... My suspicion is that if CLIM is to catch on, the
rest-of-the-world portion has to grow fast, hence their environment be
taken more seriously)

There are several concerns that can be usefully separated and dealt
with differently if need be.  At the user interface level, where
performance is less of an issue, I believe an UI system should specify
EXACTLY the behavior of functions it support and have it behave
EXACTLY the same on all platforms (modulo look and feel) without the
user having to do things differently on some platform.  How it is
implemented, whether the user need to do something different, etc.,
should not be a concern.  Ie., if the function is supposed to pop up a
window, then it should pop up the window without the user having to do
anything else, period.  For example, a function like ACCEPTING-VALUES
with the :OWN-WINDOW T option, should automatically pop up the window
without the user having to do anything special, like setting
*CLX-FORCE-OUTPUT* to T or doing a FORCE-OUTPUT beforehand for the
window to appear.  It is very upsetting to use a UI function and have
nothing happen. (It's too bad the manual I'm using is a Symbolics
manual which is oblivious of buffered systems, but then a system that
has portability as it's paramount goal shouldn't need more than one
manual.)

The other level of concern is performance.  Let me state my bias
first, I'm one of those "lucky" programmers that never have to worry
about performance, hence functionality and elegance are usually my
prime concern.  To me, performance tuning and optimizations belong to
the domain of compiler writers and wizards out to squeeze the last
micro-second out of the CPU or await faster CPUs (which is not so far
fetched in the unix world).  I don't have a good idea of what hooks
are needed to satisfy these concerns and yet preserve all the other
goals.  For the buffering question, my gut feeling is that, since it
is mostly a performance issue (somebody raised the issue of
synchronization), perhaps one should consider the strategy used in CL
when dealing with performance, namely, via declarations/proclamations
(eg., turn on/off all buffering).  The macro suggestion sounds ok,
except that it is perhaps too simplistic, I think one need to also
consider situation where abnormal exits occur - should the buffer then
still be flushed, cleared, or the user be expected to take care of
such situations, for example.  For faster graphical operations,
perhaps one will have to go down to the window substrate level and
conditionalize (#+CLX, etc.) them for portability.

Nobody has addressed the issue of different streams yet, another
environmental consideration.  CLIM seems to expect streams to be CLIM
streams, ie., streams where graphical operations can occur.  Systems
on Unix boxes in general start off with a listener where streams are
not CLIM streams, there is a compatibility problem here I think that
requires some policy decision or some convention. 

Chee.

0,,
Follow-Ups:
Main Index | Thread Index