How to use ttk::separator ?

[Richard Owlett]

I'm using http://tkdocs.com/tutorial/complex.html#separator as a guide.
The graphic in that section shows exactly what I want.

I try to add it to the object I'm creating. Unsuccessfully.

The Help system is lacking in detail/example.

Google and wiki searches do not turn up anything that appears informative.

[Bryan Oakley]

I'm usinghttp://tkdocs.com/tutorial/complex.html#separatoras a guide.
The graphic in that section shows exactly what I want.
I try to add it to the object I'm creating. Unsuccessfully.
The Help system is lacking in detail/example.
Google and wiki searches do not turn up anything that appears informative.

Without seeing your code it's impossible for us to figure out what is
wrong. At the very least, define "unsuccessfully". Do you get an
error, and if so, what error? If you don't get an error, what do you
get? Does the code run but the separator is invisible? If so, how are
you managing it (ie: what grid, pack or place options are you using?)

If possible, can you post your actual code here? We need to see both
where you create the widget and where you manage it (where you call
grid, pack or place).

[Richard Owlett]

Post by Bryan Oakley

I'm usinghttp://tkdocs.com/tutorial/complex.html#separatoras a guide.
The graphic in that section shows exactly what I want.
I try to add it to the object I'm creating. Unsuccessfully.
The Help system is lacking in detail/example.
Google and wiki searches do not turn up anything that appears informative.

Without seeing your code it's impossible for us to figure out what is
wrong.

I didn't post code as too many things might be wrong making correction
of it a not worthwhile task to answer my question. And the answer might
only apply to a specific case. Thats why I was looking for examples
[preferably multiple examples &/or more verbose description of statement].

Post by Bryan Oakley
At the very least, define "unsuccessfully". Do you get an
error, and if so, what error? If you don't get an error, what do you
get? Does the code run but the separator is invisible? If so, how are
you managing it (ie: what grid, pack or place options are you using?)

Nothing as in:
no error message
nothing visible

Post by Bryan Oakley
If possible, can you post your actual code here? We need to see both
where you create the widget and where you manage it (where you call
grid, pack or place).

My code *DOES NOT YET* perform any useful activity.
I am _ONLY_ working on layout.



package require Tk

wm title . "Test of ttk::separator"

grid [ttk::frame .p -padding "3 3 12 12"] -column 0 -row 0 -sticky nwes

grid columnconfigure . 0 -weight 1
grid rowconfigure . 0 -weight 1

grid [ttk::label .p.min_lbl -text "Min"] -column 1 -row 1 -sticky w
grid [ttk::label .p.max_lbl -text "Max"] -column 2 -row 1 -sticky w

grid [ttk::label .p.time_lbl -text "Time" ] -column 0 -row 2 -sticky w
grid [ttk::label .p.freq_lbl -text "Frequency"] -column 0 -row 3 -sticky w

grid [ttk::entry .p.t0 -width 7 -textvariable t0 ] -column 1 -row 2
-sticky w
grid [ttk::entry .p.tlast -width 7 -textvariable tlast] -column 2 -row 2
-sticky w
grid [ttk::entry .p.fmin -width 7 -textvariable fmin ] -column 1 -row 3
-sticky w
grid [ttk::entry .p.fmax -width 7 -textvariable fmax ] -column 2 -row 3
-sticky w

grid [ttk::label .p.offset_lbl -text "Offset"] -column 1 -row 5 -sticky w
grid [ttk::label .p.width_lbl -text "Width" ] -column 2 -row 5 -sticky w

grid [ttk::label .p.window_lbl -text "Window" ] -column
0 -row 6 -sticky w
grid [ttk::entry .p.toffset -width 7 -textvariable toffset ] -column
1 -row 6 -sticky w
grid [ttk::entry .p.width -width 7 -textvariable width ] -column
2 -row 6 -sticky w

# tried
# grid [ttk::separator .p.s -orient horizontal]
# and
# ttk::separator .p.s -orient horizontal
# among others
#
# wanted a separator above row of buttons


grid [ttk::button .p.2d -text "2D Plot" -command calculate] -column 0
-row 10 -sticky w
grid [ttk::button .p.3d -text "3D Plot" -command calculate] -column 2
-row 10 -sticky w


foreach w [winfo children .p] {grid configure $w -padx 5 -pady 5}
focus .p.t0
bind . <Return> {calculate}

proc calculate {} {
if {[catch {
set a 5]
}]!=0} {
set a 6
}
}

