Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #9925 > unrolled thread

I am fed up with Python GUI toolkits...

Back to article view | Back to comp.lang.python

Contents

  I am fed up with Python GUI toolkits... sturlamolden <sturlamolden@yahoo.no> - 2011-07-19 19:12 -0700
    Re: I am fed up with Python GUI toolkits... Terry Reedy <tjreedy@udel.edu> - 2011-07-19 22:34 -0400
      Re: I am fed up with Python GUI toolkits... lkcl <luke.leighton@gmail.com> - 2011-07-24 12:30 -0700
    Re: I am fed up with Python GUI toolkits... Andrew Berg <bahamutzero8825@gmail.com> - 2011-07-19 21:34 -0500
      Re: I am fed up with Python GUI toolkits... Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-07-22 12:34 +1200
        Re: I am fed up with Python GUI toolkits... sturlamolden <sturlamolden@yahoo.no> - 2011-07-22 03:30 -0700
      Re: I am fed up with Python GUI toolkits... John Nagle <nagle@animats.com> - 2011-07-24 10:02 -0700
        Re: I am fed up with Python GUI toolkits... Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-07-25 11:59 +1200
        Re: I am fed up with Python GUI toolkits... Grant Edwards <invalid@invalid.invalid> - 2011-07-25 01:37 +0000
    Re: I am fed up with Python GUI toolkits... Kevin Walzer <kw@codebykevin.com> - 2011-07-19 22:44 -0400
      Re: I am fed up with Python GUI toolkits... rantingrick <rantingrick@gmail.com> - 2011-07-20 06:05 -0700
        Re: I am fed up with Python GUI toolkits... alex23 <wuwei23@gmail.com> - 2011-07-20 20:20 -0700
        Re: I am fed up with Python GUI toolkits... Kevin Walzer <kw@codebykevin.com> - 2011-07-21 10:52 -0400
          Re: I am fed up with Python GUI toolkits... sturlamolden <sturlamolden@yahoo.no> - 2011-07-22 03:38 -0700
    Re: I am fed up with Python GUI toolkits... Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-07-20 14:28 +1000
      Re: I am fed up with Python GUI toolkits... Stefan Behnel <stefan_ml@behnel.de> - 2011-07-20 09:20 +0200
        Re: I am fed up with Python GUI toolkits... Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-07-20 17:28 +1000
          Re: I am fed up with Python GUI toolkits... Andrew Berg <bahamutzero8825@gmail.com> - 2011-07-20 02:51 -0500
            Re: I am fed up with Python GUI toolkits... Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-07-20 18:25 +1000
      Re: I am fed up with Python GUI toolkits... sturlamolden <sturlamolden@yahoo.no> - 2011-07-20 09:39 -0700
      Re: I am fed up with Python GUI toolkits... rantingrick <rantingrick@gmail.com> - 2011-07-20 10:32 -0700
        Re: I am fed up with Python GUI toolkits... Phlip <phlip2005@gmail.com> - 2011-07-20 13:58 -0700
          Re: I am fed up with Python GUI toolkits... sturlamolden <sturlamolden@yahoo.no> - 2011-07-20 15:13 -0700
            Re: I am fed up with Python GUI toolkits... Phlip <phlip2005@gmail.com> - 2011-07-20 15:52 -0700
              Re: I am fed up with Python GUI toolkits... sturlamolden <sturlamolden@yahoo.no> - 2011-07-20 16:02 -0700
          Re: I am fed up with Python GUI toolkits... Corey Richardson <kb1pkl@aim.com> - 2011-07-20 18:19 -0400
          Re: I am fed up with Python GUI toolkits... sturlamolden <sturlamolden@yahoo.no> - 2011-07-20 15:41 -0700
          Tkinter in Python has native widgets (was: I am fed up with Python GUI toolkits...) Ben Finney <ben+python@benfinney.id.au> - 2011-07-21 11:00 +1000
    Re: I am fed up with Python GUI toolkits... Ian Kelly <ian.g.kelly@gmail.com> - 2011-07-20 01:02 -0600
    Re: I am fed up with Python GUI toolkits... Thomas Jollans <t@jollybox.de> - 2011-07-20 11:59 +0200
      Re: I am fed up with Python GUI toolkits... Johann Hibschman <jhibschman+usenet@gmail.com> - 2011-07-20 07:16 -0500
      Re: I am fed up with Python GUI toolkits... sturlamolden <sturlamolden@yahoo.no> - 2011-07-20 06:47 -0700
        Re: I am fed up with Python GUI toolkits... Mel <mwilson@the-wire.com> - 2011-07-20 10:17 -0400
          Re: I am fed up with Python GUI toolkits... sturlamolden <sturlamolden@yahoo.no> - 2011-07-20 07:27 -0700
            Re: I am fed up with Python GUI toolkits... rantingrick <rantingrick@gmail.com> - 2011-07-20 08:09 -0700
        Re: I am fed up with Python GUI toolkits... Thomas Jollans <t@jollybox.de> - 2011-07-20 17:21 +0200
          Re: I am fed up with Python GUI toolkits... sturlamolden <sturlamolden@yahoo.no> - 2011-07-20 08:40 -0700
      Re: I am fed up with Python GUI toolkits... Grant Edwards <invalid@invalid.invalid> - 2011-07-20 14:10 +0000
      Re: I am fed up with Python GUI toolkits... sturlamolden <sturlamolden@yahoo.no> - 2011-07-20 07:30 -0700
    Re: I am fed up with Python GUI toolkits... Adam Tauno Williams <awilliam@whitemice.org> - 2011-07-20 07:04 -0400
      Re: I am fed up with Python GUI toolkits... Grant Edwards <invalid@invalid.invalid> - 2011-07-20 14:12 +0000
      Re: I am fed up with Python GUI toolkits... sturlamolden <sturlamolden@yahoo.no> - 2011-07-20 07:41 -0700
    Re: I am fed up with Python GUI toolkits... Tim Chase <python.list@tim.thechases.com> - 2011-07-20 06:08 -0500
      Re: I am fed up with Python GUI toolkits... sturlamolden <sturlamolden@yahoo.no> - 2011-07-20 07:45 -0700
    Re: I am fed up with Python GUI toolkits... Adam Tauno Williams <awilliam@whitemice.org> - 2011-07-20 07:16 -0400
    Re: I am fed up with Python GUI toolkits... Stefan Behnel <stefan_ml@behnel.de> - 2011-07-20 13:31 +0200
    Re: I am fed up with Python GUI toolkits... rantingrick <rantingrick@gmail.com> - 2011-07-20 05:52 -0700
    Re: I am fed up with Python GUI toolkits... rantingrick <rantingrick@gmail.com> - 2011-07-20 18:17 -0700
      Re: changing thread topics (was: I am fed up with Python GUI toolkits...) Tim Chase <python.list@tim.thechases.com> - 2011-07-20 20:38 -0500
      Changing subject sucks. Re: I am fed up with Python GUI toolkits... Phlip <phlip2005@gmail.com> - 2011-07-20 19:34 -0700
        Re: Changing subject sucks. Re: I am fed up with Python GUI toolkits... Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-07-21 14:08 +1000
      Re: I am fed up with Python GUI toolkits... Michael Torrie <torriem@gmail.com> - 2011-07-24 18:51 -0600
      Re: I am fed up with Python GUI toolkits... Terry Reedy <tjreedy@udel.edu> - 2011-07-24 22:06 -0400
    Re: I am fed up with Python GUI toolkits... rantingrick <rantingrick@gmail.com> - 2011-07-20 19:06 -0700
      Re: I am fed up with Python GUI toolkits... alex23 <wuwei23@gmail.com> - 2011-07-20 20:32 -0700
      Re: I am fed up with Python GUI toolkits... Cameron Simpson <cs@zip.com.au> - 2011-07-21 15:44 +1000
    Re: I am fed up with Python GUI toolkits... Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-07-22 12:30 +1200
      Re: I am fed up with Python GUI toolkits... Tim Roberts <timr@probo.com> - 2011-07-22 23:36 -0700
        Re: I am fed up with Python GUI toolkits... Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-07-23 22:21 +1200
          Re: I am fed up with Python GUI toolkits... Cameron Simpson <cs@zip.com.au> - 2011-07-24 13:56 +1000
          Re: I am fed up with Python GUI toolkits... Chris Angelico <rosuav@gmail.com> - 2011-07-24 15:00 +1000
          Re: I am fed up with Python GUI toolkits... Tim Roberts <timr@probo.com> - 2011-07-24 16:24 -0700

