I am fed up with Python GUI toolkits...
sturlamolden
1. Designed for other languages, particularly C++, tcl and Java.
2. Bloatware. Qt and wxWidgets are C++ application frameworks. (Python
has a standard library!)
3. Unpythonic memory management: Python references to deleted C++
objects (PyQt). Manual dialog destruction (wxPython). Parent-child
ownership might be smart in C++, but in Python we have a garbage
collector.
4. They might look bad (Tkinter, Swing with Jython).
5. All projects to write a Python GUI toolkit die before they are
finished. (General lack of interest, bindings for Qt or wxWidgets
bloatware are mature, momentum for web development etc.)
How I would prefer the GUI library to be, if based on "native"
widgets:
1. Lean and mean -- do nothing but GUI. No database API, networking
API, threading API, etc.
2. Do as much processing in Python as possible. No more native code
(C, C++, Cython) than needed.
3. Instances of extension types can clean themselves up on
deallocation. No parent-child ownership model to mess things up. No
manual clean-up. Python does all the reference counting we need.
4. No artist framework. Use OpenGL, Cairo, AGG or whatever else is
suitable.
5. No particular GUI thread synchronization is needed -- Python has a
GIL.
6. Expose the event loop to Python.
7. Preferably BSD-style license, not even LGPL.
8. Written for Python in Python -- not bindings for a C++ or tcl
toolkit.
The Eclipse SWT library does some of this for Java does some of this,
though it also has flaws (e.g. manual memory management). A Python GUI
toolkit could be partially based on the SWT code.
Is it worth the hassle to start a new GUI toolkit project?
Or should modern deskop apps be written with something completely
different, such as HTML5?
Sturla
Terry Reedy
> What is wrong with them:
>
> 1. Designed for other languages, particularly C++, tcl and Java.
>
> 2. Bloatware. Qt and wxWidgets are C++ application frameworks. (Python
> has a standard library!)
>
> 3. Unpythonic memory management: Python references to deleted C++
> objects (PyQt). Manual dialog destruction (wxPython). Parent-child
> ownership might be smart in C++, but in Python we have a garbage
> collector.
>
> 4. They might look bad (Tkinter, Swing with Jython).
>
> 5. All projects to write a Python GUI toolkit die before they are
> finished. (General lack of interest, bindings for Qt or wxWidgets
> bloatware are mature, momentum for web development etc.)
Greg Ewing's pygui project is still going and releasing new versions.
> How I would prefer the GUI library to be, if based on "native"
> widgets:
>
> 1. Lean and mean -- do nothing but GUI. No database API, networking
> API, threading API, etc.
>
> 2. Do as much processing in Python as possible. No more native code
> (C, C++, Cython) than needed.
>
> 3. Instances of extension types can clean themselves up on
> deallocation. No parent-child ownership model to mess things up. No
> manual clean-up. Python does all the reference counting we need.
>
> 4. No artist framework. Use OpenGL, Cairo, AGG or whatever else is
> suitable.
>
> 5. No particular GUI thread synchronization is needed -- Python has a
> GIL.
>
> 6. Expose the event loop to Python.
>
> 7. Preferably BSD-style license, not even LGPL.
>
> 8. Written for Python in Python -- not bindings for a C++ or tcl
> toolkit.
I think you described pygui.
> Is it worth the hassle to start a new GUI toolkit project?
Ask Greg what you might help with.
> Or should modern deskop apps be written with something completely
> different, such as HTML5?
An interesting question. I think the pyjamas project is aimed in this
direction, but the author says he will never port to Py3. (He explained
his reasons on this list when I suggested that.)
---
Terry Jan Reedy
Andrew Berg
Hash: RIPEMD160
There's PyGUI, which, at a glance, fits whit what you want. Looks like
it uses OpenGL and native GUI facilities.
http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/
It has quite a few external dependencies, though (different dependencies
for each platform, so it requires a lot to be cross-platform).
- --
CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0
PGP/GPG Public Key ID: 0xF88E034060A78FCB
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAwAGBQJOJj7PAAoJEPiOA0Bgp4/Lh5AH+wXA8SneG7QQfL/WQipQCG93
79JIVMEQz7O+LYoHNLso1nNoVlz2UW4h1xaZp5ZrqMDyHRNQPwjA15hPGUqjng2V
MBUD3IMvi4K04ZbozAZ/dWFnKrhLZ043OrwtSsKZImPcoP4Kq3ReiejjDLPReFLV
3yzyYa6i1eIabU5JlxD2B6vPM9IfYdgB3/UZXcI0DKozU7LnCGNMoNlEJzfH4c5C
gkqr2e0RhWRf17Nax9RURbaIFjbMCuFTTR7HM46Z1/WLf16+sr2AQElzG+d8a6Bx
kq5i/u5ie+rpvSpz3KbhrPaF7rCyPBa3xdX+UTfrlp3geGGbzI4K/PbN12tVAMc=
=h89v
-----END PGP SIGNATURE-----
Kevin Walzer
On 7/19/11 10:12 PM, sturlamolden wrote:
>
> 1. Designed for other languages, particularly C++, tcl and Java.
So? Doing a GUI toolkit is a hard project.
>
> 2. Bloatware. Qt and wxWidgets are C++ application frameworks. (Python
> has a standard library!)
Again, so? This isn't applicable to Tk, by the way. It's a GUI toolkit
specifically designed for scripting languages.
>
> 3. Unpythonic memory management: Python references to deleted C++
> objects (PyQt). Manual dialog destruction (wxPython). Parent-child
> ownership might be smart in C++, but in Python we have a garbage
> collector.
Again, so? Again, this isn't applicable to Tk.
>
> 4. They might look bad (Tkinter, Swing with Jython).
Then again, they might not. A lot depends on the skill of the
developer. I write highly polished commercial apps with Tk GUI's. I'm
sick of developers blaming their ugly apps on the toolkit rather than
their own lack of design training and/or skills.
>
> 5. All projects to write a Python GUI toolkit die before they are
> finished. (General lack of interest, bindings for Qt or wxWidgets
> bloatware are mature, momentum for web development etc.)
That's right. People issue a clarion call for a new GUI toolkit, then
discover that even a so-called "ugly, limited, minimalist" toolkit like
Tk has twenty years of development behind it. And people think they can
duplicate this effort in a few months by starting a flame war on
comp.lang.python?
>
> 1. Lean and mean -- do nothing but GUI. No database API, networking
> API, threading API, etc.
Presenting...Tk.
>
> 2. Do as much processing in Python as possible. No more native code
> (C, C++, Cython) than needed.
And what's wrong with native (ie. compiled) code? Python is written in
native code, isn't it? To extend Python in significant ways, it is often
necessary to drop down into native code.
>
> 3. Instances of extension types can clean themselves up on
> deallocation. No parent-child ownership model to mess things up. No
> manual clean-up. Python does all the reference counting we need.
Presenting...Tk.
>
> 4. No artist framework. Use OpenGL, Cairo, AGG or whatever else is
> suitable.
"Artist framework"? I'm not sure what you mean here.
>
> 5. No particular GUI thread synchronization is needed -- Python has a
> GIL.
No comment here.
>
> 6. Expose the event loop to Python.
Presenting...Tk.
>
> 7. Preferably BSD-style license, not even LGPL.
Presenting...Tk.
>
> 8. Written for Python in Python -- not bindings for a C++ or tcl
> toolkit.
Well, that's the holy grail, but given the history of other toolkits,
you'll reach a comparable level of maturity in 2031.
>
>
> The Eclipse SWT library does some of this for Java does some of this,
> though it also has flaws (e.g. manual memory management). A Python GUI
> toolkit could be partially based on the SWT code.
Your practical suggestion for the basis for a new Python GUI toolkit
is...a Java GUI toolkit? I'm quite confused.
>
> Is it worth the hassle to start a new GUI toolkit project?
Not unless you want to reinvent the wheel yet again.
>
> Or should modern deskop apps be written with something completely
> different, such as HTML5?
If it's written in HTML5, it is, by definition, not a desktop app.
--Kevin
--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
Steven D'Aprano
> What is wrong with them:
[...]
> 4. They might look bad (Tkinter, Swing with Jython).
Have you tried Tkinter version 8.0 or better, which offers a native look and
feel?
> 5. All projects to write a Python GUI toolkit die before they are
> finished. (General lack of interest, bindings for Qt or wxWidgets
> bloatware are mature, momentum for web development etc.)
Then you'll love PythonCard, which didn't die until after it was mature!
Actually, that's not entirely true. PythonCard is still hanging in there on
life support. Perhaps all they need is an infusion of fresh, enthusiastic
blood.
> How I would prefer the GUI library to be, if based on "native"
> widgets:
[...]
> 3. Instances of extension types can clean themselves up on
> deallocation. No parent-child ownership model to mess things up. No
> manual clean-up. Python does all the reference counting we need.
Unless you're using three of the four major Python implementations, Jython,
IronPython and (usually) PyPy.
> 4. No artist framework. Use OpenGL, Cairo, AGG or whatever else is
> suitable.
>
> 5. No particular GUI thread synchronization is needed -- Python has a
> GIL.
Except for Jython, IronPython and PyPy.
--
Steven
Ian Kelly
> 3. Unpythonic memory management: Python references to deleted C++
> objects (PyQt). Manual dialog destruction (wxPython). Parent-child
> ownership might be smart in C++, but in Python we have a garbage
> collector.
Perhaps you already know this, but recent versions of wxPython allow
dialogs to be used as context managers, which destroys them when the
with block is exited.
Stefan Behnel
>> Python has a GIL.
>
> Except for Jython, IronPython and PyPy.
PyPy has a GIL, too.
Stefan
Steven D'Aprano
Isn't it optional though?
--
Steven
Andrew Berg
Hash: RIPEMD160
On 2011.07.20 02:28 AM, Steven D'Aprano wrote:
> Isn't it optional though?
No.
http://doc.pypy.org/en/latest/faq.html#does-pypy-have-a-gil-why
- --
CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0
PGP/GPG Public Key ID: 0xF88E034060A78FCB
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAwAGBQJOJojrAAoJEPiOA0Bgp4/LXdgH/RJefVrvsawewQsxMex9NlMl
IRS6lMjVMFgsXHh2V2F+DfQ0bZ9904dgsgyU3zHkfevI3Stctrr8qainxlmUxj3q
EFTzzQLUurY+tyR1sz5y9MtxWbjvOIQrZ8VN0aj/1ks+TU7fq+2d+sa+KFgMhP+k
F2TQeZhDBYhm+NE7h7MHsYhnRHtA5nWW2UByFXu/gcdrk9rB+3nqHuxj4ROh7Ots
vHbS9W/BsDver0e2Z9w4TxZ5Jb9cAjdkAqcK4Tqth0WMhvnIpnRGxM8npwD/xsKs
9jVkZhdG1BSvXdRUqLYTucA0lfTqNMh1CZtWzvOQIBqH1cdqKP+S7zdOloyti5Y=
=H+A1
-----END PGP SIGNATURE-----
Steven D'Aprano
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: RIPEMD160
>
> On 2011.07.20 02:28 AM, Steven D'Aprano wrote:
>> Isn't it optional though?
> No.
> http://doc.pypy.org/en/latest/faq.html#does-pypy-have-a-gil-why
Ah, my mistake, thank you. I knew PyPy had multiple garbage collectors, and
confabulated that it didn't have a GIL.
So, that's two GILs, two without for the Big Four.
--
Steven
Thomas Jollans
> 3. Unpythonic memory management: Python references to deleted C++
> objects (PyQt). Manual dialog destruction (wxPython). Parent-child
> ownership might be smart in C++, but in Python we have a garbage
> collector.
I wonder - what do you think of GTK+?
I've only used Qt with C++, and I've always been highly suspicious of wx
(something about the API, or the documentation… I haven't had a look at
it in a long time), but I always found PyGTK quite nice.
> 4. They might look bad (Tkinter, Swing with Jython).
Oh well.
Really, while Swing and Tkinter are particularly bad as they draw their
own widgets (instead of using a native toolkit), if you want your GUI to
look good, you'll need to write a separate GUI for each platform that
follows each platform's UI conventions.
> 5. All projects to write a Python GUI toolkit die before they are
> finished. (General lack of interest, bindings for Qt or wxWidgets
> bloatware are mature, momentum for web development etc.)
Aye, existing GUI toolkits are mature. They work. They do the job.
> 5. No particular GUI thread synchronization is needed -- Python has a
> GIL.
That's where you're wrong: the GIL is not a feature of Python. It is an
unfortunate implementation detail of current versions of CPython. (and
PyPy, apparently)
> 6. Expose the event loop to Python.
You can tap into the Gtk/GLib event loop. Don't other toolkits allow you
to write your own loop, using some kind of process_events() function to
take care of the GUI?
> 7. Preferably BSD-style license, not even LGPL.
Umm?
> 8. Written for Python in Python -- not bindings for a C++ or tcl
> toolkit.
HOLD ON a second:
> 4. They might look bad (Tkinter, Swing with Jython).
> [...] , if based on "native" widgets:
What do you propose? We know what happens when you write a fresh GUI
toolkit: Swing and Tkinter show us.
The only reasonable option to create a toolkit that actually looks good
is to base it on the "usual" GUI libraries.
> The Eclipse SWT library does some of this for Java does some of this,
> though it also has flaws (e.g. manual memory management). A Python GUI
> toolkit could be partially based on the SWT code.
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?
> Is it worth the hassle to start a new GUI toolkit project?
No.
> Or should modern deskop apps be written with something completely
> different, such as HTML5?
NO!!
Don't be silly. Even using a crappy windowing toolkit is a lot simpler
than doing the HTML/JavaScript/HTTP/etc dance.
Adam Tauno Williams
> What is wrong with them
> 1. Designed for other languages, particularly C++, tcl and Java.
> 2. Bloatware. Qt and wxWidgets are C++ application frameworks. (Python
> has a standard library!)
I've no idea what this means. I happily use pygtk.
As for "application frameworks" maybe you are referring to their having
their own event-loop, etc... They don't have any choice. A UI toolkit
has to have an event-loop and related pluming.
Gtk builds on top of glib; which has its own event-loop etc... This
makes perfect sense to me.
> 3. Unpythonic memory management: Python references to deleted C++
> objects (PyQt). Manual dialog destruction (wxPython). Parent-child
> ownership might be smart in C++, but in Python we have a garbage
> collector.
Widget registration / hierarchy != memory management.
> 4. They might look bad (Tkinter, Swing with Jython).
Sorry, I think Gtk apps are very nice looking.
> 5. All projects to write a Python GUI toolkit die before they are
> finished. (General lack of interest, bindings for Qt or wxWidgets
> bloatware are mature, momentum for web development etc.)
PyGTK just released version 3 with GObject introspection. etk.docking
went beta a few months ago [a pygtk docking solution]. All seems pretty
alive to me. And the developers respond to questions.
> How I would prefer the GUI library to be, if based on "native"
> widgets
> 1. Lean and mean -- do nothing but GUI. No database API, networking
> API, threading API, etc.
Sounds like PyGtk to me. All that other stuff and you are on your own.
Although I'd like to have data-model binding.
> 2. Do as much processing in Python as possible. No more native code
> (C, C++, Cython) than needed.
Unreasonable.
> 3. Instances of extension types can clean themselves up on
> deallocation. No parent-child ownership model to mess things up. No
> manual clean-up. Python does all the reference counting we need.
NEVER GOING TO HAPPEN. UI's don't work that way. They are inherently
hierarchical. Just get over it.
> 4. No artist framework. Use OpenGL, Cairo, AGG or whatever else is
> suitable
Gtk supports multiple canvas modes.
> 5. No particular GUI thread synchronization is needed -- Python has a
> GIL.
Wrong.
> 6. Expose the event loop to Python.
It is.
> 8. Written for Python in Python -- not bindings for a C++ or tcl
> toolkit.
Why. Pointless. That is just re-implementation.
Tim Chase
> How I would prefer the GUI library to be, if based on "native"
> widgets:
:-)
-tkc
Adam Tauno Williams
> On 20/07/11 04:12, sturlamolden wrote:
> > GIL.
> unfortunate implementation detail of current versions of CPython. (and
> PyPy, apparently)
And this GIL is certainly *not* a synchronization solution.
Even with a GIL you can hang yourself with threads - I've verified
this. :)
> > 6. Expose the event loop to Python.
> You can tap into the Gtk/GLib event loop.
+1
> What do you propose? We know what happens when you write a fresh GUI
> toolkit: Swing and Tkinter show us.
> The only reasonable option to create a toolkit that actually looks good
> is to base it on the "usual" GUI libraries.
+1
> It is perfectly reasonable to be required to manually call some sort of
> > Is it worth the hassle to start a new GUI toolkit project?
> No.
+1, or -1, errr.. which ever one means I agree with "no".
> > Or should modern deskop apps be written with something completely
> > different, such as HTML5
> NO!!
Barf.
Of course, Gtk [at least experimentally] supports an HTML5 canvas. A
good UI library provides a lot beyond painting-the-screen (there are
events, and packing/geometry, etc...). So even if you use HTML5 you are
then going to lay something on top of that [JavaScript + JQuery...].
> Don't be silly. Even using a crappy windowing toolkit is a lot simpler
> than doing the HTML/JavaScript/HTTP/etc dance.
+1
Stefan Behnel
> Or should modern deskop apps be written with something completely
> different, such as HTML5?
Depends. For many "desktop" apps, this is actually quite workable, with the
additional advantage of having an Internet-/Intranet-ready implementation
available in case you happen to need it later on.
Plus, you can take advantage of any HTML designers (as in "humans") you
happen to have around, whereas you are often a bit on your own when you
design a GUI using a toolkit, especially when you want it to work well in a
cross-platform way.
Stefan
Johann Hibschman
> On 20/07/11 04:12, sturlamolden wrote:
>> 3. Unpythonic memory management: Python references to deleted C++
>> objects (PyQt). Manual dialog destruction (wxPython). Parent-child
>> ownership might be smart in C++, but in Python we have a garbage
>> collector.
>
> I wonder - what do you think of GTK+?
> I've only used Qt with C++, and I've always been highly suspicious of wx
> (something about the API, or the documentation… I haven't had a look at
> it in a long time), but I always found PyGTK quite nice.
GTK+ doesn't work well at all on Mac, so if "cross-platform" includes
Macs, it's not a contender.
To quote the gtk-osx.sourceforge.net page:
Developers considering GTK+ as a cross-platform environment for new
work are advised to evaluate other toolkits carefully before
committing to GTK if they consider OSX an important market.
From experience, GTK apps are pretty awful on OSX.
-Johann
sturlamolden
> I wonder - what do you think of GTK+?
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.)
> Really, while Swing and Tkinter are particularly bad as they draw their
> own widgets
GTK and Qt do that as well.
> > The Eclipse SWT library does some of this for Java does some of this,
> > though it also has flaws (e.g. manual memory management). A Python GUI
> > toolkit could be partially based on the SWT code.
>
> Okay, I haven't used SWT yet: manual memory management? Java is GC!
So is Python, yet wxPython require manual destruction of dialogs as
well.
> 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
Yes, but not to avoid a memory leak.
Sturla
Grant Edwards
>> 5. No particular GUI thread synchronization is needed -- Python has a
>> GIL.
>
> That's where you're wrong: the GIL is not a feature of Python. It is an
> unfortunate implementation detail of current versions of CPython. (and
> PyPy, apparently)
And there are always people trying to figure out how to get rid of it.
So far the cures have been worse than the disease, but that may not
always be the case...
--
Grant Edwards grant.b.edwards Yow! ... the HIGHWAY is
at made out of LIME JELLO and
gmail.com my HONDA is a barbequeued
OYSTER! Yum!
Grant Edwards
> On Tue, 2011-07-19 at 19:12 -0700, sturlamolden wrote:
>> What is wrong with them
>> 1. Designed for other languages, particularly C++, tcl and Java.
>> 2. Bloatware. Qt and wxWidgets are C++ application frameworks. (Python
>> has a standard library!)
>
> I've no idea what this means. I happily use pygtk.
I agree. PyGTK works great -- on platforms where GTK works great.
--
Grant Edwards grant.b.edwards Yow! !! I am having fun!!!
at
gmail.com
Mel
OTOH, if you intend to re-use the Dialog object, it's not a memory leak.
Mel.
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
> 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
> > 3. Instances of extension types can clean themselves up on
> > deallocation. No parent-child ownership model to mess things up. No
> > manual clean-up. Python does all the reference counting we need.
>
> 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.
Thomas Jollans
> On 20 Jul, 11:59, Thomas Jollans <t...@jollybox.de> wrote:
>
>> I wonder - what do you think of GTK+?
>
> 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.
>> Really, while Swing and Tkinter are particularly bad as they draw their
>> own widgets
>
> 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
+comp.lang.pyt...@pearwood.info> wrote:
> 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.
>>> import Tkinter
>>> Tkinter.TkVersion
8.5
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
> On Jul 20, 10:32am, rantingrick <rantingr...@gmail.com> wrote:
>
> > 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.
>
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
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
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.
Ben Finney
> Tkinter sucks because it looks like an enfeebled Motif 1980s dawn-of-
> GUIs scratchy window with grooves and lines everywhere.
Applications have been written that look like that, sure. Many of them
were *written* in the 1980s and 1990s, so the wonder is not how they
look but that they still work today at all.
To continue supporting those old applications, written with the
assumption that the widgets will look like Motif, Tk must default to
looking like ugly old Motif.
But it simply is not true that Tk applications *must* look like Motif,
or even close. We have for a long time had the “themed Tk” extension
<URL:http://wiki.tcl.tk/14796> which makes themed and/or native widgets
in Tk.
Python's Tkinter has this at the ‘tkinter.ttk’ module
<URL:http://docs.python.org/py3k/library/tkinter.ttk.html>, or for
Python 2 at <URL:http://pypi.python.org/pypi/pyttk>.
> Oh, and you can TDD it. Unlike some more "modern" GUIs I could
> mention...
Yes, the ability to test one's GUI from unit test code is a huge plus.
--
\ “Everyone is entitled to their own opinions, but they are not |
`\ entitled to their own facts.” —US Senator Pat Moynihan |
_o__) |
Ben Finney
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
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.
alex23
> The old "reinvent the wheel" argument is only valid when wheels
> already exists. Currently we have triangles (or maybe pentagons) but
> no wheels.
No, currently we have a small handful of people who feel the wheels
are triangles but have done nothing more than complain about it, while
those who don't feel likewise continue to cycle on them smoothly.
The "reinvent the wheel" argument is only valid when the affected
people do something other than whine.
alex23
> What about the etiquette of staying on topic?
Such as raising your personal opinion of online etiquette in a thread
on GUI toolkits?
As always, there's what you say, and there's what you do, and never
the twain shall meet.
Steven D'Aprano
Ha ha, rantingrick lecturing others on rudeness! How cute!
Or hypocritical. Sometimes I get those two confused.
--
Steven
Cameron Simpson
|
| RE: *Tim Chase changes topic and talks smack*
|
| On Jul 20, 8:38 pm, Tim Chase <python.l...@tim.thechases.com> wrote:
| > On 07/20/2011 08:17 PM, rantingrick wrote:
| >
| > > RE: *Ben Finney changes thread subject*
| >
| > > Please everyone, do not change the subject of someone's thread because
| > > it's considered rude. Thank you.
| >
| > 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.
|
| 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.
You're labouring under a misapprehension. The OP doesn't "own" the
thread. Starting a thread on a public list is like throwing a party.
People are going to come. And talk, damn their impudence!
It is good to stay near the topic, but threads will inevitably drift
unless they're talking about something utterly trite. It is good of an
author to mark his/her departure from the main topic, should it be
significant, with a subject change. Or even a new thread.
| How would you like it if i came to your house
You can stop there, thanks.
You continue to confuse a cooperative anarchy with some kind of
stringent autocracy or heavily premoderated forum or something.
As with your docstring formatting opinions or your spaces-vs-tabs
opinions: mandating behaviour is a little pointless - it can't be
enforced, few directives are unambiguously one sidedly good and so
mandating stuff is divisive and will drive people away.
Cheers,
--
Cameron Simpson <c...@zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/
It's quite difficult to remind people that all this stuff was here for a
million years before people. So the idea that we are required to manage it is
ridiculous. What we are having to manage is us.
- Bill Ballantine, marine biologist
Kevin Walzer
> On Jul 19, 9:44 pm, Kevin Walzer<k...@codebykevin.com> wrote:
>
>>> 2. Bloatware. Qt and wxWidgets are C++ application frameworks. (Python
>>> has a standard library!)
>>
>> Again, so? This isn't applicable to Tk, by the way. It's a GUI toolkit
>> specifically designed for scripting languages.
>
> Tk is SPECIFICALLY designed for TCL. Tkinter works ONLY by embedding a
> TCL interpreter. You statements are misleading.
Of course I know this--I'm one of the core Tcl/Tk developers on my
platform. :-) My statement was actually based on Mark Lutz's
characterization in "Programming Python," when he defends Tk's inclusion
in the stdlib (and his own book's extensive focus on it) by observing
that the toolkit was specifically designed for use with scripting
languages--Tcl at the start, but also Python, Perl, Ruby...he seemed to
want to downplay Tk's Tcl-ish roots, as if he were embarassed by them. I
guess it's a Tcl-ish subject.
>>> 3. Unpythonic memory management: Python references to deleted C++
>>> objects (PyQt). Manual dialog destruction (wxPython). Parent-child
>>> ownership might be smart in C++, but in Python we have a garbage
>>> collector.
>>
>> Again, so? Again, this isn't applicable to Tk.
>
> He did not even mention Tk in that block, do you have a TK persecution
> complex?
No, but it's an advantage that Tk has over the other ones, and an
argument that reinventing the wheel is unncessary.
>
>>> 4. They might look bad (Tkinter, Swing with Jython).
>>
>> Then again, they might not. A lot depends on the skill of the
>> developer. I write highly polished commercial apps with Tk GUI's. I'm
>> sick of developers blaming their ugly apps on the toolkit rather than
>> their own lack of design training and/or skills.
>
> This is true. Lots of people lack the skill to create professional
> quality GUI applications however lots of GUI devs lack the skill to
> create clean and intuitive API's also. Tkinter/TclTk and WxPython
> \WxWidgets has lots of warts in this respect.
I think what constitutes a "clean API" is partly a matter of taste.
>
>>> 5. All projects to write a Python GUI toolkit die before they are
>>> finished. (General lack of interest, bindings for Qt or wxWidgets
>>> bloatware are mature, momentum for web development etc.)
>>
>> That's right. People issue a clarion call for a new GUI toolkit, then
>> discover that even a so-called "ugly, limited, minimalist" toolkit like
>> Tk has twenty years of development behind it. And people think they can
>> duplicate this effort in a few months by starting a flame war on
>> comp.lang.python?
>
> Just because someone wants to entertain ideas for a new GUI does mean
> they are starting flame wars. I would say out all the responses so far
> YOURS is the most emotional.
*shrug*
Maybe it is. I prefaced this by saying, "OK, I'll bite," which suggests
that perhaps I shouldn't, because complaints and hand-wringing are
really a waste of time. In the future, I think my response (if I make
one at all) will more likely be something like this:
"An interesting idea. Please post back when you have a source code repo,
build instructions so we can play with your code, a mailing list, and a
license that is suitable for both open-source and proprietary development."
The most substantial effort at developing a new GUI API for Python did
just this--PySide (alternative bindings to Qt). No hand-wringing, no
flame wars, just an announcement of the project, an invitation to
contribute, and so on. Whether you think it's a misguided project or an
attempt to reinvent the wheel is beside the point--it's a substantial
project, with both leadership and a growing community that support
ongoing development and rapid maturation.
In my own experience, this is the only way to move things forward or
bring about any useful change--roll up my sleeves and do it myself. I've
done this a bit with Tkinter (maintaining bindings/wrappers to a popular
Tk widget, tablelist), but I've done this extensively with Tk itself on
the Mac. I complained on mailing lists for years that Tk didn't do this
or that on the Mac, and these complaints fell on deaf ears; finally, I
decided to dive into the deep end, learn the low-level API's to do what
I wanted, and bingo! Suddenly Tk did what I wanted.
That's the essence of open-source development--scratching your own itch.
Sometimes you get lucky and a large corporate entity has an itch to
scratch, and this can bring large-scale projects with large-scale
benefits. I believe Nokia is funding PySide. While Tk's port to the
Mac's Cocoa API was done by a single developer, the project was funded
by Apple. Creating a new GUI toolkit may require this scale of effort
and investment. But even without it, if a developer can get something
started and make enough progress to be of interest to others, then a
larger community may move the project forward.
Code trumps everything.
>
>>> 1. Lean and mean -- do nothing but GUI. No database API, networking
>>> API, threading API, etc.
>>
>> Presenting...Tk.
>
> True Tkinter does no Database, networking, threading, etc. However i
> would not call an embedded TCl interpreter "lean and mean".
Perhaps not. Creating a pure-Python GUI toolkit that provides native
integration with X11, Windows, and OS X windowing systems would be "lean
and mean"--but it would also be a lot of work. And, assuming the project
went forth to completion, I bet that other scripting languages would
piggyback on top of it (Lua or Ruby bindings for Python's GUI toolkit,
anyone?) because doing that is less work than writing your own toolkit
from scratch.
>
>>> 2. Do as much processing in Python as possible. No more native code
>>> (C, C++, Cython) than needed.
>>
>> And what's wrong with native (ie. compiled) code? Python is written in
>> native code, isn't it? To extend Python in significant ways, it is often
>> necessary to drop down into native code.
>
> I will agree with Kevin here. Hey, he's not ALWAYS wrong you know;
> just most of the time! ;-)
Meh.
>
>>> 6. Expose the event loop to Python.
>>
>> Presenting...Tk.
>
> Tk's event binding (whist quite powerful) is also quite overwhelming
> in the sheer number of event sequences alone and leads to spaghetti
> code. See my recent thread about the subject.
This is a matter of taste.
>
>>> 8. Written for Python in Python -- not bindings for a C++ or tcl
>>> toolkit.
>>
>> Well, that's the holy grail, but given the history of other toolkits,
>> you'll reach a comparable level of maturity in 2031.
>
> I think it could happen much sooner if people got serious. However it
> won't happen tomorrow for sure.
Certainly not.
>>> Is it worth the hassle to start a new GUI toolkit project?
>>
>> Not unless you want to reinvent the wheel yet again.
>
> The old "reinvent the wheel" argument is only valid when wheels
> already exists. Currently we have triangles (or maybe pentagons) but
> no wheels.
Well, I have two closing responses:
"Let's see your code, repo, mailing list, and license."
and:
"I'm bowing out now."
--Kevin
--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
Gregory Ewing
> Or should modern deskop apps be written with something completely
> different, such as HTML5?
I hope not! HTML is great for web pages, but not
everything should be a web page.
--
Greg
Gregory Ewing
> It has quite a few external dependencies, though (different dependencies
> for each platform, so it requires a lot to be cross-platform).
I think that's a bit of an exaggeration -- there's only
one major dependency on each platform, and it's a very
widely used one (currently PyObjC/PyGTK/PyWin32). And
I'm thinking about ways to reduce the dependencies further,
--
Greg
sturlamolden
> I think that's a bit of an exaggeration -- there's only
> one major dependency on each platform, and it's a very
> widely used one (currently PyObjC/PyGTK/PyWin32). And
> I'm thinking about ways to reduce the dependencies further,
Pyrex or Cython?
sturlamolden
> I bet that other scripting languages would
> piggyback on top of it (Lua or Ruby bindings for Python's GUI toolkit,
> anyone?) because doing that is less work than writing your own toolkit
> from scratch.
No doubt about that.
Lua has a nice GUI toolkit by the way, which also has a C API.
Currently it works on GTK+, Motif and Window. The C API is very small,
only about 100 functions. So it makes a good candidate for a new
Cython-based toolkit, even without piggybacking on Lua.
Tim Roberts
I don't think your glibness is justified. There is a legitimate appeal to
this notion. The fact is that MANY APIs can be completely and adequately
described by HTML. It provides a very natural separation of presentation
and behavior. Without style sheets, you can describe simple APIs very
compactly and let the renderer do positioning. With style sheets, you can
get very complete control over the look and feel.
This is very similar to what Microsoft has done with Windows Presentation
Foundation, except that they are using a more sophisticated XML DTD.
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.
Gregory Ewing
> Gregory Ewing <greg....@canterbury.ac.nz> wrote:
>
>>sturlamolden wrote:
>>
>>>Or should modern deskop apps be written with something completely
>>>different, such as HTML5?
>>
>>I hope not! HTML is great for web pages, but not
>>everything should be a web page.
>
> I don't think your glibness is justified. There is a legitimate appeal to
> this notion. The fact is that MANY APIs can be completely and adequately
> described by HTML.
My brain raises a TypeError on that statement. According to
my understanding of the world, describing APIs is not something
that HTML does. (Or did you mean GUI rather than API?)
There might be some sense in using something HTML-like to
describe the layout of widgets in a GUI. But laying out
widgets is only a tiny part of what's involved in creating
an application with a GUI. You still need a GUI toolkit to
provide the widgets being laid out, and application code
behind that to provide the desired functionality.
> With style sheets, you can
> get very complete control over the look and feel.
CSS is designed for graphic artists who want complete
control over every aspect of appearance. Again, this is
(arguably) okay for web pages, but I don't think it
applies to GUI applications. You *don't* want every
application looking completely different from every other
on the whim of the author -- quite the opposite.
--
Greg
Cameron Simpson
| Tim Roberts wrote:
| >Gregory Ewing <greg....@canterbury.ac.nz> wrote:
| >>sturlamolden wrote:
| >>>Or should modern deskop apps be written with something completely
| >>>different, such as HTML5?
| >>
| >>I hope not! HTML is great for web pages, but not
| >>everything should be a web page.
| >
| >I don't think your glibness is justified. There is a legitimate appeal to
| >this notion. The fact is that MANY APIs can be completely and adequately
| >described by HTML.
| There might be some sense in using something HTML-like to
| describe the layout of widgets in a GUI. But laying out
| widgets is only a tiny part of what's involved in creating
| an application with a GUI. You still need a GUI toolkit to
| provide the widgets being laid out, and application code
| behind that to provide the desired functionality.
Sure, but if a suitable API is presented for javascript to hook into
over HTTP an HTML widget kit isn't an unreasonable thing to build.
And then you have the cross platform nirvana. Except for the browsers'
various differences and bugs etc etc...
| >With style sheets, you can
| >get very complete control over the look and feel.
|
| CSS is designed for graphic artists who want complete
| control over every aspect of appearance. Again, this is
| (arguably) okay for web pages, but I don't think it
| applies to GUI applications. You *don't* want every
| application looking completely different from every other
| on the whim of the author -- quite the opposite.
You can override site specific CSS in the firefox browser, possibly
others. There are extensions to make it easier rather than mega-awkward
and undocumented. It is still a bit of a dobge, in not small part
because CSS lacks a "not" - you can't say "style everything except
blah", which means you have to enumerate a bazillion combinations and
you're still playing guessing games.
So, yes, the every author's look'n'feel is gratuitously different chaos
still applies :-(
Cheers,
--
Cameron Simpson <c...@zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/
But what ... is it good for?
--Engineer at the Advanced Computing Systems Division of IBM,
1968, commenting on the microchip.
Chris Angelico
> And then you have the cross platform nirvana. Except for the browsers'
> various differences and bugs etc etc...
>
The "platform" ceases to be Windows/Linux/Mac, ceases to be Qt/GTK/Tk,
and instead becomes Webkit/Gecko/Trident. It's still not perfectly
cross-platform. (Although the recent ones are tending to comply with
the standards better than during the old IE vs Netscape browser wars.)
ChrisA
John Nagle
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: RIPEMD160
>
> There's PyGUI, which, at a glance, fits whit what you want. Looks like
> it uses OpenGL and native GUI facilities.
> http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/
>
> It has quite a few external dependencies, though (different dependencies
> for each platform, so it requires a lot to be cross-platform).
It still uses Tcl/Tk stuff, which is un-Pythonic.
John Nagle
lkcl
> On 7/19/2011 10:12 PM, sturlamolden wrote:
>
>
>
> > What is wrong with them:
>
> > 1. Designed for other languages, particularly C++, tcl and Java.
>
> > 2. Bloatware. Qt and wxWidgets are C++ application frameworks. (Python
> > has a standard library!)
>
> > objects (PyQt). Manual dialog destruction (wxPython). Parent-child
> > ownership might be smart in C++, but in Python we have a garbage
> > collector.
>
>
> > finished. (General lack of interest, bindings for Qt or wxWidgets
> > bloatware are mature, momentum for web development etc.)
>
>
>
>
> > How I would prefer the GUI library to be, if based on "native"
> > widgets:
>
> > 1. Lean and mean -- do nothing but GUI. No database API, networking
> > API, threading API, etc.
>
> > (C, C++, Cython) than needed.
>
> > deallocation. No parent-child ownership model to mess things up. No
> > manual clean-up. Python does all the reference counting we need.
>
> > 4. No artist framework. Use OpenGL, Cairo, AGG or whatever else is
> > suitable.
>
> > 5. No particular GUI thread synchronization is needed -- Python has a
> > GIL.
>
> > 6. Expose the event loop to Python.
>
>
> > 8. Written for Python in Python -- not bindings for a C++ or tcl
> > toolkit.
>
>
> > Is it worth the hassle to start a new GUI toolkit project?
>
>
> > Or should modern deskop apps be written with something completely
> > different, such as HTML5?
>
> direction,
weeelll... we kinda want to keep as many platforms supported as
possible, so that includes IE6 canvas (VML) which surprisingly works
pretty damn good, the only thing missing is being able to add text to
VML canvas: everything else (including colour gradients) shockingly
actually works. it's slow, but what do you expect out of IE6, duh.
but yes we're finding that an increasing number of people are saying
"i wrote a pyajamas app, it used direct HTML5, sod the browsers that
don't properly support HTML5" and i think that's a good thing.
> but the author says he will never port to Py3. (He explained
> his reasons on this list when I suggested that.)
:) it's not quiiite a matter of "never" - it's conditional. the
conditions on which i, personally and extremely grudgingly, will get
involved in a py3 port of pyjamas are when it becomes hellishly
difficult for myself, personally, to maintain all of the components of
pyjamas *including* the desktop ports (w32 MSHTML, gnu pythonwebkit
project, xulrunner N.N) which people tend to forget exist for python
2.N. the reason for that are a) personally i don't like py3 (because
it didn't include backwards-compatibility for python 2) b) the pyjs
translator is self-contained, and has at absolutely no time any need
for any links at runtime to in fact any python *at all* (because the
pyjs version runs on a javascript engine *not* a python engine).
there's no "never" in there - it's just that i'll keep reviewing the
situation, and i anticipate / predict that it will begin to become
difficult to compile python2 applications (such as python-comtypes) at
some point in approx ooo... 5 to 7 years. maybe not - it's hard to
say.
anyway - if however someone else wants to collaborate and/or fund a
py3 port of pyjamas, knock yourself out: just bear in mind that it's
an estimated 18 man-month project.
l.
Tim Roberts
>Tim Roberts wrote:
>>
>> I don't think your glibness is justified. There is a legitimate appeal to
>> this notion. The fact is that MANY APIs can be completely and adequately
>> described by HTML.
>
>My brain raises a TypeError on that statement. According to
>my understanding of the world, describing APIs is not something
>that HTML does. (Or did you mean GUI rather than API?)
Yes, you are correct. Brain fart on my part.
Gregory Ewing
>> There's PyGUI, which, at a glance, fits whit what you want. Looks like
>> it uses OpenGL and native GUI facilities.
>> http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/
>
> It still uses Tcl/Tk stuff, which is un-Pythonic.
You must be thinking of something else. My PyGUI has nothing
to do with Tcl/Tk at all.
--
Greg
Michael Torrie
> Please everyone, do not change the subject of someone's thread
> because it's considered rude. Thank you.
Too funny. Says who? Changing the subject line to reflect the
direction this part of the thread (a branch if you will) is going is
definitely appropriate. At least according to etiquette rules that go
back for some time (likely before you were around--you're pretty young
no?)
Besides forking is a time-honored open source tradition.
> 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.
Oh really. I guess since you are one of the leaders I guess it must be
so. Too funny.
Fortunately not all of us are using the crippled one-dimensional
Gmail "conversation" way of reading threads on e-mails. So as long as
the topic is appropriately changed, we can deal with branches that twist
and turn. My e-mail reader threads them all quite nicely.
Now replying to an existing thread to start an entirely new, unrelated
thread is definitely rude.
> 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.
Did you study "logical fallacies" in English classes at uni? (If she
weighs the same as a duck then she's made of wood, and therefore she's a
witch).
And as for manners go, I'm glad to see you've improved so much in the
last year. Who knows you might just be removed from kill files yet.
Grant Edwards
Like Tkinter does?
I thought PyGUI it was based on GTk? That's what the web page seems
to indicate.
--
Grant
Terry Reedy
> Now replying to an existing thread to start an entirely new, unrelated
> thread is definitely rude.
Rude or not, it tends to be unproductive. If someone posted "Help with
threading internals" here, it could well not be seen by the appropriate
people, especially if they have threads collapsed.
--
Terry Jan Reedy