[Uwe Klein]

Richard Owlett wrote:
..............

Post by Richard Owlett
grid [ttk::entry .p.width -width 7 -textvariable width ] -column
2 -row 6 -sticky w
# tried
# grid [ttk::separator .p.s -orient horizontal]
# and
# ttk::separator .p.s -orient horizontal
# among others
#
# wanted a separator above row of buttons

think about which row, which column
think about what -sticky does, would it be needed here? I think yes.
lookup -columnspan, would it be userfull?

Post by Richard Owlett
grid [ttk::button .p.2d -text "2D Plot" -command calculate] -column 0
-row 10 -sticky w
grid [ttk::button .p.3d -text "3D Plot" -command calculate] -column 2
-row 10 -sticky w

If you can not manage your attention span adequately try to use a checklist
"What should go in a posting to comp.lang.tcl"

uwe

[Richard Owlett]

Post by Uwe Klein
..............

Post by Richard Owlett
grid [ttk::entry .p.width -width 7 -textvariable width ]
-column 2 -row 6 -sticky w
# tried
# grid [ttk::separator .p.s -orient horizontal]
# and
# ttk::separator .p.s -orient horizontal
# among others
#
# wanted a separator above row of buttons

think about which row, which column
think about what -sticky does, would it be needed here? I think yes.
lookup -columnspan, would it be userfull?

I had thought about those (and other associated) parameters.
That was part of the reason I did not include any code in my original
post. I did not think what I had was close enough to being correct to
make it worth while. I had noticed an apparent discrepancy between what
I could find about "separator" and all I had found concerning the
various geometry managers.

Post by Uwe Klein

Post by Richard Owlett
grid [ttk::button .p.2d -text "2D Plot" -command calculate] -column 0
-row 10 -sticky w
grid [ttk::button .p.3d -text "3D Plot" -command calculate] -column 2
-row 10 -sticky w

If you can not manage your attention span adequately try to use a checklist
"What should go in a posting to comp.lang.tcl"
uwe

I thought (erroneously) that I had said explicitly "Thats why I was
looking for examples [preferably multiple examples &/or more verbose
description of statement]." in my original post. It was in my second.

[Uwe Klein]

Post by Richard Owlett
I thought (erroneously) that I had said explicitly "Thats why I was
looking for examples [preferably multiple examples &/or more verbose
description of statement]." in my original post. It was in my second.

Thats from your side of the table.

From this side its: We don't do catwalks.

So c.l.t will not on request parade out a variety of solutions
just to make you happy.

So we are back to your original question!

If you don't post code we can't answer the Radio Jerewan question you put.

i.e. one cannot decide if it is a capital error or social error you make
or maybe even just a plain typo.

uwe

[Bryan Oakley]

Post by Richard Owlett
# tried
# grid [ttk::separator .p.s -orient horizontal]
# and
# ttk::separator .p.s -orient horizontal
# among others

It appears that what you need is not an example of a separator, but an
example of how to use grid.

if you want a widget -- any widget -- to span several columns in a
grid'ed parent you must tell grid to do that with the -columnspan
option. Without it your widget will only exist in a single cell.

Further, if you want a widget to fill it's alloted space in a grid'ed
parent you must use the -sticky option. Specifically, in your case you
want to add "-sticky ew" to get it to fill the cell(s) from side to
side.

Finally, to make the separator stand out you'll probably want to add a
little padding in the Y axis ("-pady 4" ought to do it)

[Richard Owlett]

Post by Bryan Oakley

Post by Richard Owlett
# tried
# grid [ttk::separator .p.s -orient horizontal]
# and
# ttk::separator .p.s -orient horizontal
# among others

It appears that what you need is not an example of a separator, but an
example of how to use grid.

That wasn't really my problem.
It was more related to not having grokked that ttk::separator,
ttk::entry, ttk::label, etc all operate on a "thingy" (given its path)
to return a different "thingy" (identified by its path).
["thingy" used to avoid creating more confusion by using wrong term ;]

That's why I ask to be pointed towards good code, rather than post my
know bad code. Especially when there may be a multiplicity unrelated
errors in it.

I've often heard the story that bank tellers are taught to recognize
counterfeit bills by much handling of the genuine article rather than
trying to identify whats wrong with a bogus bill.

