On 12/30/10 10:24 AM, rantingrick wrote:
On Dec 30, 8:59 am, Kevin Walzer<k...@codebykevin.com> wrote:
On 12/29/10 6:58 PM, rantingrick wrote:
Any GUI framework is going to require at least some heavy lifting in C,
C++ or Objective-C (depending on the platform). A pure-Python approach
to GUI development is technically infeasible.
This is a very good point Kevin however i would much rather spend time
learning a language like C --which is hugely useful in many
contexts!-- than to waste one second of my time on a domain specific
language like TCl which is created only for drawing GUIs using Tk. I
think everyone can agree that learning C is of benefit far more
benefit to anyone in the programming field. Also one could argue that
C and Python are very similar. However Python and Tcl are like night
and day.
Tcl is not a domain-specific language for creating GUI's. Tcl is a
full-featured, general-purpose programming language that is a peer to
Python in its capabilities, and surpasses Python in some respects.
This monkey on our back (TclTk) is dead weight. We need to free
ourselves of this GUI prison and bring Python into the 21st century.
Tk is old and ugly. Tk is slow. Tk is incomplete and it will never be
complete or extensible within our community.
In 2010, Tk only lacks two major features common to GUI toolkits:
1. A cross-platform printing API. This is mainly an issue on Windows,
which lacks a rich command-line printing framework. The canvas widget
can generate PostScript, and the text widget can export its contents to
a text file, and then "lpr" can handle the rest on Unix systems
(including the Mac). Still, if you want native dialogs and full
integration with a platform-specific printing API, you will have to
utilize one of several, incompatible, platform-specific extensions.
2. A robust widget for HTML display. The old TkHTML widget (authored by
D. Richard Hipp, the author of SQLite) works, but it's very dated (last
updated in 2002) and lacks modern features like CSS support. An effort
to produce a next-generation HTML widget, TkHTML 3, yielded an
alpha-quality widget that is enormously complex, somewhat buggy, and
little used.
These days, Tkinter has pretty much everything that other GUI toolkits
have: tree views, multi-column listboxes, plus all the basics, available
through the core widget, the themed ttk widgets, or extension packages.
Today, there's no excuse for developing an ugly Tk GUI--if a new Tk app
is ugly, that's a reflection on the developer, not the toolkit.
There is no OpenGL canvas readily available. Sure you can use Togl (as
i have successfully!) however Togl is old and unmaintained. Any GUI
library in this day and age must support opengl out of the box!
Togl is still developed. One of its maintainers, Greg Couch, is a
developer on the UCSF Chimera project (a Python-Tkinter based molecule
viewer).
Look, losing Tkinter will be very painful for me as i have tons of
code written already. However the more i learn about Tkinter the more
i realize how Tkinter is a dead end street. Why let a rotting dinosaur
stagnate in the stdlib? Anybody that has foresight knows Tkinter is
dying and cannot be revived. It is time to move on. Tkinter served us
well for a time but we must let go and evolve -- lest we wither and
die ourselves!
I have nothing against other toolkits, and if one happens to catch on,
fine. But your assertions that Tkinter/Tk is dying have no basis in
fact. I'm an active developer in Tk with both Tcl and Python, and the
reason I have stayed with the toolkit is precisely because it isn't
dying. Check out the screenshots at my website--all those GUI's are
developed in Tk. Here's one in Tkinter/Python:
http://www.codebykevin.com/phynchronicity-running.png
--Kevin
--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
--
http://mail.python.org/mailman/listinfo/python-list
