Error in "top/under/most" attribute logic?
ZB
"priority" (is placed "on top" of all visible windows) just by default.
Unfortunately, today I was a bit suprised noticing, that new toplevel has
been created *under* existing, larger window (it's presence could be
notified only by the new label on the bar).
Isn't it an logical error? Every new toplevel window - when it has been
created at all - most probably has been created to be noticed, not hidden
behind. So it shouldn't require explicit "wm attributes $path -topmost"
to be surely visible, and not covered by others - but quite otherwise:
if there's real need to hide it, it could be done by "wm attributes $path
-undermost" (or something like this).
--
ZB
hae
Hello ZB,
I would expect would you described but I am far from being an expert
on this. However it sometimes relies on the window manager on how it
does the mapping of a newly created window.
But the most common use with a new toplevel that is filled with new
widgets is like this:
set w .new_win
toplevel $w
wm withdraw $w
;# create your widgets here and put them on the window
wm deiconify $w
focus $w ;# maybe you like to do this too
The reason todo it like this is that it is a little bit faster to pack/
grid/place your widgets. Maybe this solves your problem.
Ruediger
ZB
> I would expect would you described but I am far from being an expert
> on this. However it sometimes relies on the window manager on how it
> does the mapping of a newly created window.
I am usually working under Linux - where I didn't notice such problem. But
today I noticed this under Windows. Seems, it's working a bit differently.
> But the most common use with a new toplevel that is filled with new
> widgets is like this:
>
> set w .new_win
> toplevel $w
> wm withdraw $w
> ;# create your widgets here and put them on the window
> wm deiconify $w
> focus $w ;# maybe you like to do this too
>
> The reason todo it like this is that it is a little bit faster to pack/
> grid/place your widgets. Maybe this solves your problem.
Thanks, most probably you're right. Found in the docs:
#v+
On Windows, a deiconified window will also be raised and be given the focus
(made the active window). Returns an empty string.
#v-
So this is workaround for the problem, that seems to be WM-dependent (?).
Of course, the problem itself needs a fix, IMHO.
--
ZB
Jeff Hobbs
This is a logical misstep on your part. Toplevel Z order is dependent
on several things, including OS and wm attributes. You can control
almost all aspects of Tk toplevels via the wm controls, and indeed
need to for certain applications. The first line assumption is just
outright incorrect and I believe that is fully correct for Tk.
Jeff
ZB
>> My assumption was, that every newly created "toplevel" window has higher
>> "priority" (is placed "on top" of all visible windows) just by default.
> This is a logical misstep on your part. Toplevel Z order is dependent
> on several things, including OS and wm attributes. You can control
> almost all aspects of Tk toplevels via the wm controls, and indeed
> need to for certain applications. The first line assumption is just
> outright incorrect and I believe that is fully correct for Tk.
Yes, 1-2 additional commands - but really I think, that "default"
(without any need for additional action) should be: "every new toplevel
is created on top of the existing (or earlier) ones".
Only in the case, if I really want it to be covered by the others (no idea,
why should I, actually) - this case could require additional steps.
--
Zbigniew