I am fed up with Python GUI toolkits...

[Mel]

Yes, but not to avoid a memory leak.

OTOH, if you intend to re-use the Dialog object, it's not a memory leak.

Mel.

 

[sturlamolden]

OTOH, if you intend to re-use the Dialog object, it's not a memory leak.

It cannot be reused if you don't have any references pointing to it.
Sure it is nice to have dialogs that can be hidden and re-displayed,
but only those that can be accessed again.

tp_dealloc should free any C resources the object is holding. There is
no need to save anything beyond the call to tp_dealloc. Before the
call to tp_dealloc any C resources should be kept, for the reason you
mentioned.

That is why the parent-child method of clean-up is at odds with the
Python garbage collection.


Sturla

 

[sturlamolden]

Okay, I haven't used SWT yet: manual memory management? Java is GC!

It is perfectly reasonable to be required to manually call some sort of
destroy() method to tell the toolkit what you no longer want the user to
see: firstly, you have the display a reference to your window, in a
manner of speaking, by showing it. Secondly, in a GC environment like a
JVM or the CLI, it could take a moment. Was that what you meant?

A .hide() method is warranted, but not a .destory() method to
deallocate C resources. Python calls tp_dealloc when needed.

 

[sturlamolden]

NEVER GOING TO HAPPEN.  UI's don't work that way.  They are inherently
hierarchical.  Just get over it.

Swing relies on the Java GC. Tkinter also does this correct.

A hierarchy is nice for event processing an layout management, but not
for memory mangement.

C resources should be freed by Python calling tp_dealloc, not by the
parent calling a .destroy() method on it's children.

Python is not C++, so we have a method to automatically reclaim C
resources. I don't want a toolkit to deallocate objects while Python
still holds references to them (PyQt) or require a manual call to
deallocate a widget tree (wxPython).

Python knows when it's time to deallocate C resources, and then makes
a call to the tp_dealloc member of the type object.

 

[sturlamolden]

http://xkcd.com/927/

Indeed.

 

[rantingrick]

It cannot be reused if you don't have any references pointing to it.
Sure it is nice to have dialogs that can be hidden and re-displayed,
but only those that can be accessed again.

I find that keeping a dialog alive (and hidden) is bad practice EXCEPT
in the case where a dialog will be used many, many times in an
application. Since that kind of re-usage is rare destroying the dialog
and freeing the graphical resources it consumes is important.

However a dialog should handle it's own state. That is, and
application should never have to keep up with dialog default values
and re-insert then every time, NO, the dialog should do this all by
itself.

My solution is to create a simple container class that creates and
destroys the dialog as needed (when show is called) however keeps a
state of the last user inputs so the main application does not have
to.

class Dialog():
def __init__(self):
self.state = []
# the dialog IS NOT created here!

def show(self):
# Create the dialog here
# and load any initial values
# from self.state.

def cb_okbutton(self):
# Process the inputs, store the
# current values in self.state
# and destroy.

def cb_cancelbutton(self)
# destroy the dialog.

This is a proper design pattern for all GUI dialogs.

*school-bell*

 

[Thomas Jollans]

PyGTK with GLADE is the easier to use, but a bit awkward looking on
Windows and Mac. (Not to mention the number of dependencies that must
be installed, inclusing a GTK runtime.)

Don't know about Mac, I was under the impression that GTK was fine on
Windows these days.

You can bundle GTK+ just as easily as Qt or Wx. It might, of course, be
less usual.

GTK and Qt do that as well.

Qt uses the native libraries on Windows and OSX.

 

[sturlamolden]

Don't know about Mac, I was under the impression that GTK was fine on
Windows these days.

GTK looks awful on Windows, requires a dozen of installers (non of
which comes from a single source), is not properly stabile (nobody
cares?), and does not work on 64-bit.

 

[sturlamolden]

Have you tried Tkinter version 8.0 or better, which offers a native look and
feel?

Python 2.7.2 |EPD 7.1-1 (64-bit)| (default, Jul 3 2011, 15:34:33)
[MSC v.1500 64 bit (AMD64)] on win32
Type "packages", "demo" or "enthought" for more information.8.5

 

[rantingrick]

Have you tried Tkinter version 8.0 or better, which offers a native look and
feel?

Steven, you have no buisness offering advice on Tkinter since you
yourself have proclaimed that YOU NEVER used the module and never
will. Stick to what you know please.

 

[Phlip]

Steven, you have no buisness offering advice on Tkinter since you
yourself have proclaimed that YOU NEVER used the module and never
will. Stick to what you know please.

