CLIM mail archive
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" <firstname.lastname@example.org>
Date: Tue, 22 Sep 1992 18:54 EDT
From: Bill York <email@example.com>
Date: Tue, 22 Sep 92 18:06:25 EDT
From: firstname.lastname@example.org (Clinton Hyde)
why not have done something (like I *think* I remember lispms doing)
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.
Main Index |