Post by Bryan Oakley
if you want a widget -- any widget -- to span several columns in a
grid'ed parent you must tell grid to do that with the -columnspan
option. Without it your widget will only exist in a single cell.
Further, if you want a widget to fill it's alloted space in a grid'ed
parent you must use the -sticky option. Specifically, in your case you
want to add "-sticky ew" to get it to fill the cell(s) from side to
side.
Finally, to make the separator stand out you'll probably want to add a
little padding in the Y axis ("-pady 4" ought to do it)

[Bryan Oakley]

Here's more advice unrelated to your specific question, but related to
the code you posted:

You are using both pack and grid in the same master. Don't do that.
Both grid and pack will get in an endless loop as each attempts to
readjust the geometry that was changed by the other.

Second, I recommend *not* putting the grid command on the same line as
the widgets. Doing it your way may result is slightly fewer lines of
code but it makes the code harder to read and maintain. In other
words, instead of this:

grid [ttk::label .p.min_lbl -text "Min"] -column 1 -row 1 -sticky
w
grid [ttk::label .p.max_lbl -text "Max"] -column 2 -row 1 -sticky
w

do this:

ttk::label .p.min_lbl -text "Min"
ttk::label .p.max_lbl -text "Max"

grid .p.min_lbl
grid .p.max_lbl

One significant advantage is that it lets you group items into rows
without having to explicitly give row and column numbers. For example:

grid x .p.min_lbl .p.max_lbl
grid .p.time_lbl .p.t0 .p.tlast
grid .p.freq_lbl .p.fmin .p.fmax

Doesn't that make it _much_ easier to see what is going on? You can
then specify column spans using "-", as in:

grid .p.s - - -sticky ew

Doing the geometry separately also makes it easier to change your
layout without having to touch the code that creates the widgets.

[Richard Owlett]

Post by Bryan Oakley
Here's more advice unrelated to your specific question, but related to
You are using both pack and grid in the same master. Don't do that.
Both grid and pack will get in an endless loop as each attempts to
readjust the geometry that was changed by the other.

I don't see using "pack" explicitly anywhere in code I posted. Is it
there by implication? Everything I read on geometry managers cautioned
about mixing managers.

Post by Bryan Oakley
Second, I recommend *not* putting the grid command on the same line as
the widgets. Doing it your way may result is slightly fewer lines of
code but it makes the code harder to read and maintain. In other
grid [ttk::label .p.min_lbl -text "Min"] -column 1 -row 1 -sticky w
grid [ttk::label .p.max_lbl -text "Max"] -column 2 -row 1 -sticky w
ttk::label .p.min_lbl -text "Min"
ttk::label .p.max_lbl -text "Max"
grid .p.min_lbl
grid .p.max_lbl
One significant advantage is that it lets you group items into rows
grid x .p.min_lbl .p.max_lbl
grid .p.time_lbl .p.t0 .p.tlast
grid .p.freq_lbl .p.fmin .p.fmax
Doesn't that make it _much_ easier to see what is going on? You can
grid .p.s - - -sticky ew
Doing the geometry separately also makes it easier to change your
layout without having to touch the code that creates the widgets.

That makes some sense out of the "RELATIVE PLACEMENT" section of "Tcl/Tk
Documentation > TkCmd > grid".

I think this is another argument in favor of pointing newbies to good
code, rather than trying to fix their bad code.

[Bryan Oakley]

Post by Richard Owlett

Post by Bryan Oakley
Here's more advice unrelated to your specific question, but related to
You are using both pack and grid in the same master. Don't do that.
Both grid and pack will get in an endless loop as each attempts to
readjust the geometry that was changed by the other.

I don't see using "pack" explicitly anywhere in code I posted. Is it
there by implication? Everything I read on geometry managers cautioned
about mixing managers.

That was my bad. When I cut and pasted your code I accidentally left a
couple of lines of old code in the buffer. Sorry for the confusion.

[Richard Owlett]

Post by Bryan Oakley

Post by Richard Owlett

Post by Bryan Oakley
Here's more advice unrelated to your specific question, but related to
You are using both pack and grid in the same master. Don't do that.
Both grid and pack will get in an endless loop as each attempts to
readjust the geometry that was changed by the other.

I don't see using "pack" explicitly anywhere in code I posted. Is it
there by implication? Everything I read on geometry managers cautioned
about mixing managers.

That was my bad. When I cut and pasted your code I accidentally left a
couple of lines of old code in the buffer. Sorry for the confusion.

Been there. Done that. Have MANY t-shirts ;)

[Bryan Oakley]

Post by Richard Owlett
I think this is another argument in favor of pointing newbies to good
code, rather than trying to fix their bad code.

