Hiding Controls
-
Hello again,
I have been snooping around on Apple's Cocoa site, trying many things in
Project Builder, and still can not figure out how to hide a control.
What I mean by hide is just make it so it doesn't look like it is there
anymore.. and the type of control I want to deal with right now is a
push button.
Thanks again,
Jon -
Hi,
On Sunday, November 18, 2001, at 12:43 AM, Jon Johnson wrote:> I have been snooping around on Apple's Cocoa site, trying many things
> in Project Builder, and still can not figure out how to hide a control.
Check the list archives. It's a common question because Cocoa doesn't
handle this the way most other frameworks do. The way to do it is call -
(void)removeFromSuperview on the push button view you want to hide. When
you want to show it again add it back to its super view with: -
(void)addSubview:(NSView *)aView;
Take care,
Guy -
On Sunday, November 18, 2001, at 06:37 am, Guy English wrote:> Check the list archives. It's a common question because Cocoa doesn't
> handle this the way most other frameworks do. The way to do it is
> call - (void)removeFromSuperview on the push button view you want to
> hide. When you want to show it again add it back to its super view
> with: - (void)addSubview:(NSView *)aView;
Note that removeFromSuperview makes the superview -release it, which
might make its retaincount 0 and it might be deallocated. You should
therefore retain if before removing it and release it after adding it
again.
-- Finlay -
At 12:04 Uhr +0000 18.11.2001, Finlay Dobbie wrote:> On Sunday, November 18, 2001, at 06:37 am, Guy English wrote:
>
>> Check the list archives. It's a common question because Cocoa
>> doesn't handle this the way most other frameworks do. The way to do
>> it is call - (void)removeFromSuperview on the push button view you
>> want to hide. When you want to show it again add it back to its
>> super view with: - (void)addSubview:(NSView *)aView;
>
> Note that removeFromSuperview makes the superview -release it, which
> might make its retaincount 0 and it might be deallocated. You should
> therefore retain if before removing it and release it after adding
> it again.
Therefore, another way to hide controls that is often used is to do
it the same way classic MacOS used to do it - that is, simply move
the contol out of sight to hide it, and back to show it.
Max
--
-----------------------------------------------
Max Horn
Software Developer
email: <mailto:<max...>
phone: (+49) 6151-494890 -
First, please do not hide controls. I think users hate it. They are
surprised when a button they have never seen before appears and angered
when a button they remember is missing. How is a user supposed to learn a
GUI if it keeps changing. The reason for changes may not be obvious to
users either.
It is much better to just disable a button that does not apply rather than
hide it. At least the user will know that the button is sometimes
available.
All of that said, this is a common question that has been answered many
times with source code for different techniques. My advise is don't do it.
If you won't take my advice then search for the other times this has been
answered including by me.
The next questions are not directed at Jon Johnson specifically but at all
of the many people who asked this question:
Why do people want to hide controls ? This was a non-existent practice in
NeXTtsep as far as I know. This is certainly rare in the windows world. Is
there something about the Mac that makes people want to do this ? Is there
a long tradition of hiding controls ? Why hide things ? I should think
that hiding controls from the user is the same as trying to deceive the user
or mislead the user or make the user think that something is not possible
with the application or just surprise the user. What is the rationale for
hiding rather than disabling ?
----- Original Message -----
From: "Jon Johnson" <jonj...>
To: "MacOS X Dev OmniGroup" <macosx-dev...>
Sent: Saturday, November 17, 2001 11:43 PM
Subject: Hiding Controls> Hello again,
>
> I have been snooping around on Apple's Cocoa site, trying many things in
> Project Builder, and still can not figure out how to hide a control.
>
> What I mean by hide is just make it so it doesn't look like it is there
> anymore.. and the type of control I want to deal with right now is a
> push button.
>
> Thanks again,
>
> Jon
>
> _______________________________________________
> MacOSX-dev mailing list
> <MacOSX-dev...>
> http://www.omnigroup.com/mailman/listinfo/macosx-dev -
There are valiid reasons for hiding a *control* (the question refers
to controls in general, not just to buttons).
E.g. look at the find dialog in various of Apple's apps - they have a
static text item that can say "No match" or be invisble (OK, in that
case, you can make it "invisbile" by setting the text to the empty
string).
Or a progress bar that is only shown if something is in progress (as
it is done in Project Builder).
Max
--
-----------------------------------------------
Max Horn
Software Developer
email: <mailto:<max...>
phone: (+49) 6151-494890 -
In addition, there are some times when you have a user control that doesn't
make sense. For example, in a program that primarily views data, should the
edit controls always be there? Yes, you could use another window (but that
brings the issue of the user managing the windows or the issue of modality,
depending on whether the edit window is modal or not), or sheet (but that
definitely becomes modal).
Also, if there are two types of data being stored, call it foo and bar. Foo
and bar are almost identical, except for one factor that foo has and bar
doesn't. Hiding that visual element when editing bar may make the most
sense.
Isn't a drawer a way of hiding UI items?
Donald
on 11/18/2001 12:51 PM, Max Horn at <max...> wrote:> There are valiid reasons for hiding a *control* (the question refers
> to controls in general, not just to buttons).
>
> E.g. look at the find dialog in various of Apple's apps - they have a
> static text item that can say "No match" or be invisble (OK, in that
> case, you can make it "invisbile" by setting the text to the empty
> string).
>
> Or a progress bar that is only shown if something is in progress (as
> it is done in Project Builder).
>
>
> Max
--
Donald Brown
<gadgetdon...>
http://www.eamontales.com
We have met the enemy and he is us - Pogo -
> In addition, there are some times when you have a user control that doesn'tYes, and so are Tab views, two interface details not present in NeXT GUI as
> make sense. For example, in a program that primarily views data, should the
> edit controls always be there? Yes, you could use another window (but that
> brings the issue of the user managing the windows or the issue of modality,
> depending on whether the edit window is modal or not), or sheet (but that
> definitely becomes modal).
>
> Also, if there are two types of data being stored, call it foo and bar. Foo
> and bar are almost identical, except for one factor that foo has and bar
> doesn't. Hiding that visual element when editing bar may make the most
> sense.
>
> Isn't a drawer a way of hiding UI items?
>
far as I know...
/ rgds, david>
>> There are valiid reasons for hiding a *control* (the question refers
>> to controls in general, not just to buttons).
>>
>> E.g. look at the find dialog in various of Apple's apps - they have a
>> static text item that can say "No match" or be invisble (OK, in that
>> case, you can make it "invisbile" by setting the text to the empty
>> string).
>>
>> Or a progress bar that is only shown if something is in progress (as
>> it is done in Project Builder). -
Tab Views, Drawers, Info-Window pages, disclosure triangles attached to
expanding/contracting windows, and probably other UI elements are all ways
of hiding user interface elements. However, all of these ways indicate that
more UI is available and how to see it. Tab views show the user how many
tabs are available and the user can cycle through the tabs at any time to
see their contents. There is usually a way for the user to open a drawer
and see its contents.
Having a button or text field suddenly appear where there was none before is
probably going to surprise users. There is no indication to a user that a
hidden control exists. There is no indication to the user how to make the
control visible or invisible. A user who remembers the existence of the
control may be come frustrated when she can not find the control later
because it is hidden and the reason for its being hidden is not obvious.
Several reasons for hiding and revealing controls have been stated:
- if there are two types of data being stored, call it foo and bar. Foo
and bar are almost identical, except for one factor that foo has and bar
doesn't. Hiding that visual element when editing bar may make the most
sense.
I argue that disabling that visual element when editing bar makes more
sense. Using separate Info-panel pages might also makes more sense.
- An application is primarily a viewer. Should editing controls be present
if they do not apply.
I argue that the editing controls should be visible but disabled. That way
the user knows that under some circumstances some things can be edited.
Otherwise the user has no idea that anything can be edited ever.
- A set of simple editing controls and a separate set of advanced editing
controls exist.
This is an excellent candidate for a tab view. One tab is titled "Simple"
and another is titled "Advanced". Otherwise, how do users get into advanced
mode ? How do users know the differences between advanced and simple modes.
Having both tabs informs the user that she has an obtain and lets her look
at both options before selecting one.
- A "new game" button in a tic-tac-toe game.
Is there some reason this button can not be available all the time. A
player who wants to abandon the current game and start a new game could
press the button in the middle of a game. If users are not allowed to
abandon a game in the middle then the "new game" button can be disabled. I
don't see any reason to hide this button, but on the other hand, games are
different from most applications. If there is ever a case for hidden
controls, games are good candidates. Games are meant to surprise and
entertain. Most users are going to be irritated if surprised when trying to
get work done.
Nobody has yet told be where this practice of hiding controls originates.
Is it common in Mac OS 9 ?
I urge people not to hide controls. Please consider alternatives. -
People should always consider alternatives. Many controls (in OS 9, and I
have seen it in Windows as well) that are hidden should be disabled. But as
for whether they should never be done, well, I disagree. Sometimes,
disabled controls aren't unavailable options to the user, they are clutter
that interfere with the users' evaluation of what to do next. IMHO, of
course.
Donald
on 11/18/2001 2:44 PM, Erik M. Buck at <embassociates...> wrote:> Nobody has yet told be where this practice of hiding controls originates.
> Is it common in Mac OS 9 ?
>
> I urge people not to hide controls. Please consider alternatives.
--
Donald Brown
<gadgetdon...>
http://www.eamontales.com
We have met the enemy and he is us - Pogo -
On Sunday, November 18, 2001, at 10:20 AM, Erik M. Buck wrote:> Why do people want to hide controls ? This was a non-existent practice
> in
> NeXTtsep as far as I know.
Actually, the classic NEXTSTEP example was IB - its inspector, palette,
and File's Owner windows, all of which hid/hide controls (with a
scrollable set of buttons, a popup menu, and a tab stack,
respectively). And this was also one of the most requested classes from
starting developers in the early days.
There are certainly good reasons for hiding UI. Conceptually, you don't
want to surprise the user, but that doesn't mean you want to overwhelm
them with unnecessary information (most naive NEXTSTEP applications
suffered from this, IMO - scads and scads of sliders and typeins). You
could also argue that conceptually, you're not hiding controls with a
tabview or such, because the user knows it's "under there", but
practically speaking, you need to "hide" the control.
Me, I like data dense, progressive disclosure UIs, that let me stay task
focused and don't overwhelm me with clutter I don't care about. While
I'm still not a fan of the current implementation of drawers (since they
leave no indication to the user that they're there, the UI designer has
to do that), I do like the idea a lot.
my $.02
--> Michael B. Johnson, Ph.D. -- <wave...>
--> Studio Tools, Pixar Animation Studios
--> http://xenia.media.mit.edu/~wave -
Erik M. Buck wonders:> Why do people want to hide controls ? This was a non-existent practice in
> NeXTtsep as far as I know. This is certainly rare in the windows world. Is
> there something about the Mac that makes people want to do this ?
Not at all. The Mac OS UI guidelines have recommended against such practice, for
just the reasons you cite, since 1984. Contrary to your assertion that this is
rare in the Windows world, I find that the majority of the people asking this
question do seem to have a background that's Windows-heavy. I suspect they (not
all Windows programmers, just the ones asking this question) operate under the
assumption that users are frustrated by having a control available that they
can't use.
Max Horn, in his own response to Erk, comments:> There are valiid reasons for hiding a *control* (the question refers
> to controls in general, not just to buttons).
>
> E.g. look at the find dialog in various of Apple's apps - they have a
> static text item that can say "No match" or be invisble (OK, in that
> case, you can make it "invisbile" by setting the text to the empty
> string).
>
> Or a progress bar that is only shown if something is in progress (as
> it is done in Project Builder).
I would note that neither of these are controls in the sense that they don't
provide a control mechanism. They are simply views that indicate status.
And Donald Brown asks:> For example, in a program that primarily views data, should the
> edit controls always be there?
Well, by Erik's logic (with which I agree) they should be there if editing is a
normal - even though not necessarily primary - usage of the program.> Also, if there are two types of data being stored, call it foo and bar. Foo
> and bar are almost identical, except for one factor that foo has and bar
> doesn't. Hiding that visual element when editing bar may make the most
> sense.
Depends entirely on your viewpoint. I'd leave it visible but disabled. The whole
point behind disabling is to indicate that something is not currently relevant
while maintaining a stable UI. Again, I agree with Erik's stance on this. I
suspect most long-time Mac OS programmers do, regardless of what other
experience they may have.> Isn't a drawer a way of hiding UI items?
I see the point, but it's not quite a comparable situation, primarily in that
it's under user control rather than an issue of modality. Drawers are a
reasonable extension of the desktop metaphor and are analogous to objects such
as traditionally menu-activated tool palettes on other platforms.
G -
Here go my $1e-2, caution, humble opinions ahead...> From: "Erik M. Buck" <embassociates...>
> Date: Sun, 18 Nov 2001 14:44:46 -0600
> ...
> Having a button or text field suddenly appear where there was none before is
> probably going to surprise users. There is no indication to a user that a
> hidden control exists. There is no indication to the user how to make the
> control visible or invisible. A user who remembers the existence of the
> control may be come frustrated when she can not find the control later
> because it is hidden and the reason for its being hidden is not obvious.
Right. Controls should appear and disappear, if at all, only as an
immediate result of user action, and in a standardized way that makes
sense in that context. One example is tab views; another is
disclosure triangles/buttons that make a part of the window appear
and disappear.> Several reasons for hiding and revealing controls have been stated:
>
> - if there are two types of data being stored, call it foo and bar. Foo
> and bar are almost identical, except for one factor that foo has and bar
> doesn't. Hiding that visual element when editing bar may make the most
> sense.
>
> I argue that disabling that visual element when editing bar makes more
> sense. Using separate Info-panel pages might also makes more sense.
Well, distinctions may not always be as clear-cut. In XRay I have a
permissions panel with a disclosure button which causes an "advanced"
set of controls to appear and disappear. There's also a "Change
Enclosed" button which applies only to folders. One might argue that
simply disabling this button for files makes no sense, since a naive
user might conclude that this button might conceivably be enabled
under some obscure circumstance, and that "Change Enclosed" might be
applied to files...
I was faced with making two complex nibs which differ only in the
presence or absence of that button, or to hide it when opening files
instead of folders. I chose to hide it. In any event, the visual
appearance for the user would be the same.
Now, in this case, it's impossible to change an item from being a
file to being a folder, so the button would never suddenly pop up or
disappear. I agree with Erik that it's better to have controls change
between enabled and disabled, instead of appearing and
disappearing... but hiding and showing controls before showing the
window is IMHO acceptable.> Nobody has yet told be where this practice of hiding controls originates.
> Is it common in Mac OS 9 ?
>
> I urge people not to hide controls. Please consider alternatives.
It originated in the old Mac OS days, of 400K diskettes and 128K RAM,
where every byte was precious. So the old open/save dialogs (for
instance) had all possible items and optional controls, most of them
hidden moving them out of the window frame. Later PowerPlant and
similar frameworks made this easier by simply not redrawing hidden
controls.
However I can't remember any blatant cases of applications with
controls becoming visible and invisible in non-intuitive ways, so it
seems this has always been used with some caution...
--
Rainer Brockerhoff <rainer...>
Belo Horizonte, Brazil
"Originality is the art of concealing your sources."
http://www.brockerhoff.net/ (updated Oct. 2001) -
Well, this long-time Mac OS programmer does believe things should be hidden
from time to time (1984, first product was Desk Accessory mover). So let's
be careful with the assumptions. (Calling me a Windows programmer, that's a
deadly insult in some circles.)
The less cluttered a UI is, the clearer it is to the user. And any disabled
control immediately raises the question, why can't I click on this. I've
taken tech support calls on "Nothing happens when I click on this gray
button" but never "I thought there was a button here." If there is a
hierarchy of controls (these controls are only active when a radio button is
selected), yes, they should be disabled instead of hidden. But within a
window, if there is no way to activate a control, it should be hidden.
IMHO, of course, and you have a different one. Interface is not an exact
science, there are legitimate disagreements about the best way to accomplish
something. That's why the things Apple specifically suggests we do or don't
do are called "guidelines" not "rules". These sort of discussions are
useful to help us improve our interfaces.
Donald
on 11/18/2001 8:03 PM, Gregory Weston at <gweston...> wrote:>> Also, if there are two types of data being stored, call it foo and bar. Foo
>> and bar are almost identical, except for one factor that foo has and bar
>> doesn't. Hiding that visual element when editing bar may make the most
>> sense.
>
> Depends entirely on your viewpoint. I'd leave it visible but disabled. The
> whole
> point behind disabling is to indicate that something is not currently relevant
> while maintaining a stable UI. Again, I agree with Erik's stance on this. I
> suspect most long-time Mac OS programmers do, regardless of what other
> experience they may have.
--
Donald Brown
<gadgetdon...>
http://www.eamontales.com
We have met the enemy and he is us - Pogo -
On Sunday, November 18, 2001, at 06:03 PM, Gregory Weston wrote:> Erik M. Buck wonders:
>
>> Why do people want to hide controls ? This was a non-existent
>> practice in
>> NeXTtsep as far as I know. This is certainly rare in the windows
>> world. Is
>> there something about the Mac that makes people want to do this ?
>
> Not at all. The Mac OS UI guidelines have recommended against such
> practice, for
> just the reasons you cite, since 1984. Contrary to your assertion that
> this is
> rare in the Windows world, I find that the majority of the people
> asking this
> question do seem to have a background that's Windows-heavy. I suspect
> they (not
> all Windows programmers, just the ones asking this question) operate
> under the
> assumption that users are frustrated by having a control available that
> they
> can't use.
>
It's a suggestion not a rule.
Simple Finder in OS9 hides lots of controls. Ok, there's no equiv. in
OSX Finder but you see my point, I think.
Sometimes it's best to default to a rich UI and let the user decide what
tools should be available all the time and what tools can be "hidden".> Max Horn, in his own response to Erk, comments:
>
>> There are valiid reasons for hiding a *control* (the question refers
>> to controls in general, not just to buttons).
>>
>> E.g. look at the find dialog in various of Apple's apps - they have a
>> static text item that can say "No match" or be invisble (OK, in that
>> case, you can make it "invisbile" by setting the text to the empty
>> string).
>>
>> Or a progress bar that is only shown if something is in progress (as
>> it is done in Project Builder).
>
> I would note that neither of these are controls in the sense that they
> don't
> provide a control mechanism. They are simply views that indicate status.
>
While that may be true you don't have to look far to see where Apple has
added the ability to hide controls in an app. Internet Connect comes to
mind (and personally I don't like how it's done) but I'm sure there are
others.> And Donald Brown asks:
>
>> For example, in a program that primarily views data, should the
>> edit controls always be there?
>
> Well, by Erik's logic (with which I agree) they should be there if
> editing is a
> normal - even though not necessarily primary - usage of the program.
>
>> Also, if there are two types of data being stored, call it foo and
>> bar. Foo
>> and bar are almost identical, except for one factor that foo has and
>> bar
>> doesn't. Hiding that visual element when editing bar may make the most
>> sense.
>
> Depends entirely on your viewpoint. I'd leave it visible but disabled.
> The whole
> point behind disabling is to indicate that something is not currently
> relevant
> while maintaining a stable UI. Again, I agree with Erik's stance on
> this. I
> suspect most long-time Mac OS programmers do, regardless of what other
> experience they may have.
>
Depends on the application and the end/target users.
I have what I think is a good example of control hiding. If anyone wants
a peak (be warned it's still really crufty) let me know. -
On 11/19/01 at 7:10 AM, you wrote:> Well, this long-time Mac OS programmer does believe things should be hidden
> from time to time (1984, first product was Desk Accessory mover). So let's
> be careful with the assumptions.
Which is why I took care to use the word "most" in my comments. Feeling on when
to hide an irrelevant control and when to disable it run a continuum with the
endpoints being people who will _never_ do one or the other.> The less cluttered a UI is, the clearer it is to the user.
I don't think I agree with the implication that a disabled control necessarily
qualifies an interface as "cluttered."> But within a
> window, if there is no way to activate a control, it should be hidden.
That I would tend to agree with, but I would say from the viewpoint of the user
that would likely be considered a "different" window. There's a difference
between "for this invocation of this window that control has no relevance so I
want it gone" and "for the current state of the window this control is
irrelevant but that may change so I'll hide and show it as necessary."> That's why the things Apple specifically suggests we do or don't
> do are called "guidelines" not "rules".
I've always been confused by the people who miss the implications of the word
'Guideline' in "Human Interface Guidelines." I've regulary seen people argue
against the existence of HIGs on the grounds that the stifle creativity without
recognizing that they are specifically not called Human Interface Rules Which
Must Be Obeyed Without Question. I always thought the one overriding rule was
"do what the user expects" and given that the expectations of the "average" user
mutate over time HIGs have to be flexible and they have to be able to withstand
scrutiny.
G -
On 11/19/01 at 11:51 AM, Ryan Stevens wrote:>
> On Sunday, November 18, 2001, at 06:03 PM, Gregory Weston wrote:
>
>> Erik M. Buck wonders:
>>
>>> Is there something about the Mac that makes people want to [hide
>>> controls]?
>>
>> Not at all. The Mac OS UI guidelines have recommended against such
>> practice, for just the reasons you cite, since 1984.
>
> It's a suggestion not a rule.
Yes, that's why I used the word "recommended." Nothing about what I've said
here, or in any other forum ever, should be taken to indicate that I believe
HIGs are unassailable truths. I have, in fact, explicitly denied that belief in
multiple forae, targetting multiple operating systems, over the last 15 years.> Simple Finder in OS9 hides lots of controls. Ok, there's no equiv. in
> OSX Finder but you see my point, I think.
>
> Sometimes it's best to default to a rich UI and let the user decide what
> tools should be available all the time and what tools can be "hidden".
Which goes back to my distinction about hiding things under explicit user
control as opposed to as an arbitrary side effect of user actions. I think my
original response to Erik, et al, may have left some ambiguity. I hope I cleared
that up in my response earlier today to Donald Brown.
G -
on 11/19/2001 7:53 PM, Gregory Weston at <gweston...> wrote:>> Simple Finder in OS9 hides lots of controls. Ok, there's no equiv. in
>> OSX Finder but you see my point, I think.
>>
>> Sometimes it's best to default to a rich UI and let the user decide what
>> tools should be available all the time and what tools can be "hidden".
>
> Which goes back to my distinction about hiding things under explicit user
> control as opposed to as an arbitrary side effect of user actions. I think my
> original response to Erik, et al, may have left some ambiguity. I hope I
> cleared
> that up in my response earlier today to Donald Brown.
Yup. When it comes down to it, there are two primary goals in an interface:
A confused user is an unhappy user. A user doing what he wants to
accomplish is a happy user. And our job is to make happy users.
Donald
--
Donald Brown
<gadgetdon...>
http://www.eamontales.com
We have met the enemy and he is us - Pogo -
>> Erik M. Buck wrote:
>> Why do people want to hide controls? This was a non-existent
>> practice in NeXTtsep as far as I know. This is certainly rare
>> in the windows world. Is there something about the Mac that
>> makes people want to do this? Is there a long tradition of
>> hiding controls?
>
> Yes, there is a tradition on Mac OS of sometimes hiding controls.
>
>
>> Why hide things? I should think that hiding controls from
>> the user is the same as trying to deceive the user or
>> mislead the user or make the user think that something is
>> not possible with the application or just surprise the user.
>> What is the rationale for hiding rather than disabling?
>
> Generalizing. That, at least, was the term I've seen
> used for it. Instead of creating a dozen custom
> dialog resources, each with a different set of controls
> and different glue, where possible, they'd create one
> dialog that could be used in multiple instances. Some
> would simply be missing particular buttons (in a rare
> case or 3 a radio button group would be substituted for
> check-boxes). The glue code would take a structure of
> default or previous settings, load it into the dialog
> (groping its way like unto a blind person), then crank
> up the dialog event loop. When it came back, it'd fetch
> back the altered settings into a structure (or revert,
> depending on whether an OK or Cancel button had been
> clicked).
>
> Or maybe I wanted an admin/moderator access to an app,
> where the dialog would be the same except for just a
> couple additional buttons.
>
> Of course, that's not the way I'd think to do it, &
> definitely not the approach I'd take with Cocoa.
>
> But there are other cases. In GIA, and probably other
> list-based apps, the user choices change the selections
> that are valid. Now, this case could maybe be handled by
> mere disabling, but with large lists it's been found
> better to just display the currently valid possibilities,
> bringing the list down to managable size quickly. (One
> alternative we've experimented with is tabbed views,
> and a combination of a fixed number of lists and a matrix
> of buttons; that's OK when a few of the categories have
> a predominant effect on the lists, or e.g. when exactly
> one of them will be used in every case.) But, also the
> number of lists might change, leaving more room for
> displaying the remaining ones.
>
> And then, let's say one is using a word-processor. One
> can lay-out a document as having n vertical columns per
> side of a page, so a user choice will properly not just
> disable one of a maximum number of possible columns, but
> only show the desired number of columns, with the margins
> and gutter(s) as set by the user. The same applies to
> tables; one might let the user set/declare/control the
> number & sizes of columns for a precise lay-out.
John G. Otto, Eagle Scout, Knight, Cybernetic Praxeologist
Existence, Consciousness, Identity, Life, Liberty, Property, Privacy, Justice
