tackling the packer
k:arel
8.4 and tixwish8.1.8.3)
i add 2 frames to a master frame, named ".bottom", i've set different
colours so you can follow up my explanation
NB: you should maximize your window first!
* the master frame, .bottom, is coloured green
so everything green showing means the other frames don't expand like
they should do
* the top subframe, .bottom.fr_tit, is coloured red and is working
fine: it is at the top of the window and only expanded over X
* the lower subframe, .bottom.fr_can, is coloured blue and is NOT
working fine: for some reasen, it glues to the bottom and is NOT
expanding over Y (it is over X)
we're not seeing anything blue, but all green thus i've a fault
somewhere
but i AM adding the both subframes with "-side top", so normally they
should both be at the top of the window
the goal is: all the subframes, .bottom.fr_tit and .bottom.fr_can,
aligned at the top and only .bottom.fr_can expanded
my code
************************************************************
set fr ""
###
# extra, BOTTOM frame
##
eval frame ${fr}.bottom -background green
pack ${fr}.bottom -side top -padx 10 -pady 5 -fill both -expand 1
# frame for title of the BOTTOM frame
eval frame ${fr}.bottom.fr_tit -background red
pack ${fr}.bottom.fr_tit -side top -anchor n -fill x -expand 1
eval label ${fr}.bottom.fr_tit.lblTitle \
-borderwidth 1 \
-text {"Choosen checks"}
pack ${fr}.bottom.fr_tit.lblTitle -side left -anchor nw
###
# place "Required fields" label
##
eval label ${fr}.bottom.fr_tit.lblRequired \
-borderwidth 1 \
-text {"all fields are required"}
pack ${fr}.bottom.fr_tit.lblRequired -side right -anchor se -padx 5
###
# write all the checks + options-to-set in the BOTTOM frame
##
eval frame ${fr}.bottom.fr_can -background blue
pack ${fr}.bottom.fr_can -side top -anchor n -fill both -expand 1
set w ${fr}.bottom.fr_can
###
# creating the canvas and frame in canvas
##
# set a vertical scrollbar for the checks-containing frame
# you need a canvas for a "scrolling frame"
eval canvas ${w}.canvas -relief sunken \
-borderwidth 0 -highlightthickness 0 -background Gray90 \
-yscrollcommand {"${w}.yscroll set"}
eval scrollbar ${w}.yscroll -orient vertical \
-command {"${w}.canvas yview"}
# let it scroll, let it scroll, ...
eval bind ${w}.canvas <4> {"${w}.canvas yview scroll -1 units"}
eval bind ${w}.canvas <5> {"${w}.canvas yview scroll 1 units"}
pack ${w}.yscroll -side right -fill y
pack ${w}.canvas -side top -anchor n -fill both -expand 1
Bryan Oakley
> eval frame ${fr}.bottom -background green
Are you aware that the eval is totally unnecessary in this situation?
Casually using eval in this way will eventually get you in trouble. If
you don't understand how it will get you in trouble then you definitely
should not be using it.
> pack ${fr}.bottom -side top -padx 10 -pady 5 -fill both -expand 1
>
> # frame for title of the BOTTOM frame
> eval frame ${fr}.bottom.fr_tit -background red
> pack ${fr}.bottom.fr_tit -side top -anchor n -fill x -expand 1
>
> eval label ${fr}.bottom.fr_tit.lblTitle \
> -borderwidth 1 \
> -text {"Choosen checks"}
Here's an example of why eval is a bad idea. Notice how you're having to
add extra quotes in the -text option. Remove the eval and you won't need
to use both {} and "".
As a rule of thumb, only use eval when you absolutely must, and be
pretty rigid in your definition of "absolutely must".
As for the pack problem... your problem is here:
pack ${fr}.bottom.fr_tit -side top -anchor n -fill x -expand 1
Change "-expand 1" to "-expand 0". You're telling the top subframe to
expand to fill any extra space, and so it is.
Gerald W. Lester
> i'm experiencing some trouble here working with the packer (TCL-version
> 8.4 and tixwish8.1.8.3)
>
> i add 2 frames to a master frame, named ".bottom", i've set different
> colours so you can follow up my explanation
> NB: you should maximize your window first!
>
> * the master frame, .bottom, is coloured green
> so everything green showing means the other frames don't expand like
> they should do
>
> * the top subframe, .bottom.fr_tit, is coloured red and is working
> fine: it is at the top of the window and only expanded over X
>
> * the lower subframe, .bottom.fr_can, is coloured blue and is NOT
> working fine: for some reasen, it glues to the bottom and is NOT
> expanding over Y (it is over X)
>
> we're not seeing anything blue, but all green thus i've a fault
> somewhere
> but i AM adding the both subframes with "-side top", so normally they
> should both be at the top of the window
>
> the goal is: all the subframes, .bottom.fr_tit and .bottom.fr_can,
> aligned at the top and only .bottom.fr_can expanded
While someone else has answered your question -- you may want to consider
using the grid geometry manager instead of the packer. I suspect you will
find it easier to use.
--
+--------------------------------+---------------------------------------+
| Gerald W. Lester | "The man who fights for his ideals is |
| Gerald...@cox.net | the man who is alive." -- Cervantes |
+--------------------------------+---------------------------------------+
Melissa Schrumpf
> While someone else has answered your question -- you may want to consider
> using the grid geometry manager instead of the packer. I suspect you will
> find it easier to use.
"Easier" depending on purpose. Using [grid], it's easier to layout
widgets in, well, a grid. Unfortunately, you have to keep track of
column and row numbers.
Having started with [pack], I find the fact that you need to
columnconfigure and rowconfigure grid weights in order to get -expand
functionality, rather than giving both options as one would with -expand
and -fill to [pack]. That said, the ability to set proportional
expansion with weight is a major plus for [grid].
It's all a matter of preference. Like laying things out in a table?
Enjoy [grid]. Like not having to count rows and columns all day? Use
[pack]. Enjoy counting pixels? [place] is for you. :-)
Just don't try mixing them at the same level. You can pack things
inside of a [grid]ed frame, I had a horrible problem when I accidentally
[pack]ed .frame0 and used [grid] on .frame1 ... the window never
completed drawing to screen, and pegged the processor load.
--
MKS
Quokka
> Gerald W. Lester wrote:
>
>
>>While someone else has answered your question -- you may want to consider
>>using the grid geometry manager instead of the packer. I suspect you will
>>find it easier to use.
>
>
> "Easier" depending on purpose. Using [grid], it's easier to layout
> widgets in, well, a grid. Unfortunately, you have to keep track of
> column and row numbers.
Depends: I generally use [grid] in preference to pack
for very simple layouts, allowing the position in the grid
declarations to arrange every thing.
For example:
grid .logo .config_path - - .select_file
grid ^ .pick_console .set_path .run_console .exit
keithv
> Melissa Schrumpf wrote:
>> Gerald W. Lester wrote:
>>>While someone else has answered your question -- you may want to consider
>>>using the grid geometry manager instead of the packer. I suspect you will
>>>find it easier to use.
>>
>> "Easier" depending on purpose. Using [grid], it's easier to layout
>> widgets in, well, a grid. Unfortunately, you have to keep track of
>> column and row numbers.
>
> Depends: I generally use [grid] in preference to pack
> for very simple layouts, allowing the position in the grid
> declarations to arrange every thing.
>
> For example:
>
> grid .logo .config_path - - .select_file
> grid ^ .pick_console .set_path .run_console .exit
Yes, but if you want to get the equivalent of pack's -expand, you
need to track row and column numbers to configure them.
Keith
Donald Arseneau
> Yes, but if you want to get the equivalent of pack's -expand, you
> need to track row and column numbers to configure them.
Wasn't there a -weights <list> being added to grid? I thought
I remembered discussion of that, but don't see it in the 8.5
preliminary manual.
--
Donald Arseneau as...@triumf.ca
Gerald W. Lester
> Gerald W. Lester wrote:
>
>
>>While someone else has answered your question -- you may want to consider
>>using the grid geometry manager instead of the packer. I suspect you will
>>find it easier to use.
>
>
> "Easier" depending on purpose. Using [grid], it's easier to layout
> widgets in, well, a grid. Unfortunately, you have to keep track of
> column and row numbers.
Actually you don't have to keep track of column and row numbers, you can
use relative placement (see the "RELATIVE PLACEMENT" section of the grid
man/help page).
> Having started with [pack]...
I too started with pack, mostly because it was the only geometry manager
available at the time.
> Just don't try mixing them at the same level. You can pack things
> inside of a [grid]ed frame, I had a horrible problem when I accidentally
> [pack]ed .frame0 and used [grid] on .frame1 ... the window never
> completed drawing to screen, and pegged the processor load.
Actually you should never try to mix two geometry managers at the same
level -- although you can get by with mixing place with either pack or grid.
R. T. Wurth
news:UwsNe.6505$A33.5593@lakeread06:
> Melissa Schrumpf wrote:
>> Gerald W. Lester wrote:
>>
>>
[[discussion of geoemetry managers, pack vs. grid snipped]]
My favorite geo mgr is "it depends". Frequently I use combinations. The
project I work on has some standard decorations, namely a company
proprietary notice and a hint-text bar that go at the bottom of every
toplevel window. The routine that builds these for us always packs, so all
of our toplevels must be packed. When we need a grid, we pack a full-width
frame, and grid widets into that.
For example, one common pattern throughout our code is a "simple admin
detail screen", which typically creates or edits a database record. After
creating our standard decoration, we typically pack -side top a frame and
in this frame we grid rows comprising a fixed label and a setting widget,
which might be an entry, a tk_menu, or a button that invokes a modal
calendar dialog, for example. We use some combination of -sticky and -
anchor to get the labels right justified, so they butt up against the data
setting widget with suitable padding for separation. Then, below this, we
pack our action buttons, e. g. Clear, Update, Reset, Cancel, etc. in a row
across the bottom.
Another pattern we use a lot (a view-managed table) has a table at the top,
displayed in a packed (-side top) V&H scrolled listbox, a frame containing
a row of 3 (packed) buttons for invoking modal dialogs for controlling the
selection, formatting, and sorting of the database records displayed, and
then a application-specific area. Sometimes the application-specific area
is like a simple admin detail screen, a packed frame containing gridded
widgets, sometimes it's just a field of buttons for acting on selected
records.
Occasionally, I've even packed a row of buttons into a frame gridded to
span all columns in the last row of a grid.
My conclusion is that Tk is amazingly flexible, but one isn't really using
it's full potential unless one is equally familiar and comfortable with
both geo mgrs, and carefully considers which is better for the task at
hand, based on the characteristics of the problem at hand, and not on the
author simply choosing his/her favorite.
--
Rich Wurth / rwu...@att.net / Rumson, NJ USA
Gerald W. Lester
> "Gerald W. Lester" <Gerald...@cox.net> wrote in
> news:UwsNe.6505$A33.5593@lakeread06:
>
>
>>Melissa Schrumpf wrote:
>>
>>>Gerald W. Lester wrote:
>>>
>>>
> [[discussion of geoemetry managers, pack vs. grid snipped]]
>
>
> My conclusion is that Tk is amazingly flexible, but one isn't really using
> it's full potential unless one is equally familiar and comfortable with
> both geo mgrs, and carefully considers which is better for the task at
> hand, based on the characteristics of the problem at hand, and not on the
> author simply choosing his/her favorite.
Yes, Tcl is amazingly flexible. Your recommendation to "carefully
considers which is better for the task at hand, based on the
characteristics of the problem at hand" is excellent advise.
BTW, Tk has three geometry manager grid, place and pack -- not two. Place
is useful in certain situations and can even deal with resizing, however it
is by far the least used (I admit it was put in for some special case
senerios).
Also the panedwindow is considered by some to have some geometry manager
characteristics.
Jeff Hobbs
>> [[discussion of geoemetry managers, pack vs. grid snipped]]
>>
>> ...
>>
>> My conclusion is that Tk is amazingly flexible, but one isn't really
>> using it's full potential unless one is equally familiar and
>> comfortable with both geo mgrs, and carefully considers which is
>> better for the task at hand, based on the characteristics of the
>> problem at hand, and not on the author simply choosing his/her favorite.
>
>
> Yes, Tcl is amazingly flexible. Your recommendation to "carefully
> considers which is better for the task at hand, based on the
> characteristics of the problem at hand" is excellent advise.
>
> BTW, Tk has three geometry manager grid, place and pack -- not two.
> Place is useful in certain situations and can even deal with resizing,
> however it is by far the least used (I admit it was put in for some
> special case senerios).
>
> Also the panedwindow is considered by some to have some geometry manager
> characteristics.
panedwindow, text, canvas, and the Tktable widget will all
server as geometry managers.
FWIW, grid *is* the best. I have spoken. ;)
--
Jeff Hobbs, The Tcl Guy
http://www.ActiveState.com/, a division of Sophos
PS: for those who like to debate, sure, pack can be used in
various situations easier than grid, but it does not "compose"
as well as grid. I will back up my endorsement by noting that
I use grid 99% of the time, and I have written *LOTS* of UI
code, including megawidgets with half a dozen systems. grid
has lots of tricks up it's sleeve. It's well worth learning,
and noting that 8.4 and 8.5 have enhancements to grid.
k:arel
style (or font) defined for that specific frame (for unification
overall the application)
pe:
eval frame ${w}.bottomframe $::s_frame
i've noticed the problems with quoting and {}'s as you said, but adding
extra {}'s mostly solves the problem
k:arel
comparing of the geometry managers, it will be handy when writing my
thesis :-)
@bryan: thanks, frames are working out fine right now!