Page 1 of 4  [1] 2 3 4  Next page →

#9925 — I am fed up with Python GUI toolkits...

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

[toc] | [next] | [standalone]

#9928

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

[toc] | [prev] | [next] | [standalone]

#10224

On Jul 20, 3:34 am, Terry Reedy <tjre...@udel.edu> wrote:
> 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!)
>
> > 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 thepyjamasproject is aimed in this
> 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.

[toc] | [prev] | [next] | [standalone]

#9929

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

[toc] | [prev] | [next] | [standalone]

#10055

Andrew Berg wrote:

> 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

[toc] | [prev] | [next] | [standalone]

#10092

On 22 Jul, 02:34, Gregory Ewing <greg.ew...@canterbury.ac.nz> wrote:

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

[toc] | [prev] | [next] | [standalone]

#10213

On 7/19/2011 7:34 PM, Andrew Berg wrote:
> -----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

[toc] | [prev] | [next] | [standalone]

#10232

John Nagle wrote:

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

[toc] | [prev] | [next] | [standalone]

#10238

On 2011-07-24, John Nagle <nagle@animats.com> wrote:
> On 7/19/2011 7:34 PM, Andrew Berg wrote:
>> -----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.

Like Tkinter does?

I thought PyGUI it was based on GTk?  That's what the web page seems
to indicate.

