Tk, how to hide the top level window
* Tong *
I have a command-line tk script that don't need the top level window
'.'. (believe me it is necessary :->) Is there a way that I can hide
the top level window? I'm getting a quick flash window currently.
Further more, I've got another monster Tk script that need lots of
time to initial its widgets. How can I hide the top level window, do
the packing and then show the finished window?
Thanks.
--
Tong (remove underscore(s) to reply)
http://members.xoom.com/suntong001/
- All free contribution & collection & music from the heavens
Arthur Taylor
I think you want something like ...
wm withdraw .
...
create stuff
pack stuff / grid stuff
....
wm deiconify .
Although personally I tend to never use the . window, and instead use a
"toplevel .foo", and create all my stuff under .foo. That way I can
combine it with other scripts. The advantage being that I don't have to
worry about naming conflicts.
By the way, if you take too long to build stuff, you may want a toplevel
window to appear briefly (maybe an about window) so the user knows
something is going on.
Arthur
* Tong *
Thanks Arthur!
Arthur Taylor <arthur...@home.com> writes:
> Although personally I tend to never use the . window, and instead use a
> "toplevel .foo", and create all my stuff under .foo. That way I can
> combine it with other scripts. The advantage being that I don't have to
> worry about naming conflicts.
Good suggestion! yes, that's what I always wanted to do. After
trying to do it once and have the original . window still hanging
around and not knowing how to deal with it, I just gave up... That
was an easy-giving up, wasn't it? :-)
So basically you do a "wm withdraw ." before you build you own stuff
under .foo, right?
Arthur.Taylor
-------------------
#!/bin/sh
# next line restarts /
exec wish "$0" "$@"
proc main {tl} {
catch {destroy $tl}
toplevel $tl
wm title $tl "Name of program"
set cur [frame $tl.f1]
set cur2 [frame $cur.top]
button $cur2.ok -text ok
label $cur2.lab -text "here"
pack $cur2.ok $cur2.lab -side left
set cur2 [frame $cur.bot]
...
}
set src_dir [file dirname [info script]]
if {$src_dir == "."} {set src_dir [pwd]}
wm withdraw .
main .foo
-----------
Things to note:
1) global variable src_dir contains the path to your tcl script.. Useful for
finding files, and saving files, and source'ing other scripts.
2) catch {destroy $tl} .. In case you are using a console in windows and need
to resource the file multiple times, this allows you to do that.
3) Indentation pattern of frames... Allows one to visually check if one has
pack'ed a frame or not.
4) use of cur, cur2 .... Allows one to copy paste segments of window
creation. Also it is a lot simpler to rename stuff if needed.
-----------
Something else which you might find useful, (when you need command line
arguments (ie a file name)):
if {$argc >=1 } {
eval {main} $argv
} elseif {$argv0 == $src_dir/<name of tcl script>.tcl} {
puts "Run using: $src_dir/<name of tcl script>.tcl <arguments>"
} else {
puts "Run using: main <arguments>
}
Here it should handle:
A) running it from a command line with arguments... (ie run it)
B) running it from a command line without arguments... (ie describe how to
run)
C) sourcing it from a Tk-Console. (ie describe the new command, but make the
user type it in to run it.)
I haven't tested this part much, as I just recently started using it.
---------------
Arthur
* Tong *
> My tcl scripts tend to be something like:
>
Thanks a lot, Arthur! You are sooooo helpful. :-)
Petasis George
>
> Hi,
>
> I have a command-line tk script that don't need the top level window
> '.'. (believe me it is necessary :->) Is there a way that I can hide
> the top level window? I'm getting a quick flash window currently.
>
> Further more, I've got another monster Tk script that need lots of
> time to initial its widgets. How can I hide the top level window, do
> the packing and then show the finished window?
>
> Thanks.
I wouldn't advise you to use
"wm withdraw ." on the "." window. Under some window managers
(especially under unix...) this will prevent dialogs that have as
parent the "." (like error messages) to not show up and block
your app. Better to use something like:
wm geometry . 1x1+0+0
wm overrideredirect . 1
wm transient .
You can even send it out of the visible part of the screen, like
wm geometry . 1x1+3000+3000
But in any way do not withdraw it :-)
George
Richard.Suchenwirth
> I wouldn't advise you to use
> "wm withdraw ." on the "." window. Under some window managers
> (especially under unix...) this will prevent dialogs that have as
> parent the "." (like error messages) to not show up and block
> your app. Better to use something like:
Thank you, George, for the good explanation. I allowed myself to put it
on the Wiki at "wm", http://mini.net/cgi-bin/wikit/1260.html
Hope you don't object...
--
Schoene Gruesse/best regards, Richard Suchenwirth - +49-7531-86 2703
RC DT2, Siemens ElectroCom, Buecklestr.1-5, D-78467 Konstanz,Germany
Personal opinions expressed only unless explicitly stated otherwise.
Arthur.Taylor
I admit to having more MS-Windows debugging experience than UNIX, but
so far I hadn't thought to blame the "wm withdraw ." for errors.
Bruce Hartweg
Arthur Taylor wrote:
> Although personally I tend to never use the . window, and instead use a
> "toplevel .foo", and create all my stuff under .foo. That way I can
> combine it with other scripts. The advantage being that I don't have to
> worry about naming conflicts.
>
The only draw back to that approach is then you can't ever embed the script
into another display using the -use switch, while probably rare can be quite
useful in some circumstances.
Bruce
Arthur.Taylor
far as I can tell the following works:
toplevel .foo -container true
update
toplevel .foo2 -use [winfo id .foo]
button .foo2.hello -text "hello world"
pack .foo2.hello
So if .foo is on a different display, I use the -use switch to embed my script
(.foo2 and below) into .foo ... Granted I am using only one script here, and
the .foo is not on another display during my test, but I don't see how the use
of "toplevel .foo2" is inhibiting the use of -use.
It could be that the "winfo id" is made more difficult, but '.' still exists, so
if need be one still has it. it just isn't displayed. Hopefully you can clarify
stuff.
----------
Related question: Would one use the -use option to create something like Word
Perfect, where there are multiple windows open inside the toplevel? The other
way I was thinking one could do that would be to create a canvas, and put the
windows inside it, but the min/max buttons, menu-bar etc wouldn't be put in the
canvas properly.
Bruce Hartweg
I was speaking of the -use option on the command line that embeds the "." window
into some window from another application. The embedded application has no
knowledge that it is embedded. As I said, not something commonly used but I
have found it occasionally handy. e.g. we had a system at work and I created
numerous tools to help monitor, tweak, or otherwise be useful. Then someone
wanted to make a coherent controller for ease of use for newbies/customers.
So mainly we just needed a master gui to tie them all together, so I basically made
a toolbar that had buttons for each of the items (as well as some of the program
applications & generic things like an xterm etc.). The buttons just basically exec'd
the different scripts/executables. Some things, like xterms, you might want more than
one of so every press would create a new one. Others, like some monitoring tools,
you really only needed 1 of so instead of worrying about tracking to see if an application
was running or not it was far easier to create a new toplevel the belonged to the toolbar
script with the -container flag and then exec the other script with the -use flag so
that it embeds itself inside. Then if the button is pressed again is is easy to test
if the top level existed - if so, just deiconify and raise it.
You could use to embed multiple windows inside on toplevel (using the -container
on the frame) but when you do that, you don't get the min/max buttons because
they are not top level windows so the window manager doesn't add those things.
If you wanted to mimic word type behavior you would have to create a frame that
contained the titlebar min/max buttons and another subframe that you then embedded
into and you would have to handle the behavior when the buttons were pressed.
Bruce
Donal K. Fellows
> I wouldn't advise you to use
> "wm withdraw ." on the "." window. Under some window managers
> (especially under unix...) this will prevent dialogs that have as
> parent the "." (like error messages) to not show up and block
> your app.
I've never seen this in action.
> Better to use something like:
> wm geometry . 1x1+0+0
> You can even send it out of the visible part of the screen, like
> wm geometry . 1x1+3000+3000
For a variation on the preceding that won't fail on a really very
big screen...
wm geometry . 1x1+-1500+-1500
> wm overrideredirect . 1
> wm transient .
The second has no effect (missing parameter :^) and the first causes
all "transient" effects to be ignored anyway.
Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ fell...@cs.man.ac.uk
-- I may seem more arrogant, but I think that's just because you didn't
realize how arrogant I was before. :^)
-- Jeffrey Hobbs <jeffre...@ajubasolutions.com>
Petasis George
>
> Petasis George wrote:
> > I wouldn't advise you to use
> > "wm withdraw ." on the "." window. Under some window managers
> > (especially under unix...) this will prevent dialogs that have as
> > parent the "." (like error messages) to not show up and block
> > your app.
>
> I've never seen this in action.
>
I really don't remember exactly the details, but I think it was
related to various tk dialogs, that used for parent the "." window
if you didn't specify the -parent option. I think one of these
was also the bgerror's dialog. Withdrawing the "." window
caused many dialogs to not display at all under some environments.
I really don't remember if that thread lead to a modification.
Tk84a2 which I use has a new window for reporting errors than earlier
versions (8.3.x?). Perhaps in the update this problem to have been fixed,
so it may only be a problem for earlier versions.
I don't have an earlier version around and some initial attempts to
reproduce it 8.4.a2 failed :-)
But for sure under some versions, this problem exist...
George
Bruce Hartweg
enn...@yahoo.com wrote:
>I am interested in embedding a non-tk application inside of a tk
>window. From Bruce's message, he mentioned opening up an application,
>say an xterm, by executing a script using the -use option. I'm not
>exactly clear on how this is done. When doing exec on an application
>(in Windows), isn't this spawning a process outside of the tk control
>(potentially in the background if & is used). How does one find out
>the xterm tk pathname in order to do the following? or is there
>another way to do this?
>
>toplevel .tl1 -container true # tk window
>toplevel [xterm pathname] -use [winfo id .tl1] # open up the xterm
>window in the tk window
>
>
>Thanks,
>Elizabeth
>
>
no, you can't embed an xterm like that, my example wasn't clearly worded
enough, I meant that
I had a toolbar that launched a bunch of things - one of which was a
xterm, in that case (and some of
the other tools as well) I would just launch it as normal and it would
have it's own window.
It was for other portions (some monitors, controller type GUIs) that I
only wanted a single instance
running, instead of having so way to look for running process, I would
just create a new toplevel
in the toolbar process itself (with -container) and then run the
subprocess (which was a Tk based tool)
with the -use option to embed it. that way if the button was pressed
again I just had to check for
the existence of the window and if it existed then I knew the tool was
already running, and I would
just deiconify and/or raise the window to the front.
For future reference, please post questions to clt (or just follow-up to
the post you are replying to!)
instead of e-mailing me directly. I usually won't be able to reply from
emails (to busy with paid work)
plus you'll have all of the clt readers as a pool of potential answerers
so you are much more likely to
get a solution to your problem vs. an "I don't know"
Bruce
OP for reference to the NG
Thomas Dickey
> no, you can't embed an xterm like that, my example wasn't clearly worded
> enough, I meant that
It can be embedded (though I don't do it myself, I added the option several
years ago for someone who does):
-into windowId
Given an X window identifier (a decimal integer), xterm will
reparent its top-level shell widget to that window. This is
used to embed xterm within other applications.
xterm supports ANSI color, VT220 emulation and UTF-8
There's an faq at
http://invisible-island.net/xterm/xterm.faq.html
ftp://invisible-island.net/xterm/
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
Bruce Hartweg
Thomas Dickey wrote:
> Bruce Hartweg <bruce_...@raytheon.com> wrote:
>
>>no, you can't embed an xterm like that, my example wasn't clearly worded
>>enough, I meant that
>
>
> It can be embedded (though I don't do it myself, I added the option several
> years ago for someone who does):
>
> -into windowId
> Given an X window identifier (a decimal integer), xterm will
> reparent its top-level shell widget to that window. This is
> used to embed xterm within other applications.
>
> xterm supports ANSI color, VT220 emulation and UTF-8
> There's an faq at
> http://invisible-island.net/xterm/xterm.faq.html
> ftp://invisible-island.net/xterm/
>
good to know (and why I encouraged the OP to go to the newsgroup).
but... the version of xterm on my system (whatever came with Solaris 9)
does NOT have that option.
And it highlights the point in the original question about embedding apps
*in general* in that the app being embedded has to have the support for it.
Bruce