I am fed up with Python GUI toolkits...

S

sturlamolden

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.)


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
 
T

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.)
 
A

Andrew Berg

-----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).

- --
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-----
 
K

Kevin Walzer

OK, I'll bite...

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
 
S

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.
 
I

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.
 
T

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.
 
A

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.
 
A

Adam Tauno Williams

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 this GIL is certainly *not* a synchronization solution.

Even with a GIL you can hang yourself with threads - I've verified
this. :)
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
No.

+1, or -1, errr.. which ever one means I agree with "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
 
S

Stefan Behnel

sturlamolden, 20.07.2011 04:12:
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
 
J

Johann Hibschman

Thomas Jollans said:
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
 
R

rantingrick

What is wrong with them:

1. Designed for other languages, particularly C++, tcl and Java.

This fact bugs me but no one is willing to put forth an effort to make
things happen. So we are stuck with what we have now.
3. Unpythonic memory management: Python references to deleted C++
objects (PyQt). Manual dialog destruction (wxPython).

Users should NEVER need to explicitly destroy a dialog. However it
would (should) be easy to subclass the wxDialg and create your own
logic tied to the ok and cancel buttons. See tkSimpleDialog for old
inspiration or see my threads on tkSimpleDialog improved for modern
inspiration.
Parent-child
ownership might be smart in C++, but in Python we have a garbage
collector.

There is nothing wrong with hierarchy. Please show examples where this
relationship fails.
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.)

Well you've got to get some "like minds" together. I would be willing
to participate on something more Pythonic. PyGUI looks promising.

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.
PyGUI

2. Do as much processing in Python as possible. No more native code
(C, C++, Cython) than needed.

Some heavy lifting must be done in these languages.
3. Instances of extension types can clean themselves up on
deallocation. No parent-child ownership model to mess things up.

I don't see how that "messes things up"?
4. No artist framework. Use OpenGL, Cairo, AGG or whatever else is
suitable.

Hopefully you want a canvas at least. I don't think i could get by
without one. Not only is a canvas good for drawing graphics via user
input but also for creating custom widgets that the GUI does not
expose.
6. Expose the event loop to Python.

This would be nice.
8. Written for Python in Python -- not bindings for a C++ or tcl
toolkit.

Agreed! Wx is nice but feels too much like writing C.
Is it worth the hassle to start a new GUI toolkit project?

It's a huge hassle and might be much better to grow/repair some
existing API's. PyGUI is one however it's very young. Tkinter could
use some re-factoring however it will always be based on an embedded
TCL interpreter doing "magic" behind the scenes.
Or should modern deskop apps be written with something completely
different, such as HTML5?

F___ NO! That sort of thing needs many more years to mature. Currently
we are in the beginning phases when everybody has "their" idea of what
is perfect and nobody agrees on which is best. Plus you have many
incompatibilities between the major browsers. People like to parrot
off about how cross-platform these things are compared to GUI; and
that's true only for the same version of the same browser. You just
switch from OS incompatibility to browser incompatibility.
 
R

rantingrick

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.
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?
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.
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.
Presenting...Tk.

True Tkinter does no Database, networking, threading, etc. However i
would not call an embedded TCl interpreter "lean and mean".
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! ;-)
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.
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.

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.
 
S

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.

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
 
G

Grant Edwards

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...
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top