Windownamager geometry problem
Matthias Meier
I have the problem that on an Windows-Pc the geometry of widgets isn't calculated
right, as long as the widgets are not drawn on the display.
(tcl-Version is un both cases 8.3.4)
on Windows:
> toplevel .t
> wm withdraw .t
> wm geometry .t
200x200+....
> text .t.t
> grid .t.t
> wm geometry .t
200x200+.... <---?????
> wm deiconify .t
> wm geometry .t
566x366+.....
on Linux:
> toplevel .t
> wm withdraw .t
> wm geometry .t
200x200+....
> text .t.t
> grid .t.t
> wm geometry .t
566x318+..... <---!!!!!
> wm deiconify .t
> wm geometry .t
566x318+.....
As you can see in my example, on Linux the dimnesions of the toplevel are changed
after the grid - on windows the dimensions are changed after the widget is displayd.
Is this a bug in the Windows version?
Is there any work-around?
I want to build the user interface and change the size of the toplevel
depending on the size of some Widgets. So I have to 'wm deiconify/ wm withraw' the toplevel always before I
calculate the geometry which doesn't look nice to the user.
Thank for all help
Matthias
--------------------------------------------------------------------
Matthias Meier mailto:me...@fuh.de
Fornoff und Heintzenberg GmbH Telefon: +49 (0)7665 937-0
Am Laidhölzle 9 Fax : +49 (0)7665 937-150
D - 79224 Umkirch
--------------------------------------------------------------------
Helmut Giese
HTH
Helmut
Matthias Meier
Matthias
Helmut Giese schrieb:
>
> I have no time to try it out, but maybe 'update' will help.
> HTH
> Helmut
--
Tom Wilkason
The wm command works differently on differnt window managers. To find out the info
you are looking for, try the [winfo reqwidth .t] & [winfo reqheight .t] commands.
These are what Tk uses to compute the size that is requested to the window manager.
That being said, you may not need to use the wm geometry command. The toplevel will
automatically resize itself for its contents (e.g. when you add/remove/resize the
contained widgets). What exactly are you trying to do?
Tom Wilkason
Bryan Oakley
the addition of "update idletasks" after gridding the text widget):
toplevel .t
wm withdraw .t
puts "geometry immediately after withdraw: [wm geometry .t]"
text .t.t
grid .t.t
update idletasks
puts "geometry after gridding a text widget: [wm geometry .t]"
wm deiconify .t
puts "geometry after deiconifying: [wm geometry .t]"
exit 0
I get the following output:
geometry immediately after withdraw: 1x1+0+0
geometry after gridding a text widget: 486x318+110+110
geometry after deiconifying: 486x318+110+110
Does this help? Or maybe this is something that was broken in 8.3 (I don't
presently have 8.3 installed to try it out...)
Kevin Kenny
> I have the problem that on an Windows-Pc the geometry of widgets isn't calculated
> right, as long as the widgets are not drawn on the display.
That's actually pretty fundamental to the way Tk works, but I strongly suspect
that you can get all the information you need to do whatever it is you're
attempting. There are actually three geometries to consider.
1. What the widgets themselves have requested.
When a widget is configured, it immediately asserts the width and height
that it wants to be. The [winfo reqwidth] and [winfo reqheight] commands
retrieve this width and height, which are always available.
If the widget is the master in a geometry manager (grid, pack, place,
and the 'window' subcommands of [text] and [canvas]), then [winfo
reqwidth] and [winfo reqheight] will reflect the space that the widget
needs to contain its slave widgets. There's a caveat here, though, that
the space isn't actually computed until an idle callback (there are
sound performance reasons for this). So if you're dealing with code that
needs requested size of a widget with managed geometry, you have to
defer to that point. You can use [update idletasks] for this, but
I dislike the practice of entering the event loop recursively; I prefer
to launch the geometry-dependent code using [after idle].
2. What has been requested of the window manager.
The [wm geometry] command sets and returns the geometry that a toplevel
window has hinted to the window manager that it needs. This is generally
the least useful to query; it's used primarily to put toplevel windows
at particular places on the screen, for instance, to center a dialog box
over its parent.
3. What the widget actually got.
The actual geometry of a widget isn't calculated until the first time the
widget is displayed. How could it be otherwise? Remember that the window
manager might not give a toplevel widget its requested size. In fact,
small toplevels almost always get more space than they ask for, to
accommodate the window manager decorations. Toplevels larger than the
screen are typically resized downward. Most window managers also let the
user resize on demand.
When the size, position and stacking of a window are determined, a
<Configure> event arrives; at this time, [winfo width], [winfo height],
[winfo x], [winfo y], [winfo rootx], [winfo rooty], ... are all
determined. One of the side effects of a <Configure> on a geometry
master is that the geometry manager (gridder, packer, placer, ... )
slices up the space given to the master and configures the slaves.
What does all this mean?
Generally speaking, if you're trying to place or size widgets according
to the placement or size of other widgets, you'll want to do that in a
<Configure> binding -- or at least, that's the best practice. I consider
any answer that involves [update] or [tkwait] inferior to <Configure>.
(See http://wiki.tcl.tk/UpdateConsideredHarmful if you want to know why.)
Here's an example that displays a dialog 50 pixels below the
bottom edge of its parent:
# Procedure that adjusts the geometry of toplevel $t, to
# place it 50 pixels below toplevel $w.
proc fixup { t w } {
if { [string compare . $w] } return
set geom [wm geometry $w]
regexp {^([0-9]*)x([0-9]*)[+]([0-9]*)[+]([0-9]*)} $geom -> w h x y
set y2 [expr { $y + $h + 50 }]
wm geometry .t ${w}x[winfo reqheight .t]+${x}+${y2}
}
# Create the main window.
grid [label .l -text {This label contains rather a lot of text, and is used
to make a window of unknown size}]
wm group . .
# Create the transient dialog
toplevel .t
grid [label .t.l -text {This window should appear 50 pixels
below the other one}]
wm transient .t .
wm group .t .
# Set up to reconfigure the transient dialog to track its
# parent's geometry.
bind . <Configure> [list fixup .t %W]
There is another example at http://wiki.tcl.tk/CenteringAWindow
--
73 de ke9tv/2, Kevin KENNY GE Corporate R&D, Niskayuna, New York, USA
Richard.Suchenwirth
> # Procedure that adjusts the geometry of toplevel $t, to
> # place it 50 pixels below toplevel $w.
>
> proc fixup { t w } {
> if { [string compare . $w] } return
> set geom [wm geometry $w]
> regexp {^([0-9]*)x([0-9]*)[+]([0-9]*)[+]([0-9]*)} $geom -> w h x y
> set y2 [expr { $y + $h + 50 }]
> wm geometry .t ${w}x[winfo reqheight .t]+${x}+${y2}
> }
is last used before the regexp), but I've also run into bugs before
because I named a widget pathname "w" and a width, well, "w". Such code
may give maintainers a hard time..
Will ProCheck detect this? Can we write a proc that, given the above
proc definition, detects the problem?
I like Tcl's untypedness very much, but here is a case where a
type-checking compiler makes life somehow easier.
--
Schoene Gruesse/best regards, Richard Suchenwirth - +49-7531-86 2703
Siemens Dematic AG, PA RC D2, Buecklestr.1-5, 78467 Konstanz,Germany
Personal opinions expressed only unless explicitly stated otherwise.
Richard.Suchenwirth
>
> Kevin Kenny wrote:
> > # Procedure that adjusts the geometry of toplevel $t, to
> > # place it 50 pixels below toplevel $w.
> >
> > proc fixup { t w } {
> > if { [string compare . $w] } return
> > set geom [wm geometry $w]
> > regexp {^([0-9]*)x([0-9]*)[+]([0-9]*)[+]([0-9]*)} $geom -> w h x y
> > set y2 [expr { $y + $h + 50 }]
> > wm geometry .t ${w}x[winfo reqheight .t]+${x}+${y2}
> > }
> Danger Will Robinson! This happens to work (because the widget pathname
> is last used before the regexp), but I've also run into bugs before
> because I named a widget pathname "w" and a width, well, "w". Such code
> may give maintainers a hard time..
> Will ProCheck detect this? Can we write a proc that, given the above
> proc definition, detects the problem?
>
> I like Tcl's untypedness very much, but here is a case where a
> type-checking compiler makes life somehow easier.
Also, continuing "code review" in the coffee kitchen, the value of
parameter "t" is never used (against the documentation), but a window
with constant name .t is queried and configured without ever having been
created.. easily fixed by replacing twice ".t" with "$t".
Kevin Kenny
>
> "Richard.Suchenwirth" wrote:
> >
> > Kevin Kenny wrote:
> > > # Procedure that adjusts the geometry of toplevel $t, to
> > > # place it 50 pixels below toplevel $w.
> > >
> > > proc fixup { t w } {
> > > if { [string compare . $w] } return
> > > set geom [wm geometry $w]
> > > regexp {^([0-9]*)x([0-9]*)[+]([0-9]*)[+]([0-9]*)} $geom -> w h x y
> > > set y2 [expr { $y + $h + 50 }]
> > > wm geometry .t ${w}x[winfo reqheight .t]+${x}+${y2}
> > > }
> > Danger Will Robinson! This happens to work (because the widget pathname
> > is last used before the regexp), but I've also run into bugs before
> > because I named a widget pathname "w" and a width, well, "w". Such code
> > may give maintainers a hard time..
> > Will ProCheck detect this? Can we write a proc that, given the above
> > proc definition, detects the problem?
> >
> > I like Tcl's untypedness very much, but here is a case where a
> > type-checking compiler makes life somehow easier.
>
> Also, continuing "code review" in the coffee kitchen, the value of
> parameter "t" is never used (against the documentation), but a window
> with constant name .t is queried and configured without ever having been
> created.. easily fixed by replacing twice ".t" with "$t".
Richard is correct on both counts. I code carelessly when I'm flaming
about [update]. 8^)
> Schoene Gruesse/best regards, Richard Suchenwirth - +49-7531-86 2703
> Siemens Dematic AG, PA RC D2, Buecklestr.1-5, 78467 Konstanz,Germany
> Personal opinions expressed only unless explicitly stated otherwise.
--