Home > Archive > Tcl > October 2004 > [Tk] Scrollbar, placer, packer, size...
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
[Tk] Scrollbar, placer, packer, size...
|
|
| Sektor van Skijlen 2004-10-19, 3:59 pm |
| 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 line
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) resulted
in 0. Also every particular data frame has height 0. How can I then obtain the
"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!"
| |
| Kevin Kenny 2004-10-19, 8:57 pm |
| 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
| |
| Sektor van Skijlen 2004-10-19, 8:57 pm |
| Dnia Tue, 19 Oct 2004 16:55:48 -0400, Kevin Kenny skrobie:
> Sektor van Skijlen wrote:
> [... various attempts at a solution deleted ...]
[color=darkred]
> 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 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 -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 hardnesses
of using WinAPI at all, operating with scrollbars in WinAPI is much more easy
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!"
| |
| Donald Arseneau 2004-10-19, 8:57 pm |
| 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.
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
| |
| Donal K. Fellows 2004-10-20, 4:07 pm |
| 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.
| |
| Donald Arseneau 2004-10-20, 4:07 pm |
| "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
| |
| Kevin Kenny 2004-10-20, 4:07 pm |
| 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 -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.
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
| |
| Peter Spjuth 2004-10-20, 4:07 pm |
| 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
| |
| Andreas Leitgeb 2004-10-20, 4:07 pm |
| 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.
| |
| Sektor van Skijlen 2004-10-20, 8:57 pm |
| Dnia Wed, 20 Oct 2004 10:55:55 -0400, Kevin Kenny skrobie:
> Sektor van Skijlen wrote:
[color=darkred]
> 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 with
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 just
directly that I have a widget which does not fit in its parent... Say, canvas
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 look
> 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.
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 like
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!"
| |
| Shaun Deacon 2004-10-20, 8:57 pm |
| Hmm...You could also use an extension such as Tix which has various
scrolled widgets where the scrollbar creation and management is
done for you :
tixScrolledHList
tixScrolledListBox
tixScrolledText
tixScrolledWindow
The tixScrolledWindow widget is a scrolled canvas. So :
tixScrolledWindow $w.scrolledWin -scrollbar auto
Would also do what you want (vertical and horizontal scrollbars are
automatically created when the window is not large enough to contain
the contents)
I believe BWidgets and Itk also have similar widgets...
Why re-invent the wheel ?
Only my 2 cents worth
Shaun
| |
| Peter Spjuth 2004-10-20, 8:57 pm |
| Andreas Leitgeb wrote:
> Peter Spjuth <peter.spjuth@space.se> wrote:
>
>
> To me it seems the page describes some proposals, as opposed
> to already working tricks.
Correct.
> 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.
Maybe. In what order should the slaves apply their weight?
Stacking order? Column/row order? Other?
Personally, I prefer an error since conflicting values are a
sure sign that I have done something wrong. Plus the semantics
and implementation gets simpler.
> The scrolled grid doesn't seem to deal with auto-hiding of
> scrollbars.
No. With the current scrollbar interface a "scrollee" has no
way of handling that since it does not know what scrollbar(s)
it is attached to.
Theoretically the scrollbar itself could handle auto-hiding,
but I think that is the job of a higher level mechanism such
as a megawidget.
/Peter
| |
| Donal K. Fellows 2004-10-21, 8:57 am |
| Andreas Leitgeb wrote:
> No, the scrollbar cannot do it *properly*, because for this it
> would also need to know, whether its disappearing would allow
> the other direction's scrollbar to disappear as well, and whether
> the space gained from autohiding the other bar actually allows
> the scrollbar to hide in the first place.
I've seen auto-hiding scrollable-window implementations in other
toolkits, and they tend to have the di vantage that they require a
real widget to be embedded within themselves. This limits the size of
contents that can be displayed quite a lot (e.g. to a bit under 6000
lines of text at typical font sizes[*]). The advantage that the current
scrolling interface has is that it can act on the virtual data space
instead of having to be applied to widgets.
Pick your trade-off; Tk picks one way.
Donal.
[* Widget dimensions must be expressable in a short. This sucks but
isn't our design decision. ]
| |
| Andreas Leitgeb 2004-10-21, 4:04 pm |
| Donal K. Fellows <donal.k.fellows@manchester.ac.uk> wrote:
> Andreas Leitgeb wrote:
[color=darkred]
> I've seen auto-hiding scrollable-window implementations in other
> toolkits, and they tend to have the divantage that they require a
> real widget to be embedded within themselves. This limits the size of
> contents that can be displayed quite a lot (e.g. to a bit under 6000
> lines of text at typical font sizes[*]). The advantage that the current
> scrolling interface has is that it can act on the virtual data space
> instead of having to be applied to widgets.
>
> Pick your trade-off; Tk picks one way.
This isn't a question of tradeoff.
Two points:
a) autohiding of scrollbars:
The canvas (and text) could recognize the situation, where the
whole scrollregion would fit into the physical window, if
the window was just <n> pixels larger. It would have to be
told how much space <n> it would gain by hiding the scrollbar,
and the ".sb set"-api might be enhanced by some special value
which would cause .sb to disappear (change width to 0). Of
course, for compatibility, the canvas would emit these new
values only, if it has been previously told the value <n>;
this guarantees compatibility with scripts that intercept
the scrollcommands (and couldn't handle new values).
The gain seems quite marginal at first glance, but non-hiding
scrollbars or scrollbars that only hide if the window is temporarily
made larger are just one subtle hint for non-professional looking
apps. Imho it's more important than pattern-backgrounds.
b) avoiding the canvas by an autoscrolling frame widget.
This might induce a limitation on the scrollable region, but
depending on the situation (what are the contents to be scrolled)
this is often a non-issue. Often it is about some forms, that can
be just larger than a reasonable windowsize would allow, but still
orders of magnitude smaller than the 16bit widget-size limits.
|
|
|
|
|