Maybe you're right, though in my experience most newbies are looking
to solve their immediate problems. Your original post didn't actually
ask for anything, so I had to assume you wanted help fixing your
actual code. This time apparently I guessed wrong about what you were
expecting. It happens. Sorry 'bout that.

Do you still need help or have you figured out how to create and use
separators?

[Richard Owlett]

Post by Bryan Oakley

Post by Richard Owlett
I think this is another argument in favor of pointing newbies to good
code, rather than trying to fix their bad code.

Maybe you're right, though in my experience most newbies are looking
to solve their immediate problems.

YEPP!
They eventually learn that they don't really learn much that way.
Being old and grey, I've learned ;)

Post by Bryan Oakley
Your original post didn't actually
ask for anything, so I had to assume you wanted help fixing your
actual code.

I really need a keyboard that reads my mind. I thought I had said that.
I had not.

Post by Bryan Oakley
This time apparently I guessed wrong about what you were
expecting. It happens. Sorry 'bout that.
Do you still need help or have you figured out how to create and use
separators?

Not at the moment. There will be. I got the separator working using code
as I had been laying things out. I've not quite finished moving to the
format you suggested. Next is plugging in the working code that I
already have so the GUI actually does something. Then the "Do I like
using it" question has to be answered.

[Richard Owlett]

Post by Bryan Oakley
Do you still need help or have you figured out how to create and use
separators?

After learning to spell variable names the same way twice and not
telling grid to put things in wrong place, it worked fine.

Now to debug the overall project spec.

Thanks for the help.

[Donald Arseneau]

Post by Bryan Oakley
Second, I recommend *not* putting the grid command on the same line as
the widgets.

Whereas I think it can be quite a reasonable coding style. It keeps
all the setup for a widget in one place.

Post by Bryan Oakley
ttk::label .p.min_lbl -text "Min"
ttk::label .p.max_lbl -text "Max"
grid .p.min_lbl
grid .p.max_lbl

wherein I see no advantage.

Post by Bryan Oakley
One significant advantage is that it lets you group items into rows
without having to explicitly give row and column numbers.

Which is great, but only in the simple cases where there are no
individual settings of padding and stickyness.

Donald Arseneau ***@triumf.ca

[Richard Owlett]

Post by Donald Arseneau

Post by Bryan Oakley
Second, I recommend *not* putting the grid command on the same line as
the widgets.

Whereas I think it can be quite a reasonable coding style. It keeps
all the setup for a widget in one place.

Post by Bryan Oakley
ttk::label .p.min_lbl -text "Min"
ttk::label .p.max_lbl -text "Max"
grid .p.min_lbl
grid .p.max_lbl

wherein I see no advantage.

There are readability advantages for the raw newbie. At least this one.
It emphasizes that there are two distinct operations being performed,
one by "grid" and one by "ttk::label".

Post by Donald Arseneau

Post by Bryan Oakley
One significant advantage is that it lets you group items into rows
without having to explicitly give row and column numbers.

Which is great, but only in the simple cases where there are no
individual settings of padding and stickyness.

It is also useful when doing a layout that is in a "rough draft" stage.
I can just cut and paste to move things around without worrying about
messing up line and column numbers.

[Bryan Oakley]

Post by Bryan Oakley
Second, I recommend *not* putting the grid command on the same line as
the widgets.

Whereas I think it can be quite a reasonable coding style.  It keeps
all the setup for a widget in one place.

Post by Bryan Oakley
    ttk::label .p.min_lbl -text "Min"
    ttk::label .p.max_lbl -text "Max"
    grid .p.min_lbl
    grid .p.max_lbl

wherein I see no advantage.

Post by Bryan Oakley
One significant advantage is that it lets you group items into rows
without having to explicitly give row and column numbers.

Which is great, but only in the simple cases where there are no
individual settings of padding and stickyness.

True enough, though that can be solved with a "grid configure" on the
unique items after laying them out. I definitely don't recommend it in
all cases, but in many simple situations it works great.

[Donald Arseneau]

Post by Bryan Oakley

Post by Donald Arseneau
Which is great, but only in the simple cases where there are no
individual settings of padding and stickyness.

True enough, though that can be solved with a "grid configure" on the
unique items after laying them out. I definitely don't recommend it in
all cases, but in many simple situations it works great.

Also, to argue against myself, a complex case with many options
on widget creation and positioning should be done with two separated
commands because it gets too messy to combine them.

Donald Arseneau ***@triumf.ca