Tkinter wm_withdraw doesn't work 
Author Message
 Tkinter wm_withdraw doesn't work

Anyone know the correct way to translate the Tk-ism "wm withdraw ."
to Python/Tkinter?

As far as I can see, the implementation of the Wm class' wm_withdraw
function tries to call a nonexistent member function called "tk()":

I executed the following file:

--------- file withdraw.py ------
from Tkinter import *

root = Tk()

wm = Wm()
wm.wm_withdraw()

root.mainloop()
---------------------------------

...and obtained the following result:

$ python withdraw.py
Traceback (most recent call last):
  File "withdraw.py", line 7, in ?
    wm.wm_withdraw()
  File "/usr/local/lib/python2.1/lib-tk/Tkinter.py", line 1457, in wm_withdraw
    return self.tk.call('wm', 'withdraw', self._w)
AttributeError: Wm instance has no attribute 'tk'



Thu, 06 Nov 2003 05:08:39 GMT  
 Tkinter wm_withdraw doesn't work

    Theodore> root = Tk()
    Theodore> wm = Wm()
              ^^^^^^^^^

This is wrong conceptually.  Wm is not a class that is supposed to be
instantiated.  Instead, it is supposed to be used indirectly, to derive
other classes from it.  "Introduction to Tkinter" call such classes
"mixin's", classes to mix into other classes to provide extra
functionalities.  Only two classes directly derive from Wm, both because
they are top-level widgets.  One is Tk, the other is Dialog.  So to withdraw
the root window, all you need is:

  root = Tk()
  root.wm_withdraw()

The same holds for Dialogs.  That you can say "wm = Wm()" is just because
Python is a language that do not disallow silly things from happening, so
everybody should really read the (unluckily, non-existent) manual.  Since
it is currently impossible to read the manual, everybody should really read
the source.

Notably, every concrete widget class that is *not* a top-level widget class
is an internal class, and hence is derived from Widget to support the
packer, grid and placer operations.

Regards,
Isaac.



Thu, 06 Nov 2003 19:30:09 GMT  
 Tkinter wm_withdraw doesn't work

Quote:
> Python is a language that do not disallow silly things from happening, so
> everybody should really read the (unluckily, non-existent) manual.  Since
> it is currently impossible to read the manual, everybody should really read
> the source.

Now, I'm not a C programmer, so essentially you just said "You
shouldn't try to use Tkinter."

Does wxPython have the same "You must also learn C" restriction?
--



Thu, 06 Nov 2003 20:54:04 GMT  
 Tkinter wm_withdraw doesn't work

CF> Does wxPython have the same "You must also learn C" restriction?

It has C++ manual with Python specific notes.

--
Best regards,
 Niki Spahiev



Fri, 07 Nov 2003 00:40:14 GMT  
 Tkinter wm_withdraw doesn't work

Quote:


>CF> Does wxPython have the same "You must also learn C" restriction?

>It has C++ manual with Python specific notes.

More generally, one of the reasons I believe that this is a problem with
regards to Python and those libraries is that the Python wrappers were
written by enthusiasts of those libraries who were primarily desiring to
achieve the ability to USE those libraries in Python. The "make it usable
to everyone else" part of this is playing second string, therefore leading
to thin documentation.

One generally OUGHT to learn C in conjunction with Python, however.
C is an important substrate of Python; one of Python's reasons of
existence is to wrap C.

C//



Fri, 07 Nov 2003 01:14:41 GMT  
 Tkinter wm_withdraw doesn't work

    ...

Quote:
> One generally OUGHT to learn C in conjunction with Python, however.
> C is an important substrate of Python; one of Python's reasons of
> existence is to wrap C.

I disagree.  One MAY want to learn C, eventually, IF one makes
substantial use of the "classic" Python (CPython) and wants to
extend it in C.  But in many cases one will be using other languages
for extensions -- Java for Jython, any language at all (that is able
to produce speedy in-process COM objects -- e.g. Eiffel should be
fine, or Delphi...) if one uses CPython but only on Windows.

Alex



Fri, 07 Nov 2003 02:04:16 GMT  
 Tkinter wm_withdraw doesn't work

Quote:



>    ...
>> One generally OUGHT to learn C in conjunction with Python, however.
>> C is an important substrate of Python; one of Python's reasons of
>> existence is to wrap C.

>I disagree.  One MAY want to learn C, eventually, IF one makes
>substantial use of the "classic" Python (CPython) and wants to
>extend it in C.  But in many cases one will be using other languages
>for extensions -- Java for Jython, any language at all (that is able
>to produce speedy in-process COM objects -- e.g. Eiffel should be
>fine, or Delphi...) if one uses CPython but only on Windows.

Fair enough. I know fairly little about Jython, so I'll dodge that one.

However, as to other languages, this ignores the host of C examples
(including the native ones like dictobject.c and listobject.c) which
provide a huge bases for developing other extensions. If one is going
to extending CPython on Windows or any other platform, the preferred
language really is C. Other extensions will likely not be very appreciated
by the community.

Just IMO,

C//



Fri, 07 Nov 2003 03:54:18 GMT  
 Tkinter wm_withdraw doesn't work

    ...

