Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Tkinter: The good, the bad, and the ugly!

Reply
Thread Tools

Tkinter: The good, the bad, and the ugly!

 
 
Michael Torrie
Guest
Posts: n/a
 
      01-22-2011
On 01/20/2011 11:17 AM, Emile van Sebille wrote:
> The problem with QT is the license.


PyQT indeed is licensed poorly for anything that's not GPL. But Qt
itself is dual-licensed under GPL and the LGPL, as of version 4.6 I
think. The LGPL license would seem to be quite acceptable even for
commercial, closed-source programs. Is this not so? The license is at
parity with GTK+.

Eventually PySide will be stable and fast, and so the licensing issues
involving PyQt won't matter.
 
Reply With Quote
 
 
 
 
Gregory Ewing
Guest
Posts: n/a
 
      02-25-2011
[Sorry to revive an old thread, but I was away when it occurred
and I'd like to make a comment...]

Kevin Walzer wrote:

> This library isn't much different from other Python GUI toolkits--it's
> dependent on underlying, rather large, platform-specific
> implementations--but it provides an even higher level of abstraction. On
> the Mac, it is dependent on PyObjC; on Windows, pywin32; and on X11,
> pygtk. In short, it's a wrapper over other wrappers.


PyGUI differs from the likes of wxPython and PyQT in that the
things it depends on are mainly just Python bindings for native
facilities already present on the platform.

This is an issue because of the number of API translations
involved. WxWidgets and Qt are themselves cross-platform libraries
that present quite a different API from the platform. The Python
bindings for them just expose that API to Python, resulting in
something that is not very Pythonic. To fix that, you would need
another layer on top, resulting in *two* API translations.

Each time such a translation occurs, something gets lost. PyGUI
is designed to minimise the loss by building a Pythonic API
directly on the platform API.

To me, this is the most important thing. Minimising the size of
third-party dependencies is also a goal, but it's secondary, and
can be addressed in various ways later, such as by using ctypes
or custom extension modules. Getting the API right, and proving
that it can be implemented with acceptable quality on all the
target platforms, are the first priorities.

--
Greg
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
if and and vs if and,and titi VHDL 4 03-11-2007 05:23 AM



Advertisments