GUIs - A Modest Proposal

[Cameron Laird]

.
[much wisdom, particularly
in regard to Tkinter]
.
.

The very diversity of GUI toolkits came into effect because Python is
very easy to extend and integrate with other C/C++ libraries. Writing a
GUI toolkit from scratch is much, much harder. Even a simple toolkit
like Tk has twenty years of developer-hours behind it. Do you really
think the Python community will be able to a) agree on the design of a
new toolkit to replace Tkinter and b) implement the code in a timely
fashion across multiple platforms? It sounds like an impossible goal to me.

.
.
.
Several people (other than Kevin) have written about Tkinter's
"non-standard"/unsatisfying/... appearance. Those who last
looked at it several years ago will probably do well to fire up
an instance and view the Tile widgets it now offers. While I
don't know nearly enough to guarantee that they'll please
everyone, they're at least different from the Tkinter of 2005,
and at least some of the differences are in directions mentioned
in this thread.

 

[Matt]

PyQt is tied to one platform.

Several posters have asked for support for or clarification of this
claim of yours.

On its face it seems to be nonsense.

So just what are you talking about?

 

[Grant Edwards]

Several posters have asked for support for or clarification of this
claim of yours.

Let me guess...

The one platform it's tied to is Qt?

 

[Jeff Hobbs]

If you are referring tohttp://search.cpan.org/~srezic/Tk-804.028/-
this also has a full Tcl interpreter, in pTk/mTk, and uses Tcl_Interp
and Tcl_Obj throughout. From the Perl/Tk FAQ (*):

"However, from a Perl perspective, Perl/Tk does not require any
familiarity with Tcl, nor does its installation depend on any Tcl code
apart from that packaged within Perl/Tk."

They also explain

"The pTk code proper is an externally callable Tk toolkit (i.e. a
re-write of the Tk 8.0 code that allows easier external linking &
calling, especially by perl)."

I couldn't quite understand what they mean by that: the sources for
tcl/generic (for example) look fairly unmodified.

Perl/Tk, as referenced above, does indeed replace the Tcl interpreter
with a bolt-on replacement using Perl internals. While this was
workable, it was brittle and harder to maintain.

Tkx (http://search.cpan.org/dist/Tkx/), a replacement Tk binding for
Perl, authored by myself (core Tcl member, with knowledge of Perl
internals as well) and others at ActiveState, reintroduced the Tcl
binding in a very flexible way. It's actually the Tcl module (http://
search.cpan.org/dist/Tcl/) that has all the magic. Tk is loaded
dynamically from that - Perl has no direct linkage to it.

Tkx proved to be faster, more flexible and more extensible than the
original Perl/Tk. The interface also took advantage of Tcl's stubs
mechanism to provide a level of binary version independence (Perl's
Tcl module can load any Tcl 8.4, 8.5 or 8.6 patchlevel without
recompilation, with 100% functionality).

If you look to revamp things, don't go down the path of trying to
remove Tcl to get to Tk. Instead reconsider the approach to Tcl. A
little bending might prove a much better match in the long term.

Jeff

 

[Jeff Hobbs]

Hello Mark,

Are you maintaining Tkinter or Tix or both? There is a nagging issue
with Tix that needs fixing. Upon subbclassing some widgets and when
using the import Tix and import Tix as *. Maybe it is already fixed in
3.0 (i have not checked) but we need to fix it.

I am still currently rewriting Tkinter Tix and IDLE in my spare time
but got a bit busy lately. Anyhoo, i would really like to bring some
patches, upgrades, and just a general spit shining to the entire three-
plexx so let me know.

I am not a Tkinter maintainer, but I am one of the core Tk and Tix
maintainers (having also completely revamped Tix a couple of years ago
for better long-term stability and compatibility). If you have fixes
that are relevant there, I can integrate them. I should note that
much of Tix has been subsumed or replaced by better equivalents in the
core of Tk. That said, it assumes you know and are using Tk 8.5.
I've seen a lot of FUD on Tk in this thread, and much of it is a
decade old perspective. Tk 8.5 does have native themed widgets (using
Win32, Carbon or Cocoa, and X11, though also with plugins to gtk and
qt). I'd have to explore more into Tkinter to see where anybody
derives value from Tix in current programs.