Quote:
> provide a huge bases for developing other extensions. If one is going
> to extending CPython on Windows or any other platform, the preferred
> language really is C. Other extensions will likely not be very appreciated
> by the community.

If one wants one's extensions to be "appreciated by the community"
(the Python one), you're probably right that C is one's only hope.  If,
on the other hand, one cares about productivity or cross-language
use, the picture is different.  I develop in C when I must (because I
hope for an extension to be used widely), in C++ when I can (because,
with Boost Python, it makes me 2 or 3 times more productive than C
with the Python API's) or when I need my extension to be used
cross-language (because C++ with ATL is my most productive way
to develop COM servers -- people with Delphi or Eiffel backgrounds
will no doubt be more productive in their favourite languages... Haskell
or O'Caml are not fully mature yet for COM dev't, IMHO, though they
ARE advancing very fast).

Alex



Fri, 07 Nov 2003 06:01:24 GMT  
 Tkinter wm_withdraw doesn't work

Quote:



>    ...
>> One generally OUGHT to learn C in conjunction with Python, however.
>> C is an important substrate of Python; one of Python's reasons of
>> existence is to wrap C.

>I disagree.  One MAY want to learn C, eventually, IF one makes
>substantial use of the "classic" Python (CPython) and wants to
>extend it in C.  But in many cases one will be using other languages
>for extensions -- Java for Jython, any language at all (that is able
>to produce speedy in-process COM objects -- e.g. Eiffel should be
>fine, or Delphi...) if one uses CPython but only on Windows.

Speaking of Delphi, can Delphi be used to extend Python instead of C.
Does anyone know of a website with Delphi units?

costas



Fri, 07 Nov 2003 07:22:22 GMT  
 Tkinter wm_withdraw doesn't work

    Carl> everybody should really read the source.

    Carl> Now, I'm not a C programmer, so essentially you just said "You
    Carl> shouldn't try to use Tkinter."

At least, you should really read <PythonLibDir>/lib-tk/Tkinter.py and
understand that, so that you know where things are, and how to convert Tk
manpages into use within Python/Tkinter.

Regards,
Isaac.



Fri, 07 Nov 2003 09:16:40 GMT  
 Tkinter wm_withdraw doesn't work

Quote:

> > Python is a language that do not disallow silly things from happening, so
> > everybody should really read the (unluckily, non-existent) manual.  Since
> > it is currently impossible to read the manual, everybody should really read
> > the source.

> Now, I'm not a C programmer, so essentially you just said "You
> shouldn't try to use Tkinter."

fwiw, in an earlier paragraph, he quoted my Tkinter introduction
document.  looks like what he really said is "don't trust my advice"

an overview of the Tkinter classes can be found here:
http://www.pythonware.com/library/tkinter/introduction/tkinter-classe...

the wm_withdraw method is described here, together with other
Tk/Toplevel methods:
http://www.pythonware.com/library/tkinter/introduction/toplevel-windo...

for a general intro to Python's class concept, and how method
inheritance works, see your favourite Python book.

Cheers /F



Sun, 09 Nov 2003 22:39:44 GMT  
 Tkinter wm_withdraw doesn't work

    Fredrik> fwiw, in an earlier paragraph, he quoted my Tkinter
    Fredrik> introduction document.  looks like what he really said is
    Fredrik> "don't trust my advice"

Definitely not.  I mention your work because I know the answer is there.
"An Introduction to Tkinter" is definitely a work that should be highly
respected.  The problem is that while the answer of this particular problem,
and a lot of other common problems, are there, there are also a lot of
questions that the work didn't yet document (e.g., the packer), didn't plan
to address (e.g., data format for images, etc), or didn't mention altogether
(e.g., profile reading, stacking model).  This is very reasonable: the work
is "An Introduction to Tkinter", not "A Tkinter manual".  That piece of
information is still only available if you dig into the source of Tkinter
and the manual of Tk.  That's why I say "you have to read the source".  I
still deeply want a "Tkinter manual".

I've been trying to write one, and thus far progress is not as good as I
wanted.  I found that I've mis-understood a lot of concepts in Tk, even
though I know Tk for more than 6 years now.  Thus far I've only partially
documented the Tkinter organization, the widget model and geometry
management aspects.  This partial work can be found in my own page
http://www.csis.hku.hk/~kkto/doc-tkinter/.  I definitely want to hear your
comments or suggestions.

Regards,
Isaac.



Mon, 10 Nov 2003 10:21:39 GMT  
 
 [ 12 post ] 

 Relevant Pages 

1. tkinter -- why doesn't this work?

2. Tkinter doesn't work with Tcl/Tk8.0.5 part 2

3. Tkinter and Python 1.5.1: after doesn't work anymore

4. ??? tkinter doesn't work with tcl76.dll

5. Tkinter doesn't work with beta tk/tcl

6. Tkinter.Listbox: activate() doesn't work

7. BLT installs but doesn't work, and TkTable doesn't build

8. EAI works (or doesn't work) differently under different platforms

9. tkman works/doesn't work [hpux9]

10. match works, don't match doesn't

11. Bevel Buttons' icon doesn't work

12. re.LOCALE | re.IGNORECASE doesn't work as you'd expect

 

 
Powered by phpBB® Forum Software