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

labels for panes

    Date: Wed, 23 Sep 1992 11:21 EDT
    From: Scott McKay <SWM@stony-brook.scrc.symbolics.com>

	Date: Tue, 22 Sep 1992 19:10 EDT
	From: "John C. Mallery" <jcma@reagan.ai.mit.edu>

	    Date: Tue, 22 Sep 1992 18:54 EDT
	    From: Bill York <york%oakland-hills@lucid.com>

	       Date: Tue, 22 Sep 92 18:06:25 EDT
	       From: chyde@chesapeake.ads.com (Clinton Hyde)

	       why not have done something (like I *think* I remember lispms doing)
	       like this:

	       reserve space at either top or bottom of the pane which is part of the
	       margin region and put the label in that space? that way the interior
	       clipping region of the pane is cleanly separated from the label.
	       scroll-bars can go in the margins, as can things like choice-boxes,
	       etc, and you can be certain that they won't be affected by any drawing
	       to the window (except calls to low-level functions which don't know
	       about the margins as clipping regions).

	    This is in theory possible, but CLIM's CLX-port's margins mechanism is
	    not nearly as robust or powerful as the Genera margin components
	    facility.  Still, if this is an important enough issue for users,
	    something could probably be done.

	It sure is important multiple-window/multiple-layout configurations not to menu seas
	of pop-up menus. Label text style just about as important -- so what the window is
	about is easily distinguised from the content of the window.

    It's important, but is it important enough to further delay the release
    of CLIM 2.0 to do this in CLIM 1.1?  CLIM 2.0 already supports labels.

It really depends on how you view the product.  Personally, I'll' take
whatever I can get as soon as possible.  But often, people are turned off by a
software package that has bugs, is hard to use, or lacks key features they
need.  So, if this is a problem, I would delay.  

Alternatively, I imagine CLIM is targeted at developers right now, so getting
something better than 1.1 out should override the completeness issue.  After
all, 2.1 can come out when the additional features are ready.

Personally, I would like to see a release strategy with smaller, upward
compatible releases with higher frequency than big, possibly incompatible
releases over longer periods.  This is good for two reasons:

	1) Steady progess is observed by users, inspiring confidence
	that things will get (even) better;

	2) Users are confronted with a smaller number of things to learn 
	with each release, and consequently, will make use of them.

And if they don't want to update their code, that is there choice; they can
wait for a few more minor releases.

0,,
Follow-Ups: References:
Main Index | Thread Index