I have a program that run in the terminal. But once in a while I need it
to bring up a window (GUI) with some information (and interactive
widgets).
So I do:
root = TkRoot.new
…set up the window…
Tk.mainloop
This works. Then the user closes the window and the program continues
running.
HOWEVER, the next time I try to bring up the window, Tk gives the
following error:
can’t invoke “frame” command: application has been destroyed
(RuntimeError)
(I also tried with TkToplevel instead of TkRoot.)
How can I solve this problem?
I looked into the source code of ‘/ext/tk/lib/dialog.rb’, thinking
perhaps TkDialog is what I need. I tried the following code:
class MyDialog < TkDialog
def initialize(*args)
super(*args)
TkLabel.new(self, :text => ‘this is a test’).pack
end
end
MyDialog.new :title => ‘something’
Now, this is already an improvement because I can call MyDialog.new()
again and again without Tk telling me that the “application has been
destroyed”. HOWEVER, I can’t put my own widgets in the dialog: my ‘this
is a test’ label doesn’t show up…
HOWEVER, the next time I try to bring up the window, Tk gives the
following error:
can’t invoke “frame” command: application has been destroyed
(RuntimeError)
Now here’s a blast from the past:
def maybeMainloop(reveal = false)
if reveal then
Tk.mainloop()
Tk.restart()
@canvas = nil
end
end
Notice I was using 4-space indentations back then! Always remember that
following community standards, such as Ruby’s Official 2-space
indentations, is
much MUCH more important than producing lots of boring original
research!
Read and obey the post by Hidetoshi NAGAI. He maintains RubyTk, AFAIK!
(BTW, suppose I’ll be running my code inside a Tk application. In that
case I wouldn’t want to execute Tk.mainloop() (and restart(), of course)
at all. Any way to find out if we’re already running in a Tk
application?)
If a GUI is already running, then if you block its main loop, the user
will see
the window lock up. So use @v.wait…
GTK requires you to memorize CONSTANTS.
Shoes doesn’t have mature widgets. FOX is a pain to compile. So we go
with Tk.
dead-end. (It has an ingeniously simple API, I admit, but the facts that
I struggled yesterday to fetch the selcted item from a TkListbox, and
even more to add scrollbars,
Hmm… I think that it not so difficult.
Possibly, Ruby/Tk is easier than Tcl/Tk.
:widget equal to “%W” (see Tcl/Tk’s “bind” manual).
current Ruby/Tk supports accessor-names of Tk::Event object instead
of
“%” substitutions.
p [w.curselection, w.get(w.curselection[0])]
}
lbox.value = %w(a b c foo bar baz hoge fuga zzz asdf qwer zxcv)
lbox.focus
Tk.mainloop
and that the fonts are so ugly and
unreadable, show that Tk has been dormant for at least 15 years.)
Well, I recommend you to use Tcl/Tk8.5 for your Ruby/Tk.
Tcl/Tk8.5 supports anti-aliased fonts on X window systems,
and includes Tile (Ttk) extension (widget styling engine) as default.
Now here’s a blast from the past:
[…]
Tk.mainloop()
Tk.restart()
Superb! That solved my problem. Thanks.
(BTW, suppose I’ll be running my code inside a Tk application. In that
case I wouldn’t want to execute Tk.mainloop() (and restart(), of course)
at all. Any way to find out if we’re already running in a Tk
application?)
Notice I was using 4-space indentations […]
LOL
Hidetoshi NAGAI wrote:
There is a trick
[…] @v.wait # wait command makes a eventloop while waiting
Thanks, Nagai, but this is too much voodoo for me I don’t bother to
study the “dark” corners of Tk because I have a feeling Tk is a
dead-end. (It has an ingeniously simple API, I admit, but the facts that
I struggled yesterday to fetch the selcted item from a TkListbox, and
even more to add scrollbars, and that the fonts are so ugly and
unreadable, show that Tk has been dormant for at least 15 years.) But it
seems we don’t have much choice. GTK requires you to memorize CONSTANTS.
Shoes doesn’t have mature widgets. FOX is a pain to compile. So we go
with Tk.
As the author of the www.tkdocs.com site, I’d very much welcome any
feedback as to the installation instructions, and particularly if anyone
knows easier ways to get things running!
Mark
I gave up, it’s too complicated for me. I’ll just wait for the next
release of Ubuntu.
Did you see ‘/ext/tk/README.tcltklib’ ?
Can’t it help you ?
Thanks! I made it. It was actually simple. My Tk apps look decent now
Mark R. wrote:
As the author of the www.tkdocs.com site, I’d very much
welcome any feedback as to the installation instructions
Two things:
There’s no need to compile the whole Ruby. After I extracted Ruby’s
source tarball I went to the ‘ext/tk’ folder and compiled only the Tk
extension. As Nagai points out, that folder has a README.tcltklib which
lists the command line options one needs to pass to ‘ruby extconf.rb’.
There’s no need to mention ActiveState or ActiveTcl. On my linux
distro (Ubuntu) I just type “sudo apt-get install tcl8.5 tcl8.5-dev
tk8.5 tk8.5-dev” and everything gets installed.
./configure --disable-pthread --with-tcl-dir=/usr/local
–with-tk-dir=/usr/local --disable-tcl-thread
make && make install
(I tried just rebuilding ext/tk as described in README.tcltklib, but the
effect was the same.)
Then some of the ruby/tk demos run but some segfault. For example:
Probably, your Tcl/Tk libraries are compiled with threads support
option.
The following table is the relation of thread support between
Ruby and Tcl/Tk.
| Tcl/Tk with threads | without threads
-------------------±----------------------±-----------------------
Ruby with pthread | work | possibly work
-------------------±----------------------±-----------------------
without pthread | NOT work (freq. SEGV) | work
-------------------±----------------------±-----------------------
“–disable-tcl-thread” option doesn’t change thread support status of
Tcl/Tk libraries.
make && make install
effect was the same.)
-------------------±----------------------±-----------------------
without pthread | NOT work (freq. SEGV) | work
-------------------±----------------------±-----------------------
“–disable-tcl-thread” option doesn’t change thread support status of
Tcl/Tk libraries.
You’re right about my tk lib using pthread, but I’m not sure why:
But I did rebuild tcl and tk with the options shown above, including
–disable-threads. The strange thing is that this worked for me in the
past with 8.4. Is there some other option that I have to pass to
configure to disable pthread?
Interestingly,
$ ldd libtcl8.5.so | grep thread
has empty output. So somehow tk is building with pthread, but tcl is
not. I used the same configure arguments for both.
I just rebuilt tk8.5.6 again with
./configure --disable-threads --prefix=/usr/local
and the still the resulting libtk8.5.so depends on libpthread.
I don’t bother to