From: "David Herron" <david@twg.com>
Subject: Re: Wishes for TK listboxes & scrollbars
Sensitivity: Personal
Encoding:  75 TEXT , 4 TEXT 
Conversion: Prohibited
Organization: The Wollongong Group, Inc., Palo Alto, CA
Conversion-With-Loss: Prohibited
Date: Wed, 29 Jul 1992 21:19:21 GMT

Wolfgang Fischer sent me a private note asking a couple of questions and
trying to explain why TK shouldn't have a viewport widget.  At least that's
what I think he was trying.  In any case, I wrote a response but the mail
bounced because of his address: Wolfgang Fischer <wf@athen.uucp>.  This is
not a proper domain name and I haven't the foggiest idea how to reach it.

Since the reply is likely of general interest .....

> This is a conceptual difference between Motif and tk. The scrollbar
> is a entity in itself talking to the scrolled widget and beeing called
> from the scrolled widget.

you can do that in Motif as well.  But it's more difficult to set up.
Just like with TK, you must set up communication between the two widgets.
In TK it's pretty trivial, while in Motif it isn't.

> If a widget does not want a scrollbar, it does not configure one.

NIT: It is not the widget which wants or not wants.. it is the programmer.

With TK listbox+scrollbar situations the scrollbar is there all the time.
Granted a programmer could set up code to detect the need for the scrollbar,
but that is never done because it is hard to do.

> If the contents of a window is to large in whatever direction, the
> widget may configure one or two scrollbars.

Again, in TK the widget cannot do this automatically.  The programmer has to
write code to do it (non-trivial).


The advantage of XmScrolledWindow is its generality.  It is useful for listboxes
and editboxes to automatically pop scrollbars up and down on need.  The equivalent
in TK is to create one or two scrollbars, and set up mutual callbacks to update
each others details.  This works well with things which already support the
`scrolling' idea.

But a viewport window (that is, XmScrolledWindow) is much more generally
usable than that.  It can be used with any other widget, ones which don't
normally support the scrolling idea.  A scrolled button is a very real (and 
weird) possibility.  The place where Motif makes really good use of this
is on the XmMainWindow and XmPanedWindow widgets.

Main windows can be set up so that resizing them to be too small will pop
up scroll bars at the edges of the window.  The user then has a viewport..

Paned windows have the same effect as main windows, but there is one viewport
per pane.

> But why are you not posting your tk-procs to get the keyboard
> commands?

I did.  (yesterday)








While writing the above I remembered that the canvas widget (new in tk2.1)
has a viewport facility in it.  But that the viewport area is unable to
hold regular TK widgets.

It would be really nifty-keano if the viewport part would be spun off into its
own widget and that it were able to manage any TK widget.  It should support
the yscrollcommand and xscrollcommand concept from the listboxes and edit boxes.
Come to think of it.. there should already be code to do viewports in the
listbox code already there.

Like I was saying to Wolfgang.. having a viewport widget is a lot more 
flexibility since it allows the scrolling ability to be added to any other
widget.  The most useful will be to the window as a whole.  It would be a
step in the direction to having paned windows in tk.  &c

<- David Herron <david@twg.com>, Just: Another E-Mail hacker ...
<-
<- As for the prevalence of gratuitous stupidity in modern life, well,
<- need I say more than "MS-DOS"? -- Bill Janssen
Newsgroups: comp.lang.tcl