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 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#9984

On Jul 19, 11:28 pm, 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?

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.

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

#9993

On Jul 20, 10:32 am, 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.

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

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

#9994

On 20 Jul, 22:58, Phlip <phlip2...@gmail.com> wrote:

> 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

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

#9997

On Jul 20, 3:13 pm, sturlamolden <sturlamol...@yahoo.no> wrote:

> On 20 Jul, 22:58, Phlip <phlip2...@gmail.com> wrote:
>
> > 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).

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

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

#9998

On 21 Jul, 00:52, Phlip <phlip2...@gmail.com> wrote:

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

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

#9995

[Multipart message — attachments visible in raw view] — view raw

Excerpts from Phlip's message of Wed Jul 20 16:58:08 -0400 2011:
> 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

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

#9996

On 20 Jul, 22:58, Phlip <phlip2...@gmail.com> wrote:

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

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

#9999 — Tkinter in Python has native widgets (was: I am fed up with Python GUI toolkits...)

Phlip <phlip2005@gmail.com> writes:

> 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

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

#9943

On Tue, Jul 19, 2011 at 8:12 PM, sturlamolden <sturlamolden@yahoo.no> 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.

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.

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

#9954

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.

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

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

#9962

Thomas Jollans <t@jollybox.de> writes:

> 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

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

#9965

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

> 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

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

#9968

sturlamolden wrote:
> On 20 Jul, 11:59, Thomas Jollans <t...@jollybox.de> wrote:

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

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

	Mel.

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

#9970

On 20 Jul, 16:17, Mel <mwil...@the-wire.com> wrote:

> 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

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

#9973

On Jul 20, 9:27 am, sturlamolden <sturlamol...@yahoo.no> wrote:
> On 20 Jul, 16:17, Mel <mwil...@the-wire.com> wrote:
>
> > 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.

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

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

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

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

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

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

    def cb_cancelbutton(self)
        # destroy the dialog.

This is a proper design pattern for all GUI dialogs.

*school-bell*

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

#9974

On 20/07/11 15:47, sturlamolden wrote:
> 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.

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

#9977

On 20 Jul, 17:21, Thomas Jollans <t...@jollybox.de> wrote:

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

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

#9966

On 2011-07-20, Thomas Jollans <t@jollybox.de> wrote:

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

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

#9969

On 20 Jul, 11:59, Thomas Jollans <t...@jollybox.de> wrote:

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

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

#9958

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.

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.

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

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

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

csiph-web