In any case, the basic mantra for Tix is new development should avoid
it, but existing development should work fine. New development should
leverage the good work of Guilherme Polo in making the Tk 8.5 core
themed widgets available in Tkinter.

Jeff

 

[Ethan Furman]

I am not a Tkinter maintainer, but I am one of the core Tk and Tix
maintainers (having also completely revamped Tix a couple of years ago
for better long-term stability and compatibility). If you have fixes
that are relevant there, I can integrate them. I should note that
much of Tix has been subsumed or replaced by better equivalents in the
core of Tk. That said, it assumes you know and are using Tk 8.5.
I've seen a lot of FUD on Tk in this thread, and much of it is a
decade old perspective. Tk 8.5 does have native themed widgets (using
Win32, Carbon or Cocoa, and X11, though also with plugins to gtk and
qt). I'd have to explore more into Tkinter to see where anybody
derives value from Tix in current programs.

In any case, the basic mantra for Tix is new development should avoid
it, but existing development should work fine. New development should
leverage the good work of Guilherme Polo in making the Tk 8.5 core
themed widgets available in Tkinter.

Jeff

Thanks for the info, Jeff!

Is there a good web-site / tutorial / book / etc that you would
recommend for getting a good handle on Tk 8.5?

~Ethan~

 

[Jeff Hobbs]

Thanks for the info, Jeff!

Is there a good web-site / tutorial / book / etc that you would
recommend for getting a good handle on Tk 8.5?

Most of the Tk 8.5 references will be Tcl-based, but one that is cross-
language is Mark Roseman's www.tkdocs.com.

For books, there is John Ousterhout's main book, now in the 2nd
edition, updated with Tcl/Tk 8.5 references:
http://www.amazon.com/Tcl-Toolkit-2nd-John-Ousterhout/dp/032133633X

To understand just the changes in Tk 8.5, you can see the wiki page
that lists references for all changes:
http://wiki.tcl.tk/10630

It includes 16 new widgets (many themed versions of classic widgets,
but key new ones like the combobox and notebook), new canvas and text
features, and more. The wiki in general has lots of how-to reference
info (over 20K pages of content).