Allow me.

Tkinter sucks because it looks like an enfeebled Motif 1980s dawn-of-
GUIs scratchy window with grooves and lines everywhere.

Tkinter is awesome because you can nest anything inside anything else,
and it has an elaborate & extendable properties system.

Oh, and you can TDD it. Unlike some more "modern" GUIs I could
mention...

 

[sturlamolden]

Tkinter sucks because it looks like an enfeebled Motif 1980s dawn-of-
GUIs scratchy window with grooves and lines everywhere.

The widget set is limited compared to GTK or Qt, though it has the
most common GUI controls, and it does not look that bad with the
recent ttk styling (it actually doesn't look like Motif anymore). But
it does not have a good GUI builder (that I know of).

Sturla

 

[Corey Richardson]

Excerpts from Phlip's message of Wed Jul 20 16:58:08 -0400 2011:

Allow me.

Tkinter sucks because it looks like an enfeebled Motif 1980s dawn-of-
GUIs scratchy window with grooves and lines everywhere.

Themed Tk (TTK) has come a far way. I'll leave the research for you, however,
as I can not give this post the time it deserves.

--
Corey Richardson
"Those who deny freedom to others, deserve it not for themselves"
-- Abraham Lincoln

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iQEcBAEBCAAGBQJOJ1RXAAoJEAFAbo/KNFvpkasH/Rv+y9K/aBEO6W4YlCqCo1Zk
Ot6PmJbVi/I2kWeEScqyQm/GTN/7tPgoM2q7v3RE2MbYF4N+D0pRuS1SFeyyJdxx
KJAxl4bm2pW/DohRbcLv0TXjrqoxWCRTNZ1oWVF22vEbnjhdj6xGd2aeywpbSqLK
H/sCtf/KdAjySDQuyJsXk0qTGqycl9bnHcsYh1+ESLrzXxyqbvDYxCYExZm2TqOQ
6EeazB6xO7MbSOSMaWs3W8sRRLjN/589ZLZOcJlKykLyM4YEjQyGN2ixwJH5k/H5
HosdYCxDhXAiEx2PmnxPZLGEq1PFcFI2PsI1Dv1P/8C8kR847wqjSx864C3EnvQ=
=nwFm
-----END PGP SIGNATURE-----

 

[sturlamolden]

Tkinter sucks because it looks like an enfeebled Motif 1980s dawn-of-
GUIs scratchy window with grooves and lines everywhere.

And using it with OpenGL has been impossible since Python 2.2 (or
whatever).

 

[Phlip]

The widget set is limited compared to GTK or Qt, though it has the
most common GUI controls, and it does not look that bad with the
recent ttk styling (it actually doesn't look like Motif anymore). But
it does not have a good GUI builder (that I know of).

Oh, and you can TDD it, too...

 

[sturlamolden]

Oh, and you can TDD it, too...

No, I can't TDD with Tkinter. All my tests fail when there is no
OpenGL support (Togl is gone). For TDD to work, the tests must have a
chance of passing.

 

[rantingrick]

RE: *Ben Finney changes thread subject*

Please everyone, do not change the subject of someone's thread because
it's considered rude. Thank you.

 

[Tim Chase]

RE: *Ben Finney changes thread subject*

Please everyone, do not change the subject of someone's thread because
it's considered rude. Thank you.

Right...do not change the subject because it's considered rude.
Change it because the topic drifted from the original topic and a
fitting subject line helps people decide whether they want to
read any subsequent sub-threads. That's just email etiquette as
old as the tubes.

-tkc

 

[rantingrick]

RE: *Tim Chase changes topic and talks smack*

Right...do not change the subject because it's considered rude.
Change it because the topic drifted from the original topic and a
fitting subject line helps people decide whether they want to
read any subsequent sub-threads.  That's just email etiquette as
old as the tubes.

What about the etiquette of staying on topic? The only person who is
OFFICIALLY allowed to change the subject matter of a thread is the OP.
Sure some folks might make an off topic post here and there however i
find it bombastically rude when folks just change a topic of thread
they do not own.

How would you like it if i came to your house and wrote my name on
your refrigerator door, or used your toilet without asking, or slept
in your bed? I would not do that because i have manners. Feel free to
make yourself comfortable but don't put you feet on the coffee table.

 

[Phlip]

RE: *Ben Finney changes thread subject*

Please everyone, do not change the subject of someone's thread because
it's considered rude. Thank you.

No it isn't. Rambling off on a new topic under the wrong subject is
rude.