-- 
Grant

[toc] | [prev] | [next] | [standalone]

#9930

OK, I'll bite...

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

[toc] | [prev] | [next] | [standalone]

#9964

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.

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

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

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

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

> > 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! ;-)

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

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


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

[toc] | [prev] | [next] | [standalone]

#10007

rantingrick <rantingr...@gmail.com> wrote:
> 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.

[toc] | [prev] | [next] | [standalone]

#10027

On 7/20/11 9:05 AM, rantingrick wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#10094

On 21 Jul, 16:52, Kevin Walzer <k...@codebykevin.com> wrote:
> 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.

http://www.tecgraf.puc-rio.br/iup/

[toc] | [prev] | [next] | [standalone]

#9934

On Wed, 20 Jul 2011 12:12 pm sturlamolden wrote:

> 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

[toc] | [prev] | [next] | [standalone]

#9944

Steven D'Aprano, 20.07.2011 06:28:
>> Python has a GIL.
>
> Except for Jython, IronPython and PyPy.

PyPy has a GIL, too.

Stefan

[toc] | [prev] | [next] | [standalone]

#9945

On Wed, 20 Jul 2011 05:20 pm Stefan Behnel wrote:

> Steven D'Aprano, 20.07.2011 06:28:
>>> Python has a GIL.
>>
>> Except for Jython, IronPython and PyPy.
> 
> PyPy has a GIL, too.

Isn't it optional though?




-- 
Steven

[toc] | [prev] | [next] | [standalone]

#9949

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

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

[toc] | [prev] | [next] | [standalone]

#9952

On Wed, 20 Jul 2011 05:51 pm Andrew Berg wrote:

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

[toc] | [prev] | [next] | [standalone]

#9982

On 20 Jul, 06:28, Steven D'Aprano <steve
+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

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.python

csiph-web