I've been working on a new project and I am struggling with positioning panedwindows.
Luc <luc@sep.invalid> posted:
I've been working on a new project and I am struggling with positioning
panedwindows.
See: https://tkdocs.com/tutorial/index.html
There is no Royal road to (Tk) geometry.
On Sat, 14 Feb 2026 08:24:20 GMT, Colin Macleod wrote:
Luc <luc@sep.invalid> posted:**************************
I've been working on a new project and I am struggling with positioning
panedwindows.
See: https://tkdocs.com/tutorial/index.html
There is no Royal road to (Tk) geometry.
That doesn't help someone who has the manual and has been "trying
everything until it works" and even trying ChatGPT.
Besides, I can't open it even with two Internet providers.
Are you blocking countries?
On 2/14/2026 8:19 AM, Luc wrote:
That doesn't help someone who has the manual and has been "trying
everything until it works" and even trying ChatGPT.
Besides, I can't open it even with two Internet providers.
Are you blocking countries?
I use Claude.ai and find it works much better with tcl/tk than chatgpt.
On 2/14/2026 7:48 PM, et99 wrote:
On 2/14/2026 8:19 AM, Luc wrote:
That doesn't help someone who has the manual and has been "trying
everything until it works" and even trying ChatGPT.
Besides, I can't open it even with two Internet providers.
Are you blocking countries?
I use Claude.ai and find it works much better with tcl/tk than chatgpt.
Encouraged by your frequent success stories on these ai bots, I spent a lot of time today with them. With minor variations, they all produced similar results.-a But overall, I was left frustrated as I wasted time trying their recommendations which included non-existent, imaginary command names, packages, and blaring mistakes. Here are a few:
Overall, they do offer insights into a solution but you must be willing to spend time to find it and improve on it. This is more difficult if you are new to a domain or a package.
1) "sock" is undefined:
proc Direct_Url_/upload/simple {args} {
-a-a-a global uploadDir
-a-a-a upvar #0 Httpd$sock data
...
2) this is not how split works in tcl:
# Split by boundary
set boundary "--$boundary"
set parts [split $postData $boundary]
3) many uses of commands that simply don't exist. But I admit would be quite helpful if they did.
I use Claude.ai and find it works much better with tcl/tk than chatgpt.
I showed your code to the Claude and we found several issues. For one, on >windows (where I tested), you need
wm state $::w zoomed (or withdrawn)
not -zoomed 0/1
But the big problem was you're not waiting for the windows to render
before you ask for their sizes. I added some waits and did a full update
(not just idletasks).
Before that, I found a sash on the far right that was hiding all the stuff >you put into that panel. Then I changed horizontal to vertical on the
panel on the left that needs to be sub-divided.
Also, everything is so large in that skeleton builder that when it did >finally get rendered, the vertical sash was almost all the way to the
left, but at least now visible.
And that last line starts with $if which is likely a typo.
But the big problem was you're not waiting for the windows to render before you ask for their sizes. I added some waits and did a full update (not just idletasks).
Here is a diff of the code. I threw in my wait routine to delay a bit (in**************************
the event loop, uses vwait) where you were doing an update idletasks and
use update alone.
et99 <et99@rocketship1.me> posted:
But the big problem was you're not waiting for the windows to render before you ask for their sizes. I added some waits and did a full update (not just idletasks).
It seemed inextricable, but AI seems useful in this desperate case...
Is this you or the AI that was able to guess the flow of appearance ? It is puzzling.
Olivier
On 2/15/2026 5:10 PM, et99 wrote:
I got interested in this problem when Luc mentioned using chatgpt. Since I've been using Claude with great success, I thought I would give it a shot.
To be honest, I found Luc's coding style to be a bit forbidding with too much indirection for my tastes, and I didn't want to decipher what the code was doing.
I agree with that sentiment. It is difficult to offer help when there is minimal explanation but lots of code.
So what is it supposed to do?
Maybe something like this?
package req Tk
On 2/15/2026 5:10 PM, et99 wrote:
I got interested in this problem when Luc mentioned using chatgpt. Since
I've been using Claude with great success, I thought I would give it a
shot.
To be honest, I found Luc's coding style to be a bit forbidding with too
much indirection for my tastes, and I didn't want to decipher what the
code was doing.
I agree with that sentiment. It is difficult to offer help when there is minimal explanation but lots of code.
So what is it supposed to do?
I have, IIRC, more than a few times mentioned to Luc that when asking
for help here that he should post a minimal script that exhibits the >problem. I have noticed that despite those requests, the "it's broken"
code examples continue to contain extras that make it hard for us >(volunteers I might add) to figure out what is going on, much less what
is going wrong. So for this post of his, I took a short look, saw a
lot of extraneous code, and decided to move along.
On Mon, 16 Feb 2026 01:30:27 -0000 (UTC), Rich wrote:
I have, IIRC, more than a few times mentioned to Luc that when asking
for help here that he should post a minimal script that exhibits the >>problem. I have noticed that despite those requests, the "it's broken" >>code examples continue to contain extras that make it hard for us >>(volunteers I might add) to figure out what is going on, much less what
is going wrong. So for this post of his, I took a short look, saw a
lot of extraneous code, and decided to move along.
**************************
Fair criticism, but note that it involves Tk (as usual).
Perhaps you will also remember that I have also been reprimanded
for not posting enough code. One day, not enough. Another day, too
much. It's hard to get that right.
What would a minimal script be like? I am not sure because I don't
know where the problem is.
If you really want to see what I am trying to achieve, there is
a video here:
https://limewire.com/d/Savgx#exppOUDS5H
On Sun, 15 Feb 2026 00:56:19 -0800, et99 wrote:
Here is a diff of the code. I threw in my wait routine to delay a bit (in >>the event loop, uses vwait) where you were doing an update idletasks and >>use update alone.**************************
This is my one concern here. "A wait routine" to "delay a bit."
How much is "a bit"? How do we even know how much wait is enough?
I need some way to make Tk do it right. When it thinks it's right
should not be my problem, Tk should manage it.
On 2/15/2026 5:10 PM, Luc wrote:
If you really want to see what I am trying to achieve, there is
a video here:
https://limewire.com/d/Savgx#exppOUDS5H
Ah, I see that you actually do want the left 2 panes to be side by
side. So, changing that value to vertical, as I did was not needed. However, it also works as horizontal with the panes on top of each
other. The problem was really the timing.
Rich's point about making the code more event-driven, is probably the
right thing to do.
I asked Claude what he thought of that and here is his answer:
(notice he still gets the ;# on line comment wrong) - I didn't test
this however.
Yes, the `<Configure>` event approach would work and is actually the **proper** way to handle this in Tcl/Tk! It's more reliable than
trying to guess when geometry is ready with `update` calls.
**How it works:**
```tcl
# Set a flag to prevent multiple repositionings
set ::sash_positioned 0
bind $::BOXFRAME <Configure> {
if {!$::sash_positioned} {
set ::sash_positioned 1
# Now we have ACTUAL rendered geometry
set w [winfo width $::BOXFRAME] # actual width, not reqwidth
set sw [winfo screenwidth .]
if {$::PANEL_IS_ON_RIGHT == 1} {
set w [expr {$sw - $w}]
$::of.pw_maincontainer sashpos 0 $w
}
}
}
```
**Is it more difficult?**
Not really - it's actually **cleaner** in some ways:
**Pros:**
- Works reliably - you get actual rendered sizes, not guesses
- No need for multiple `update` calls and waiting
- Handles window resizing automatically if you want
- More "correct" event-driven approach
**Cons:**
- Slightly different mental model (event-driven vs procedural)
- Need to guard against multiple firings with a flag
- Code is split between setup and callback
For this specific case, I'd say the `<Configure>` approach is
actually **simpler and more robust** than the current mess of `update`/`wait` calls. The flag prevents cascading, and you only
reposition once when the geometry is actually ready.
The original code was trying to be procedural in an event-driven GUI framework, which is why it's struggling!
On Sun, 15 Feb 2026 18:41:18 -0500, saito wrote:
Maybe something like this?**************************
package req Tk
Your prototype looks good. Thanks. I will study it.
Two problems, though.
1. The vertical divider can't be dragged. In my design, it can.
2. I need the proc to create panedwindows in an arbitray parent
widget, so I can use it as a kind of reusable building block.
The video wasn't clear for me. Is that the code behind your screens or are you building an editor?
In any case, here is a second version that has both horizontal and vertical dividers. You can increase/reduce button frame left and right, and reduce/increase the two text frames on the left vertically.
You should be able to make a proc out of this if you want multiple of them. You can send them the top widget name.
On 2/16/2026 10:01 AM, saito wrote:
The video wasn't clear for me. Is that the code behind your screens or
are you building an editor?
In any case, here is a second version that has both horizontal and
vertical dividers. You can increase/reduce button frame left and
right, and reduce/increase the two text frames on the left vertically.
You should be able to make a proc out of this if you want multiple of
them. You can send them the top widget name.
That is a quite nice example. It demonstrates how one builds frames
separate from the panes. It is often useful to have a way to view the hierarchy, and for that I have several tools I use to display the widget tree. Here we can see that there is a nested pained window:
The tool to print the hierarchy is nice too.
On 2/16/2026 11:47 AM, saito wrote:
The tool to print the hierarchy is nice too.
proc ltree {{root .} {level 0}} { # list widget tree
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 59 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 20:57:39 |
| Calls: | 810 |
| Calls today: | 1 |
| Files: | 1,287 |
| D/L today: |
11 files (21,026K bytes) |
| Messages: | 194,568 |