The key with Tk that I've seen misunderstood in this thread is that it
has lots of extensions. Those in the core community do argue about
whether "important" widgets should be full core or kept as widgets
(where they get their own dev cycle). There are some fantastic Tk
widgets out there, like tktreectrl (http://
tktreectrl.sourceforge.net/), tktable, many in tklib (e.g. tablelist
http://www.nemethi.de/tablelist/tablelist.html), and more. They can
be used with any of the languages that integrate with Tk, but may not
have "built-in" support (IOW, you might need some language-specific
shim). Overcoming these hurdles may help reduce the pain and glum
feelings people have towards Tk bound to non-Tcl languages (and is
indeed one of the points addressed by Tkx). It doesn't help with doc
translation (for use with other languages), so that's yet another
hurdle. :-/

Jeff

 

[Kevin Walzer]

Most of the Tk 8.5 references will be Tcl-based, but one that is cross-
language is Mark Roseman's www.tkdocs.com.

For books, there is John Ousterhout's main book, now in the 2nd
edition, updated with Tcl/Tk 8.5 references:
http://www.amazon.com/Tcl-Toolkit-2nd-John-Ousterhout/dp/032133633X

To understand just the changes in Tk 8.5, you can see the wiki page
that lists references for all changes:
http://wiki.tcl.tk/10630

It includes 16 new widgets (many themed versions of classic widgets,
but key new ones like the combobox and notebook), new canvas and text
features, and more. The wiki in general has lots of how-to reference
info (over 20K pages of content).

The key with Tk that I've seen misunderstood in this thread is that it
has lots of extensions. Those in the core community do argue about
whether "important" widgets should be full core or kept as widgets
(where they get their own dev cycle). There are some fantastic Tk
widgets out there, like tktreectrl (http://
tktreectrl.sourceforge.net/), tktable, many in tklib (e.g. tablelist
http://www.nemethi.de/tablelist/tablelist.html), and more. They can
be used with any of the languages that integrate with Tk, but may not
have "built-in" support (IOW, you might need some language-specific
shim). Overcoming these hurdles may help reduce the pain and glum
feelings people have towards Tk bound to non-Tcl languages (and is
indeed one of the points addressed by Tkx). It doesn't help with doc
translation (for use with other languages), so that's yet another
hurdle. :-/

Jeff

To see the new ttk widgets at work in Tkinter, look at the next
generation of the venerable app PySol, PySolFC, at
http://pysolfc.sourceforge.net. Here are screenshots of (I think) the
Windows versions:

http://pysolfc.sourceforge.net/screenshots.html

And the Mac version:

http://mac.softpedia.com/progScreenshots/PySolFC-Screenshot-24708.html

Here's a screenshot from one of my own Tkinter applications that makes
use of ttk widgets and also such Tk extension packages as BWidgets (the
treeview) and tablelist (the table view):

http://www.codebykevin.com/phynchronicity-running.png

--Kevin

 

[est]

Having said all that, I would like to eliminate some of the
depedencie. At some point I'll probably re-do the Windows
implementation using ctypes, because pywin32/mfc is hindering
more than helping in some areas. I'm also thinking about ways
to interface directly with Cocoa without going through pyobjc.
But all that is some way off in the future after I get the API
nailed down more.

that would be awesome!

 

[Matt]

Let me guess...

The one platform it's tied to is Qt?

good answer

 

[g4b]

On the subject of the gui discussion mentioned here last year, which you get lead to if you read around in the pyjamas docs, I have to admit, since I know both development types (gwt, wx, qt) and (django, jquery), I have to state the fact, that pyjamas should also consider bonding with native javascript library developments.

Excuse me if I accidentaly go a bit off track, but I guessed, I might bringin my thoughts (but I hope, not to get emotional responses which made thisthread a bit hard to follow in the end)

The interchange between fixed sized GUI applications and browsing technology as a whole could for example get very interesting for django development,if javascript operated functions would be taken over by native python.

I was just looking at pyquery, a python implementation of jquery, which could easily backbone jquery itself on the python end.

Now this is not pyjamas' task, but the pyjs compiler could be used, so thatjquery code could be written for both languages. Since jquery DOM interfacing is way easier, and hot fixes can be made by javascript development teams, GUI elements of jquery libraries could be integrated into the application.

While the functionality of the UI therefore still is GUI based in terms of fixed applications, like pyjamas desktop, concurrent efforts could take place from the so called "web-development" gui layouts. On that front, a lot of talented coders exist in younger generations, which would have the ability to develop the web frontend in closer relation to the web-designers, mainting the key issues for the world-wide-web: design, speed and small loadingtime.

Long story short: if you could write jquery in python which actually compiles into jquery in javascript, and even runs on python itself, you could deploy widgets natively from python in django, and dont have to leave python to improve webapplications with its native strengths.

You can free yourself up pretty soon from having too much problems with ui.the designer can do that. You focus on datasets, server-client-api, or youcan expose one of your pyjamas widgets as jquery plugin integrating validation of data server and clientside.

You can still develop a control application or other integrated software parts natively with pyjamas desktop, knowing the web uses correct code.

Of course that depends on how much overhead pyjamas libraries have if you only take a piece of it out, like a richtext element or a fully bloated editor, but even then, internally you load the app anyway up front, externally the user transitions from being a human guest to being a system user only in certain occasions.

Any thoughts?