[Tk] Scrollbar, placer, packer, size...

I'm trying to make ahh... some unusual thing with the scrollbar. :)

What I want to have is:

1. I have a group of frames (which contain buttons). Let's say that each
frame is "one button high" and wide for whole screen. Almost.

2. The number of frames is indeterminate (a file is being loaded and each li
ne
from this file comprises data for one frame).

3. User must have access to each frame, regardless of their number in the
window.

The only solution is to have a scrollbar, which will scroll the group of
frames. However...

I decided that there will be a frame, which will be maybe higher than the
window displaying it, but it will be placed, not packed. When I scroll down,
the frame will be placed with negative position in y and 0 in x.

One of the problems is how to determine the "hidden height", which has to
determine the "scrollsize" (size of the scrolling bar). Trying to obtain the
height of the "great frame" (into which the "data lines" were packed) result
ed
in 0. Also every particular data frame has height 0. How can I then obtain t
he
"hidden height" ?

Next, I decided that the "great frame" be placed into some other frame
(external frame, let's say), and the external frame be packed (to make the
data and the scrollbar laid out separately). Is that a good solution?

I tried to find some solution for this on wiki, but found nothing. Maybe
somebody knows an implementation for such a thing?


--
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"Java does not have pointers!"

Sektor van Skijlen wrote:
> I'm trying to make ahh... some unusual thing with the scrollbar. :)
>
> What I want to have is:
>
> 1. I have a group of frames (which contain buttons). Let's say that each
> frame is "one button high" and wide for whole screen. Almost.
[... various attempts at a solution deleted ...]
> I tried to find some solution for this on wiki, but found nothing. Maybe
> somebody knows an implementation for such a thing?

You're working too hard. :)

A typical solution to this sort of problem is to window a frame into
a canvas, and scroll the canvas:

canvas .c -width 600 -height 400 \
-xscrollcommand [list .x set] -yscrollcommand [list .y set]
scrollbar .x -command [list .c xview] -orient horizontal
scrollbar .y -command [list .c yview] -orient vertical

grid .c -row 0 -column 0 -sticky nsew
grid .y -row 0 -column 1 -sticky ns
grid .x -row 1 -column 0 -sticky ew
grid rowconfigure . 0 -weight 1
grid columnconfigure . 0 -weight 1

frame .c.f
for { set i 1 } { $i < 100 } { incr i } {
grid [button .c.f.b$i -text "Button \#$i"] \
[label .c.f.l$i -text "<- look to the left to see button \#$i!"]
}

.c create window 2 2 -window .c.f -anchor nw

bind .c <Configure> {
.c configure -scrollregion [.c bbox all]
}

Since you sound as if you're doing something that's very like a
form, you might instead want to consider windowing your buttons
into a text widget instead:

text .t -width 80 -height 24 \
-xscrollcommand [list .x set] -yscrollcommand [list .y set]
scrollbar .x -command [list .t xview] -orient horizontal
scrollbar .y -command [list .t yview] -orient vertical

grid .t -row 0 -column 0 -sticky nsew
grid .y -row 0 -column 1 -sticky ns
grid .x -row 1 -column 0 -sticky ew
grid rowconfigure . 0 -weight 1
grid columnconfigure . 0 -weight 1

for { set i 1 } { $i < 100 } { incr i } {
button .t.b$i -text "Button \#$i"
.t window create end -window .t.b$i -align center
.t insert end " <- look to the left to see button \#$i\n"
}

--
73 de ke9tv/2, Kevin

Dnia Tue, 19 Oct 2004 16:55:48 -0400, Kevin Kenny skrobie:
> Sektor van Skijlen wrote: 
> [... various attempts at a solution deleted ...] 

> You're working too hard. :)

You know... while someone has set 1280x1024 screen resolution, there is no
problem with using this tool. However some people already reported me that t
he
lines don't fit in window and a scrollbar is needed.

I was (negatively) surprised that it's so hard to deal with scrollbars in Tk
.
Until this case, everything in Tk's GUI management was easy. For example, I
don't understand, why I have to set upper/lower (in case of vertical -orient
)
positions of the bar instead of setting separately the scrolling size (size 
of
the scrolling bar) and the bar position. Also, why I must get back the
position when scrollbar emits "moveto" instead that scrollbar sets it itself
and I only had to corrrect it if it would be improper to set such a position
.

WinAPI, for example, provides - beside custom scrollbar - also automatic
scrollbars for whole window (horizontal and vertical). And, despite hardness
es
of using WinAPI at all, operating with scrollbars in WinAPI is much more eas
y
than in Tk.


--
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"Java does not have pointers!"

Sektor van Skijlen <ethouris@pl.spamu.lubie.nie.wp.invalid> writes:

> I was (negatively) surprised that it's so hard to deal with scrollbars in Tk.[/col
or]

Scroolbars are designed to be attached to specific widgets.  Making
them work with other widgets is not worth the trouble when you
can put your unusual widget into a supported widget like canvas.

Donald Arseneau                          asnd@triumf.ca

Donald Arseneau wrote:
> Scroolbars are designed to be attached to specific widgets.  Making
> them work with other widgets is not worth the trouble when you
> can put your unusual widget into a supported widget like canvas.

Hmm, I wonder what the cost of using a canvas instead of a dedicated
scrollable-frame widget is? (Probably not quite enough to justify a new
core widget though; if you have masses of scrolled frames about, you
perhaps should be considering a different GUI... :^)

Donal.

"Donal K. Fellows" <donal.k.fellows@manchester.ac.uk> writes:

> Donald Arseneau wrote: 
>
> Hmm, I wonder what the cost of using a canvas instead of a dedicated
> scrollable-frame widget is? (Probably not quite enough to justify a new
> core widget though; if you have masses of scrolled frames about, you
> perhaps should be considering a different GUI... :^)

I think a minimal scrolled holer (frame) widget would be valuable
in the core.

I'd also like to drop canvas for other misuses :-)


Donald Arseneau                          asnd@triumf.ca

Sektor van Skijlen wrote:
> You know... while someone has set 1280x1024 screen resolution, there is no
> problem with using this tool. However some people already reported me that
 the
> lines don't fit in window and a scrollbar is needed.
>
> I was (negatively) surprised that it's so hard to deal with scrollbars in 
Tk.
> Until this case, everything in Tk's GUI management was easy. For example, 
I
> don't understand, why I have to set upper/lower (in case of vertical -orie
nt)
> positions of the bar instead of setting separately the scrolling size (siz
e of
> the scrolling bar) and the bar position. Also, why I must get back the
> position when scrollbar emits "moveto" instead that scrollbar sets it itse
lf
> and I only had to corrrect it if it would be improper to set such a position.[/col
or]

Rather than complaining about the complexity of mostly-internal API's,
could I get you to look at the [canvas] solution I posted and explain
in what way it fails to solve your problem?  I realize that it's
*different* in coding style from win32, but does it do the right thing
in your application?  If not, can you enlighten us about what else
it needs to do, and we can look into it further?

Yes, using a canvas is perhaps overkill.  But: The canvas is already
there.  It works.  It doesn't cost all that much.

By the way, if you need the scrollbars to disappear when the window
is big enough to contain everything, you can simply copy and paste the
code from http://wiki.tcl.tk/950 - which, I believe, is also in tklib,
and call ::autoscroll::autoscroll on both scrollbars.  So if that's
your problem, it's solved by a library procedure and three lines of
code (a [package require] and two calls to autoscroll).

--
73 de ke9tv/2, Kevin

Donald Arseneau wrote:
> "Donal K. Fellows" <donal.k.fellows@manchester.ac.uk> writes: 
>
>
> I think a minimal scrolled holer (frame) widget would be valuable
> in the core.

How about the scrolled grid, from http://wiki.tcl.tk/10687 ?

It's a simple way to achieve the same thing.

/Peter

Peter Spjuth <peter.spjuth@space.se> wrote:
> How about the scrolled grid, from http://wiki.tcl.tk/10687 ?
> It's a simple way to achieve the same thing.

To me it seems the page describes some proposals, as opposed
to already working tricks.

anyway, there are some comments about it:
the -weight option to adding slaves is pretty ,
but I don't think it should ever cause errors to
be thrown.  If one slave's -weight-option is
at odds with a previous one, it should simply
overwrite it. (otherwise one would have to
distinguish default-values from previously set
values, which imho isn't worth the trouble.

The scrolled grid doesn't seem to deal with auto-hiding of
scrollbars.

I've seen (and also used) quite simple methods to auto-hide
scrollbars, but these simple ways always had a nasty effect:
Sometimes I have to make the window just a bit larger until the
scrollbars disappear and then reshrink it to have an exact fit.

Most other gui-toolkits (those that have widgets with builtin
scrollbars) can correctly determine the exact size-limit where
scrollbars are hidden or need to reappear.

Dnia Wed, 20 Oct 2004 10:55:55 -0400, Kevin Kenny skrobie:
> Sektor van Skijlen wrote: 

> Rather than complaining about the complexity of mostly-internal API's,
> could I get you to look at the [canvas] solution I posted and explain
> in what way it fails to solve your problem?

What a nervous :)
No, the solution you provided me succeeds to solve my problem perfectly.
That's exactly what I need.

> I realize that it's *different* in coding style from win32,

If I had preferred win32 GUI programming I wouldn't have made you bother wit
h
solving my problem in Tk. I choosen Tk not because its portability (the
application this problem concerns contains also local paths, so despite this
aplication works under windows, it's useless under windows), but because of
its simplicity.

> but does it do the right thing in your application?

Ehhh... yes. It does. I was only disgusted the way I have to do this. Not ju
st
directly that I have a widget which does not fit in its parent... Say, canva
s
is rather prepared to display drawings (or something like this) and the use 
of
it in this case is only because it well cooperates with scrollbars, nothing
more.

> If not, can you enlighten us about what else it needs to do, and we can lo
ok
> into it further?

I think scolling a grid, as it was proposed, is a good solution.

> Yes, using a canvas is perhaps overkill.

Ehh... say, exaggeration.

> But: The canvas is already there.  It works.  It doesn't cost all that much.[/colo
r]

Good.

But as I have Tk, very simple and (mostly) intuitive GUI toolkit, I expect
that it allow me to express just what I need. Using a canvas widget looks li
ke
a workaround, regardless of how much it is reasonable.

> By the way, if you need the scrollbars to disappear when the window
> is big enough to contain everything, you can simply copy and paste the
> code from http://wiki.tcl.tk/950 - which, I believe, is also in tklib,
> and call ::autoscroll::autoscroll on both scrollbars.  So if that's
> your problem, it's solved by a library procedure and three lines of
> code (a [package require] and two calls to autoscroll).

Good. I only expressed my opinion about the standard Tk's scrollbar
functionality. I never expected Tk, famous about easy GUI programming, would
have it done such a hard and unintuitive way.


--
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"Java does not have pointers!"