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

[rantingrick]

Tkinter: The good, the bad, and the ugly!
-----------------------------------------
An expose by rantingrick


----------------------
The Good
----------------------
Back in the early days of Python --when this simplistic beauty of
programming bliss we enjoy today was just a tiny glimmer of hope in a
archaic world plagued by dark forest of braces and jagged caverns of
cryptic syntaxes-- our beloved dictator (Mr. Van Rossum) had the
foresight to include a simplistic GUI toolkit that we call Tkinter
into the stdlib. And he saw that it was great, and that it was good,
and so he rested.

And when the first python programmers used this gift handed down from
the gods they were pleased. They could see that all of the heavy work
of cross-platform-ism landed square on the shoulders of TCL/Tk and all
Python had to do was wrap a few methods to wield the beast we all know
as graphical user interfaces.

Life was good, people were happy...but darkness loomed on the
horizon...


----------------
Enter the Bad
----------------
However as we all know there exists no real Utopian bliss without many
pitfalls and snares. Since Tkinter is just a wrapping of some TclTk
calls the people realized that they are now at the perilous mercy of
another group of developers (psst: thats the TCL folks!) who have only
their own goals and dreams in mind and could care less for the
troubles of others. They realized that Tkinter was lacking. However
this lacking was not Tkinters fault, no, the fault lye with TclTk. And
to compound these problems they also realized that in order to fix the
design problems inherit in TclTk they must learn an obscure and mostly
useless language... TclTk!!

--------------------------------
Utterly destroyed by the Ugly!
--------------------------------
And then the people became very angry... "What a double cross!" they
chanted. Why should we learn a language like TclTk just to fix
problems that the TclTk folks need to fix themselves? Would not that
time be more wisely spent in looking over code that is 100% Python and
modifying it? Not only would our community benefit but we can
propagate the maintainece and/or improvements to a wider group of
folks by removing the high entrance requirements. When we elevate
every python programmer to a PythonGUI maintainer then we will have
achieved community nirvana!

We have now reached a point where the very simplicity we have embraced
(Tkinter) has become a stumbling block not only for the users of
Tkinter, but more devastating is the damage this TCL/Tk monkey has
done to keep our fellow Python brothers and sisters from learning how
a GUI kit works (behind the scenes) with each OS to bring all this
graphical stuff to life.

------------------------
So what should we do?
------------------------
The answer is simple. We need a 100% Python GUI. A GUI coded in Python
from top to bottom. A GUI that is cross platform to the big three
(Windows, Linux, and Mac). A GUI that not only is easy as Tkinter but
also a GUI that can be manipulated by the average python programmer. A
GUI that not only teaches the fundamentals of using a GUI, but also a
GUI that teaches how a GUI works under the hood

Then and only then will Python be truly what GvR intended. I want
everyone here to consider what i am proposing and offer some opinions
because it is time for change.

[Katie T]

On Wed, Dec 29, 2010 at 11:58 PM, rantingrick <rantingrick at gmail.com> wrote:
>
> Then and only then will Python be truly what GvR intended. I want
> everyone here to consider what i am proposing and offer some opinions
> because it is time for change.

What's your opinion of the other gui toolkits with Python bindings
like PyQt and PyGtk?

Katie
--
CoderStack
http://www.coderstack.co.uk/perl-jobs
The Software Developer Job Board

[Octavian Rasnita]

From: "Katie T" <katie at coderstack.co.uk>
> What's your opinion of the other gui toolkits with Python bindings
> like PyQt and PyGtk?
>
> Katie
> --


They are not accessible at all for screen readers, so the programs that still use them won't be accessible to all potential users.

Octavian

[rantingrick]

On Dec 29, 6:07?pm, Katie T <ka... at coderstack.co.uk> wrote:
> On Wed, Dec 29, 2010 at 11:58 PM, rantingrick <rantingr... at gmail.com> wrote:
>
> What's your opinion of the other gui toolkits with Python bindings
> like PyQt and PyGtk?

Hello KateT,

Well i like wxPython as it is quite well rounded but we all know it
has some shortcomings too and wx is far too bloated for the stdlib!
pyQt and pyGtk i cannot comment on because i have no experience with
them.

However i need to stress that my intention is towards a 100% Python
GUI. Not a binding, not a wrapping (except for OS calls!) but a *real*
Python GUI. The only thing that i know of at this point is pyGUI
although there are probably others. Allowing the average Python
programmer the ability to read OS specific calls written in Python
would not only benefit their GUI knowledge, but also there knowledge
of OS's in general.

I guess you could sum it as "Getting the most bang for your community
buck".

[Gerry Reno]

wxPython looks good but I don't see anyone developing support for things
like smartphones.

Also, what do you think about frameworks such as pyjamas? It lets you
write in python and compiles everything down to Javascript so it can be
used across the Web as well as on the desktop.

[rantingrick]

On Dec 29, 6:41?pm, Gerry Reno <gr... at verizon.net> wrote:
> wxPython looks good but I don't see anyone developing support for things
> like smartphones.

No wx is not the answer to our problems

> Also, what do you think about frameworks such as pyjamas? ?It lets you
> write in python and compiles everything down to Javascript so it can be
> used across the Web as well as on the desktop.

Hmm, this is like two double edged swords smashing one another in
battle.

Sword One: On one hand web frameworks are going to be really big soon
-- however legacy GUI's are not going away any time soon!

Sword Two: On the other hand web frameworks provide awesome cross
platform ability that is surly only going to get better as time goes
-- however i utterly hate JavaScript (although much worse web
languages exist!). And sending requests back and forth between Python,
JavaScript, and BrowserX is also a real PITA. Because even though
everyone knows this is coming all the major browsers are trying to
insert their API into the mix. So that Joe Scripter has to write code
that is compatible between many browsers. Until the world agrees on a
unified API --AND IMPLEMENTS IT SERIOUSLY-- we are at the mercy of
drunken sailors at the helm.

I believe pyjamas has a bright future in the web playground, however
we still need to focus our community efforts towards a Python based
GUI. I can see a pythonGUI and pyjamas existing side by side in mutual
harmony for many years.

[Stef Mientki]

On 30-12-2010 02:03, rantingrick wrote:
> On Dec 29, 6:41 pm, Gerry Reno <gr... at verizon.net> wrote:
>> wxPython looks good but I don't see anyone developing support for things
>> like smartphones.
> No wx is not the answer to our problems
Just partial ;-)

Why not write a (Pythonic) wrapper and choose what will be under neat it ?

My personal situation at this moment:

* for desktop applications we basically use wxPython
* the use of sizers in wxPython is not easy and full of cross-pointers with useless names.
Therefor we already used a wrapper for wxPython.
* for components missing in wxPython, we embed PySide-QT and Delphi components in wxPython
* for server-side web applications we use web2py
* for client-side web applications we use PyJamas
* for mobile devices we use PocketPyGUI
* as PySide-QT is making a huge progress at the moment and has improved licenses, (and might be
usable for mobile devices) we might want to move gradually from wxPython to PySide-QT

Right at this moment, I'm writing a new wrapper, that already can handle (in a simple way) wxPython
and PySide-QT(partial).
After this works fully, PyJamas and Web2pY will be added (PockectPyGui can probably fully be
replaced by QT)

cheers,
Stef


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20101230/f7811700/attachment.html>

[Arndt Roger Schneider]

rantingrick schrieb:
> On Dec 29, 6:41 pm, Gerry Reno <gr... at verizon.net> wrote:
>
>>wxPython looks good but I don't see anyone developing support for things
>>like smartphones.
>
>
> No wx is not the answer to our problems
>

Rather: ... to *your* problem...

>
>>Also, what do you think about frameworks such as pyjamas? It lets you
>>write in python and compiles everything down to Javascript so it can be
>>used across the Web as well as on the desktop.
>
>
> Hmm, this is like two double edged swords smashing one another in
> battle.
>
> Sword One: On one hand web frameworks are going to be really big soon
> -- however legacy GUI's are not going away any time soon!

There are enough out there in the wild,
they will last quite for awhile indeed;
but it's time for them to die.

>
> Sword Two: On the other hand web frameworks provide awesome cross
> platform ability that is surly only going to get better as time goes
> -- however i utterly hate JavaScript (although much worse web
> languages exist!). And sending requests back and forth between Python,
> JavaScript,

Apparently the authors do know that, too:
MessageID:<mailman.1298.1290672551.2218.python-list at python.org>,
*sigh* no svg.

BTW: Look in comp.lang.javascript:
javascript is framework/toolkit resistent.

and BrowserX is also a real PITA. Because even though
> everyone knows this is coming all the major browsers are trying to
> insert their API into the mix. So that Joe Scripter has to write code
> that is compatible between many browsers. Until the world agrees on a
> unified API --AND IMPLEMENTS IT SERIOUSLY-- we are at the mercy of
> drunken sailors at the helm.

svg: opera, chrome, safari(including ios), ie9, firefox.
Although svg is missing under webkit/android
--Apple kept the hardware accelerated part to themeselves.
Goolge is currently implementing hardware acceleration for svg in
chrome/webkit, likewise Microsoft/ie.
Lets wait and see when svg becomes available in android, too.

Although smil is quiet another subject.

>
> I believe pyjamas has a bright future in the web playground, however
> we still need to focus our community efforts towards a Python based
> GUI. I can see a pythonGUI and pyjamas existing side by side in mutual
> harmony for many years.
>

pyjamas: Perhaps without javascript.

-roger

[geremy condra]

On Wed, Dec 29, 2010 at 5:03 PM, rantingrick <rantingrick at gmail.com> wrote:
> On Dec 29, 6:41?pm, Gerry Reno <gr... at verizon.net> wrote:

>> Also, what do you think about frameworks such as pyjamas? ?It lets you
>> write in python and compiles everything down to Javascript so it can be
>> used across the Web as well as on the desktop.
>
> Hmm, this is like two double edged swords smashing one another in
> battle.

Seriously, get off of WoW and go write some code. If you'd spent the
last year programming instead of doing your best Xah Lee impression
you might have actually made some progress on this.

Geremy Condra

[Zeissmann]

> Seriously, get off of WoW and go write some code. If you'd spent the
> last year programming instead of doing your best Xah Lee impression you
> might have actually made some progress on this.

I'm curious, is Xah Lee some sort of a Usenet meme? Cause this is not the
first time I see his name in the context of a lightweight invective.

[Mel]

Zeissmann wrote:

>> Seriously, get off of WoW and go write some code. If you'd spent the
>> last year programming instead of doing your best Xah Lee impression you
>> might have actually made some progress on this.
>
> I'm curious, is Xah Lee some sort of a Usenet meme? Cause this is not the
> first time I see his name in the context of a lightweight invective.

AFAIK he's just a guy who thinks Usenet is his blog, and kicks off big
rambling threads, cross-posted to infinity that mathematically have
probability 0.0 of being on topic in any of the groups they're in.

Mel.

[rantingrick]

On Jan 14, 3:37?pm, geremy condra <debat... at gmail.com> wrote:
> If you'd spent the
> last year programming instead of doing your best Xah Lee impression
> you might have actually made some progress on this.

Well Geremy the very first step a wise developer employs is to get an
idea of what the masses want and what they don't want. Nobody wants to
waste a second (much less a whole year) developing a wxPython stdlib
module when the powers that be won't even *entertain* the idea of a
wxPython stdlib module. Most every Python programmer (noob to pro)
understands that while Tkinter is a great starter GUI module
eventually you hit the glass ceiling. However for some strange and
quite ridiculous reason they insist on keeping Tkinter alive forever.
I am at a loss here.

Interviewer: So how do you feel about Tkinter?
Python Community: Well Tkinter sucks what more can i say?

Interviewer: Ok so maybe we should replace Tkinter with something
better then?
Python Community: What? Are you stupid? No it sucks but we will keep
it! And that is that! I have spoken!

Interviewer: So let me get this strait fella... You hate Tkinter, and
most of your constituents won't even bother to use it because they
hate it also *however* you just want to let it rot in the stdlib like
some aging hero of boredom and booze?
Python Community: Pretty much. Yea.

Interviewer: Sounds like a Masochistic psychosis to me.
Python Community: ad hominem!, ad hominem!

[Terry Reedy]

On 1/15/2011 11:17 PM, rantingrick wrote:

> Well Geremy the very first step a wise developer employs is to get an
> idea of what the masses want and what they don't want.

'The masses' have so far been divided on what alternative they might
want. In any case, open source developers are typically scratching their
own itches, which may are may not be influenced by 'the masses'.

> Nobody wants to waste a second (much less a whole year)
> developing a wxPython stdlib
> module when the powers that be won't even *entertain* the idea of a
> wxPython stdlib module.

As far as I know, no one has ever seriously proposed any replacement for
tkinter in at least the last ten years. There has been nothing to
entertain, review, or discuss, let alone approve or reject. (And if you
propose to the PSF that developer X contribute his code, the answer will
be to talk to developer X instead.) 'gui' does not appear in any PEP
title (except as part of 'guide' or 'guideline'.

--
Terry Jan Reedy

[Katie T]

On Thu, Dec 30, 2010 at 12:15 AM, rantingrick <rantingrick at gmail.com> wrote:
>
> However i need to stress that my intention is towards a 100% Python
> GUI. Not a binding, not a wrapping (except for OS calls!) but a *real*
> Python GUI. The only thing that i know of at this point is pyGUI
> although there are probably others. Allowing the average Python
> programmer the ability to read OS specific calls written in Python
> would not only benefit their GUI knowledge, but also there knowledge
> of OS's in general.

It's very hard to write a good gui framework, very very few people
have managed to do it well. Microsoft, Sun and Google have all had the
resources to hire very good developers and designers to dedicate to
the task and still haven't managed to do it well.

There's not the expertise or the investment in the Python community to
build a strong Python GUI solution. From an educational viewpoint I
see that there could be value in having a pure Python solution, but in
terms of having a GUI solution that people will actually want to use
in their apps, I'm dubious that it's achievable.

Katie
--
CoderStack
http://www.coderstack.co.uk/perl-jobs
The Software Developer Job Board

[rantingrick]

On Dec 30, 7:54?pm, Katie T <ka... at coderstack.co.uk> wrote:

> It's very hard to write a good gui framework, very very few people
> have managed to do it well.

This is a very good point Katie. Creating a Python GUI is a huge
undertaking and it will take much time to work out the bugs. A truly
Pythonic GUI may be (i must admit) a pipe dream at this time. However
i know that unless we start thinking about something new right now, it
will be two, three, ten years down the road and we will be in the same
situation.

A lot of folks are probably thinking that since Python3000 is here
that Python is up to current technology but i must differ with that
opinion. Yes Python3 is much better than the 2.x line however Tkinter
and IDLE are so dated and antique that Py3000 is a bit lackluster.

Look, when Guido breathed life into Tkinter many years ago he did so
with good intentions. I believe at that time (and for a while after)
Tkinter was an asset to this community. However, now Tkinter just
looks old and dumpy.

Actually i would't mind keeping Tkinter and just tweaking it a bit but
that is impossible! There will always be a glass ceiling between us
and Tcl. We are confined from the Tcl folks and there is nothing we
can do about. Tkinter has had a decade to become more relevant in the
21st century however the Tcl folks have failed to deliver. We cannot
keep depending on outsiders, we must start the transition to something
better.


> There's not the expertise or the investment in the Python community to
> build a strong Python GUI solution. From an educational viewpoint I
> see that there could be value in having a pure Python solution, but in
> terms of having a GUI solution that people will actually want to use
> in their apps, I'm dubious that it's achievable.


Also a good point Katie. But i think i have just a little more
optimism than you :).

I will conceded that if we cannot build a truly Pythonic GUI then we
must at least pick a GUI that is up to date with Python3000. A good
choice might be a limited version of wxPython in the stdlib and a 3rd
party extension module available for download. We can use Tkinter as
the template. All you need in the stdlib are the same widgets that are
in Tkinter now. However unlike Tkinter, now a rich 3rd party module
will be available. By doing this we will have removed the glass
ceiling, and we did not have to re-invent the wheel to do it.

What is your opinion (or anyone) on wxPython?

[Robert]

On 2010-12-30 22:06:57 -0500, rantingrick said:
>
>
> What is your opinion (or anyone) on wxPython?

Ok, I am curious again. Have you even tried wxPython or PySide/PyQt?

--
Robert

[rantingrick]

On Dec 30, 9:51?pm, Robert <sigz... at gmail.com> wrote:
> Ok, I am curious again. Have you even tried wxPython or PySide/PyQt?

Yes i have used wxPython on a few projects and was very happy with the
feature rich nature of it. I found previously (with Tkinter) i would
have to build my own compound widgets due to non-existence or just
plain poor design. That was not the case in wx as it has more eye
candy than i could ever put to good use ;)

[python]

Rick,

> However, now Tkinter just looks old and dumpy.

Have you taken a look at the ttk module (based on tile) that ships with
Python 2.7/3.1? This adds native/theme-aware widgets to Tkinter. And it
adds additional widgets such as a treeview (which can also be used as a
grid), notebook, progressbar, scales, panedwindow (splitters), etc.

The widgets in ttk match each platform's standards and look as
professional as the equivalents found in wxPython/pyQt. Take a look at
the screenshots on this rather long page to get an idea of what is now
possible - "out-of-box" with Python 2.7/3.1.
http://www.tkdocs.com/tutorial/onepage.html

I've done GUI development in wxPython and pyQt, and until recently
*never* considered Tkinter. Once I saw what was possible with the ttk
module, I've started moving a lot of new GUI projects from these other
platforms back to Tkinter/ttk (enhanced with PIL module).

Why Tkinter/ttk vs. wxPython or pyQt
- professional looking apps are now possible (really!)
- very light weight install and distribution
- works with both 2.x/3.x (not possible with wx)
- very robust (wx can be finicky at times)

Subjective: I also prefer Tk's geometry managers to wx's sizers even
though I learned sizers first.

You seem to be very enamored with wxPython. What have you found in
wxPython that's not available with the latest versions of Tkinter/ttk
other than an AUI equivalent and better support for RTL languages?

Malcolm

[Alexander Kapps]

On 30.12.2010 00:58, rantingrick preached:
>
> Tkinter: The good, the bad, and the ugly!
> -----------------------------------------
> An expose by rantingrick

You are seriously starting to sound like Xah Lee.


> our beloved dictator (Mr. Van Rossum) had the foresight to include a simplistic GUI toolkit that we call Tkinter
> into the stdlib. And he saw that it was great, and that it was good, and so he rested.

For a technocrat (and that's an insult, in my book), you have a
really annoying bible-style type of speech (or do you just play too
much WoW?).

Would you please stop to consider your own, what 4 or 5, years of
programming experience to be enough to judge on such reasons?

Some thought-food for you: What other GUI toolkit even just *could*
had been included by Pan, Jesus, Mohammed, Budda, or God herself?
(it's *your* wording that makes me include such names)


> The answer is simple. We need a 100% Python GUI.

How many times did you say that now? Have you done anything to
archive that goal? Have you even tried to support existing projects?
I'm going to bet my right arm, that you haven't.

> Then and only then will Python be truly what GvR intended.

I must admit, you keep true with yourself and even advance on that.
Now you not only claim to speech for the whole Python community, but
for Guide himself.

Sorry, but how megalomaniac are you?

[Octavian Rasnita]

From: "rantingrick" <rantingrick at gmail.com>
> Back in the early days of Python --when this simplistic beauty of
> programming bliss we enjoy today was just a tiny glimmer of hope in a
> archaic world plagued by dark forest of braces and jagged caverns of
> cryptic syntaxes-- our beloved dictator (Mr. Van Rossum) had the
> foresight to include a simplistic GUI toolkit that we call Tkinter
> into the stdlib. And he saw that it was great, and that it was good,
> and so he rested.


Yes, for that time it was good.

> Life was good, people were happy...but darkness loomed on the
> horizon...

Not all the people were happy because the darkness disappeared partially for some of them and more and more blind people started to use a computer, and discovered that the Tk interfaces are absolutely inaccessible for them.

> The answer is simple. We need a 100% Python GUI. A GUI coded in Python
> from top to bottom. A GUI that is cross platform to the big three
> (Windows, Linux, and Mac). A GUI that not only is easy as Tkinter but
> also a GUI that can be manipulated by the average python programmer. A
> GUI that not only teaches the fundamentals of using a GUI, but also a
> GUI that teaches how a GUI works under the hood


So it should be a kind of SWING library made in Python, right?
It is a good idea, but it should not have the problems of SWING and in that case it would be very hard to do.

First, the interface should look exactly as the native interfaces for each system named, and it should provide the same features, because otherwise the interface would look strange for all the users on all the operating systems.
And of course, it should not only look OK, but it should also follow the accessibility standards for beeing accessible for screen readers also.

WxPython is the best GUI because it is fast, even though it is bloated, it uses the native GUI elements on all those 3 operating systems and a relatively good accessibility for screen readers.

But WxPython still have problems because not all operating systems native GUIS offer the same widgets and features and those features custom-made don't respect the accessibility standards.

WxPython is fast because it is made in C - it uses the native GUI elements of the OS which are also made in C. Would a Python - only GUI have the same speed? If yes, it would be great.

Octavian

[python]

Octavian,

> Not all the people were happy because the darkness disappeared partially for some of them and more and more blind people started to use a computer, and discovered that the Tk interfaces are absolutely inaccessible for them.

Might this package help? (I have no experience with this project)

Tka11y 0.1.1 - accessibility-aware Tkinter
http://pypi.python.org/pypi/Tka11y

Another idea: Use Tkinters <Enter> events to speak TTS descriptions of
the current control and/or its contents?

I would love to hear from anyone using either of techniques ... or other
techniques or screen reader products ... to make their Tkinter
applications accessible to low vision/blind users.

Malcolm

[Octavian Rasnita]

From: <python at bdurham.com>
Subject: Tkinter accessability options (was Re: Tkinter: The good, the bad, and the ugly!)


> Octavian,
>
>> Not all the people were happy because the darkness disappeared partially for some of them and more and more blind people started to use a computer, and discovered that the Tk interfaces are absolutely inaccessible for them.
>
> Might this package help? (I have no experience with this project)
>
> Tka11y 0.1.1 - accessibility-aware Tkinter
> http://pypi.python.org/pypi/Tka11y
>
> Another idea: Use Tkinters <Enter> events to speak TTS descriptions of
> the current control and/or its contents?
>
> I would love to hear from anyone using either of techniques ... or other
> techniques or screen reader products ... to make their Tkinter
> applications accessible to low vision/blind users.
>
> Malcolm


Thank you very much for those projects! I will test them.

Unfortunately they are not a solution because if I want to create an accessible app I can do it using an accessible library, but if the other programmers of the world use a non-accessible by default GUI, than their programs won't be accessible, or they will offer a limited accessibility like Java Access Bridge offers to SWING-based apps.

If Tkinter would use that project that should offer the accessibility by default, that would be a real solution.

Octavian

[Almar Klein]

On 30 December 2010 00:58, rantingrick <rantingrick at gmail.com> wrote:

>
> Tkinter: The good, the bad, and the ugly!
> -----------------------------------------
> An expose by rantingrick
>
>
> ----------------------
> The Good
> ----------------------
> Back in the early days of Python --when this simplistic beauty of
> programming bliss we enjoy today was just a tiny glimmer of hope in a
> archaic world plagued by dark forest of braces and jagged caverns of
> cryptic syntaxes-- our beloved dictator (Mr. Van Rossum) had the
> foresight to include a simplistic GUI toolkit that we call Tkinter
> into the stdlib. And he saw that it was great, and that it was good,
> and so he rested.
>
> And when the first python programmers used this gift handed down from
> the gods they were pleased. They could see that all of the heavy work
> of cross-platform-ism landed square on the shoulders of TCL/Tk and all
> Python had to do was wrap a few methods to wield the beast we all know
> as graphical user interfaces.
>
> Life was good, people were happy...but darkness loomed on the
> horizon...
>
>
> ----------------
> Enter the Bad
> ----------------
> However as we all know there exists no real Utopian bliss without many
> pitfalls and snares. Since Tkinter is just a wrapping of some TclTk
> calls the people realized that they are now at the perilous mercy of
> another group of developers (psst: thats the TCL folks!) who have only
> their own goals and dreams in mind and could care less for the
> troubles of others. They realized that Tkinter was lacking. However
> this lacking was not Tkinters fault, no, the fault lye with TclTk. And
> to compound these problems they also realized that in order to fix the
> design problems inherit in TclTk they must learn an obscure and mostly
> useless language... TclTk!!
>
> --------------------------------
> Utterly destroyed by the Ugly!
> --------------------------------
> And then the people became very angry... "What a double cross!" they
> chanted. Why should we learn a language like TclTk just to fix
> problems that the TclTk folks need to fix themselves? Would not that
> time be more wisely spent in looking over code that is 100% Python and
> modifying it? Not only would our community benefit but we can
> propagate the maintainece and/or improvements to a wider group of
> folks by removing the high entrance requirements. When we elevate
> every python programmer to a PythonGUI maintainer then we will have
> achieved community nirvana!
>
> We have now reached a point where the very simplicity we have embraced
> (Tkinter) has become a stumbling block not only for the users of
> Tkinter, but more devastating is the damage this TCL/Tk monkey has
> done to keep our fellow Python brothers and sisters from learning how
> a GUI kit works (behind the scenes) with each OS to bring all this
> graphical stuff to life.
>
> ------------------------
> So what should we do?
> ------------------------
> The answer is simple. We need a 100% Python GUI. A GUI coded in Python
> from top to bottom. A GUI that is cross platform to the big three
> (Windows, Linux, and Mac). A GUI that not only is easy as Tkinter but
> also a GUI that can be manipulated by the average python programmer. A
> GUI that not only teaches the fundamentals of using a GUI, but also a
> GUI that teaches how a GUI works under the hood
>
> Then and only then will Python be truly what GvR intended. I want
> everyone here to consider what i am proposing and offer some opinions
> because it is time for change.
> --
> http://mail.python.org/mailman/listinfo/python-list
>

A lot of ranting indeed... I agree that Tk has a few shortcomings (I never
use it myself), but since many people are currently using it, I don't see an
easy way of replacing Tk with anything else. FWIW, I like the ideas of FLTK
(very lightweight, just draw all widgets itself + has good OpenGl support),
although the project seems to have lost its momentum. I think that you are
suggesting something like that, but written in Python.

Almar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20101230/b62680ea/attachment.html>

[Hank Fay]

1) pyjamas has a desktop version.

2) I don't consider JSONRpc to be a deal-breaker, and since that's what pyjamas uses naturally, and since it's incredibly easy to use the Python middleware of your choice for the JSONRpc server, running in different browsers is unlikely to be an issue.

3) I don't think legacy apps should be a consideration in deciding what tooling is going to be built today: building for all the yesterdays is a recipe for stagnation. Besides, the legacy apps have their own toolsets for maintenance: if they are to be converted, converting them to a form that can run anywhere (using, e.g., PhoneGap to access native UI hooks) seems to me the best choice.

That said, pyjamas has only the beginnings of a visual designer (pyjsglade at http://sourceforge.net/projects/pyjsglade/). It's being written in Python, too, which should please you (as it does me -- so much so that I volunteered to be a documenter for the project).

I think pyjamas combined with pyjsglade could be the foundation for a pythonic ui development environment that could carry us forward for many years to come, unlike those available today in Python.

Hank

PS: At first I thought you were going to do a riff on "The Plan" from years ago. I had broken 5 ribs in multiple places in a bicycling accident 2 days before when a friend faxed it to me (it was that far back): I can't tell you how much it hurt to laugh so hard. <s> But this isn't a laughing matter: I see it as the main impediment to opening up Python to the kinds of programmers who used Access, VB6 and VFP to build the kinds of domain-knowledge-specific apps that continue to enhance many workplaces.

[Hank Fay]

1) pyjamas has a desktop version.

2) I don't consider JSONRpc to be a deal-breaker, and since that's what pyjamas uses naturally, and since it's incredibly easy to use the Python middleware of your choice for the JSONRpc server, running in different browsers is unlikely to be an issue.

3) I don't think legacy apps should be a consideration in deciding what tooling is going to be built today: building for all the yesterdays is a recipe for stagnation. Besides, the legacy apps have their own toolsets for maintenance: if they are to be converted, converting them to a form that can run anywhere (using, e.g., PhoneGap to access native UI hooks) seems to me the best choice.

That said, pyjamas has only the beginnings of a visual designer (pyjsglade at http://sourceforge.net/projects/pyjsglade/). It's being written in Python, too, which should please you (as it does me -- so much so that I volunteered to be a documenter for the project).

I think pyjamas combined with pyjsglade could be the foundation for a pythonic ui development environment that could carry us forward for many years to come, unlike those available today in Python.

Hank

PS: At first I thought you were going to do a riff on "The Plan" from years ago. I had broken 5 ribs in multiple places in a bicycling accident 2 days before when a friend faxed it to me (it was that far back): I can't tell you how much it hurt to laugh so hard. <s> But this isn't a laughing matter: I see it as the main impediment to opening up Python to the kinds of programmers who used Access, VB6 and VFP to build the kinds of domain-knowledge-specific apps that continue to enhance many workplaces.

[Steven D'Aprano]

On Wed, 29 Dec 2010 15:58:53 -0800, rantingrick wrote:

> Tkinter: The good, the bad, and the ugly!
> -----------------------------------------
> An expose by rantingrick


Your ideas are intriguing to me and I wish to subscribe to your
newsletter.


> The answer is simple. We need a 100% Python GUI. A GUI coded in Python
> from top to bottom. A GUI that is cross platform to the big three
> (Windows, Linux, and Mac). A GUI that not only is easy as Tkinter but
> also a GUI that can be manipulated by the average python programmer. A
> GUI that not only teaches the fundamentals of using a GUI, but also a
> GUI that teaches how a GUI works under the hood

I look forward to seeing this software of yours. Let us know when you've
got some code, and not just empty talk.



--
Steven

[Adam Skutt]

On Dec 29, 7:48?pm, "Octavian Rasnita" <orasn... at gmail.com> wrote:
> First, the interface should look exactly as the native interfaces for each system named, and it should provide the same features, because otherwise the interface would look strange for all the users on all the operating systems.
> And of course, it should not only look OK, but it should also follow the accessibility standards for beeing accessible for screen readers also.
>

Which is where the contradiction comes into play: to use the actual
native widgets, you have to write some C (or Objective-C). Of course,
on Windows, people have faked the native widgets so many times that
you could probably get away with it if you made a really good fake,
though there are still a lot of gotchas that go with that
(accessibility and all that "other stuff"). On Linux, it's not like
there's really a standard anyway. That leaves OS X as the really
troublesome one.

>WxPython is fast because it is made in C - it uses the native GUI elements of the OS which are also made in C. Would a Python - only GUI have the same speed? If yes, it would be great.
>

Speed is not even on the list of things I'd be worried about first.

Adam

[Kevin Walzer]

On 12/29/10 6:58 PM, rantingrick wrote:
> The answer is simple. We need a 100% Python GUI. A GUI coded in Python
> from top to bottom. A GUI that is cross platform to the big three
> (Windows, Linux, and Mac). A GUI that not only is easy as Tkinter but
> also a GUI that can be manipulated by the average python programmer. A
> GUI that not only teaches the fundamentals of using a GUI, but also a
> GUI that teaches how a GUI works under the hood

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.

--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

[rantingrick]

On Dec 30, 8:59?am, Kevin Walzer <k... at 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.

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.

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!

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!

[Kevin Walzer]

On 12/30/10 10:24 AM, rantingrick wrote:
> On Dec 30, 8:59 am, Kevin Walzer<k... at 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

[python]

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

+1 (emphasis added)

Other tk/ttk benefits:
- Very stable
- Cross platform (w/native look and feel via Python 2.7/3.1 ttk)
- Light weight
- Easy to distribute
- Extensible

Regarding lack of print support: All GUI frameworks suck in this regard.
The best approach is to use a technology designed for generating hard
copy output - something like PDF, TeX, or RTF library.

Malcolm

[rantingrick]

On Dec 30, 9:51?am, Kevin Walzer <k... at codebykevin.com> wrote:
>
> 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,

Anybody can gloat and gush about their favorite programming language
however what separates fantasy from reality is evidence of these
"theories". Or rather, Illusions of grandeur!

> and surpasses Python in some respects.

The only thing that Tcl has over Python is building Tk GUI's. Please
post evidence otherwise if you dare! In the meantime i will not be
holding my breath.

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

True windows has no "one-liner" "send-to-print-function" but what it
does have is GDI and GDI+ which are far more powerful for windows
programmers. Sure you may have to issue a few dc.MoveTo(x,y) and
dc.LineTo(x,y) and dc.TextOut(blah) but what is so hard about that?
Really, if you want a one liner just wrap up some Python code into a
nice interface. This argument is either completely bogus or utterly
idiotic.

> 2. A robust widget for HTML display.

The fact that Tkinter lacks an HTML widget is of no concern to me.
Actually if i had a choice of including HTML support or not i would
opt for not. Why? Because the simple fact is that Python needs a
simplistic GUI and not bloat-ware in the stdlib. HTML widgets, handy
dandy anolog clocks, happy faces and dancing bananas widgets belong in
3rd party extension library's and not in the Python stdlib. However we
must make sure that any GUI we support not only has these widgets
available as extension libraries but that these libraries are
currently maintained. If you are going to complain about lacking
widgets then Togl would be a good starting point.


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

Yes Tk is not all bad for TclTk, however it IS all bad for Python. Let
the Tcl folks use Tk and we will use a python GUI. Nuff said.

> Togl is still developed. One of its maintainers, Greg Couch, is a
> developer on the UCSF Chimera project (a Python-Tkinter based molecule
> viewer).

Have you seen the code in togl.py yourself? I mean really read it from
beginning to end? It's a hodgepodge of poorly written code. I know
this because i had to update the code myself for one of my projects.

Look i have nothing against you Kevin. However i know you and Tkinter
(and Tcl) are in bed together. So this is more of a *personal*
decision for you instead of a *community* decision. Whether Tkinter
exists in the stdlib or not should't matter to you because you can
just download it from a 3rd party site.

And *if* enough people really love Tkinter as you suggest then
removing it will not kill it. However you know as well as i do that
Tkinter is a drain on this community and the only thing keeping it
alive is the fact that it is packaged in the stdlib. Once Tkinter is
removed it will die as it should and something better will take it's
place. Something more Pythonic. And most importantly something that is
completely and totally under the direct control of the Python
community.

[Kevin Walzer]

On 12/30/10 12:36 PM, rantingrick wrote:
> On Dec 30, 9:51 am, Kevin Walzer<k... at codebykevin.com> wrote:
>>
>> 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,
>
> Anybody can gloat and gush about their favorite programming language
> however what separates fantasy from reality is evidence of these
> "theories". Or rather, Illusions of grandeur!

You can build web servers, database tools, FTP clients, test
suite/automation tools, chat clients, and drivers of other CLI tools
with Tcl, just to name a few. In terms of what can be done with the
language, I'm not aware of anything that can be done in Python that
can't be done in Tcl.

The size of Python's community and its large standard library are an
advantage over Tcl. While Tcl is technically capable of many things,
it's often easier to find a Python library already coded for specific
functions--for instance, while Tcl has XML parsing and can parse RSS, it
doesn't have a rich library like feedparser all wrapped up and ready to go.

>
>> and surpasses Python in some respects.
>
> The only thing that Tcl has over Python is building Tk GUI's. Please
> post evidence otherwise if you dare! In the meantime i will not be
> holding my breath.

I find that Tcl's "everything is a string" representation offers a more
flexible and expressive approach in certain contexts. Tcl's "exec"
function makes interacting with external tools simpler than os.popen and
subprocess--I can get the output of a command with less code.

Of course, this is partly a matter of taste.

--Kevin

--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

[rantingrick]

On Dec 30, 4:44?pm, Kevin Walzer <k... at codebykevin.com> wrote:

> You can build web servers, database tools, FTP clients, test
> suite/automation tools, chat clients, and drivers of other CLI tools
> with Tcl, just to name a few.

Ok, thats swell. But do you have any real examples, links, or some
evidence of this? Or are we witnessing more wishful thinking?

> In terms of what can be done with the
> language, I'm not aware of anything that can be done in Python that
> can't be done in Tcl.

Again the proof is in the pudding my friend!

> The size of Python's community and its large standard library are an
> advantage over Tcl.

Yes, go on...

> While Tcl is technically capable of many things,
> it's often easier to find a Python library already coded for specific
> functions--for instance, while Tcl has XML parsing and can parse RSS, it
> doesn't have a rich library like feedparser all wrapped up and ready to go.

Thanks, well i must say that it it getting easier to win this
argument.

> I find that Tcl's "everything is a string" representation offers a more
> flexible and expressive approach in certain contexts.

Maybe but that is hardly going to "woo" the masses is it?

> Tcl's "exec"
> function makes interacting with external tools simpler than os.popen and
> subprocess--I can get the output of a command with less code.

Newsflash!, NewsFlash!, Python has an exec function. Am i missing
something here? :)

> Of course, this is partly a matter of taste.

Well your posts so far are leaning heavily that way Kevin :)

[Kevin Walzer]

On 12/30/10 6:17 PM, rantingrick wrote:

> Ok, thats swell. But do you have any real examples, links, or some
> evidence of this? Or are we witnessing more wishful thinking?

http://tcl.apache.org/rivet/
http://www.amsn-project.net/
http://thecoccinella.org/
http://personal5.iddeo.es/andresgarci/tclcurl/english/
http://openacs.org/
http://www.aolserver.com/
http://www.macports.org/
http://www.nist.gov/el/msid/expect.cfm
http://www.simulistics.com/
http://personal5.iddeo.es/andresgarci/getleft/english/
http://model.com/
http://sqlitestudio.one.pl/index.rvt
http://www.speech.kth.se/wavesurfer/
http://www.ellogon.org/
http://moodss.sourceforge.net/
http://www.projectforum.com/
http://www.eggheads.org/
http://brlcad.org/
http://www.muonics.com/

--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

[Owen Jacobson]

On 2010-12-30 12:36:05 -0500, rantingrick said:

> On Dec 30, 9:51?am, Kevin Walzer <k... at codebykevin.com> wrote:
>>
>> 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,
>
> Anybody can gloat and gush about their favorite programming language
> however what separates fantasy from reality is evidence of these
> "theories". Or rather, Illusions of grandeur!

One: it's "delusions" of grandeur.

>> and surpasses Python in some respects.
>
> The only thing that Tcl has over Python is building Tk GUI's. Please
> post evidence otherwise if you dare! In the meantime i will not be
> holding my breath.

Two: were you raised in a barn? How the hell did you get so up on
yourself that you think this is an okay way to respond to a perfectly
civil post? Abusing people's opinions and soldiering around demanding
everyone justify themselves to you is a great way to get people to
ignore whatever point you were trying to make.

>From your other posts, I gather that you have a very clear idea of what
your ideal Python GUI framework would look like. That puts you in the
best possible position to implement it. If you're successful, share it
around; if it's good, it will gain traction on its own merit. You're
not earning any traction on rhetorical grounds here.

-o

[Terry Reedy]

On 12/30/2010 10:51 AM, Kevin Walzer wrote:

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

Uh.
1. Postscript is somewhat obsolete; being superseded somewhat by svg.
2. It is not as useful on Windows as it seems to be on *nux and macs --
not easy to either view or print.

3. The files it calls '.eps' are not readable by OOo. They can be read
by Photoshop, which can then write a file, supposedly the same but
actually not, that *can* be read by OOo. There was a thread on this list
about the issue.

I do not know whether tk is too sloppy in what it writes (and the file I
look for a trivial drawing did look sloppy, with lots of near
repetition) or whether OOo is too strict. But clearly, TK *could* write
better .eps files (like Photoshop does). And the current output is
clearly limited for my purposes.

--
Terry Jan Reedy

[Steven D'Aprano]

On Thu, 30 Dec 2010 07:24:04 -0800, rantingrick wrote:

> Also one could argue that C and Python are very similar.

One could also argue that black is white, that diamond is softer than
chalk, and that bananas are a type of spaceship. Doesn't make it so.

How to add two numbers in C:

#include <stdio.h>
int main()
{
int a, b;
scanf("%d%d", &a, &b);
printf("%d\n", a + b);
return 0;
}

And in Python:

a, b = input().split() # use raw_input in Python 2
print(int(a) + int(b))


And in Tcl:

scan [gets stdin] "%d %d" x y
puts [expr {$x + $y}]


None of the three are exactly clones of each other, but it seems to me
that Tcl and Python are quite close in spirit, if not syntax.


--
Steven

[Mel]

Steven D'Aprano wrote:

> On Thu, 30 Dec 2010 07:24:04 -0800, rantingrick wrote:
>
>> Also one could argue that C and Python are very similar.
>
> One could also argue that black is white, that diamond is softer than
> chalk, and that bananas are a type of spaceship. Doesn't make it so.
>
> How to add two numbers in C:
>
> #include <stdio.h>
> int main()
> {
> int a, b;
> scanf("%d%d", &a, &b);
> printf("%d\n", a + b);
> return 0;
> }
>
> And in Python:
>
> a, b = input().split() # use raw_input in Python 2
> print(int(a) + int(b))
>
>
> And in Tcl:
>
> scan [gets stdin] "%d %d" x y
> puts [expr {$x + $y}]
>
>
> None of the three are exactly clones of each other, but it seems to me
> that Tcl and Python are quite close in spirit, if not syntax.

They both have the interpreter spirit. Very different under the hood; Tcl
is the LISP of strings. They could have called it STRP.

Mel.

[rantingrick]

On Dec 30, 1:51?pm, Steven D'Aprano <steve
+comp.lang.pyt... at pearwood.info> wrote:
> How to add two numbers in C:
>
> [...snip code example...]
>
> None of the three are exactly clones of each other, but it seems to me
> that Tcl and Python are quite close in spirit, if not syntax.

Yes i'll agree to that if you also agree that Python and Perl are the
same. Then i "maybe" your "suggestion" holds water, maybe. But you
forgot to comment on the other big point which is... What language
would you rather spend your time learning if you only had C and Tcl to
choose from? If you answer Tcl you are either foolish or just trying
to win the argument by playing devils advocate, and in that case
you're even more foolish!

The moral is that C and Python are far more useful to any programmer
than Tcl will ever be -- whether you consider them together or apart
does not matter. Tcl is too limited whereas Python and especially C
are far more useful in various situations.

[Robert]

On 2010-12-30 18:12:21 -0500, rantingrick said:

> On Dec 30, 1:51?pm, Steven D'Aprano <steve
> +comp.lang.pyt... at pearwood.info> wrote:
>> How to add two numbers in C:
>>
>> [...snip code example...]
>>
>> None of the three are exactly clones of each other, but it seems to me
>> that Tcl and Python are quite close in spirit, if not syntax.
>
> Yes i'll agree to that if you also agree that Python and Perl are the
> same. Then i "maybe" your "suggestion" holds water, maybe. But you
> forgot to comment on the other big point which is... What language
> would you rather spend your time learning if you only had C and Tcl to
> choose from? If you answer Tcl you are either foolish or just trying
> to win the argument by playing devils advocate, and in that case
> you're even more foolish!
>
> The moral is that C and Python are far more useful to any programmer
> than Tcl will ever be -- whether you consider them together or apart
> does not matter. Tcl is too limited whereas Python and especially C
> are far more useful in various situations.

I'll bite. Exactly how is Tcl too limited in your view?

--
Robert

[Gerry Reno]

For those that are lurking, this might provide a little background:

http://journal.dedasys.com/2010/03/30/where-tcl-and-tk-went-wrong



Essentially, there is nothing "wrong" with Tcl and Tkinter. They are
part of a long evolutionary chain of how we got to where we are today.
They deserve to be respected for the contributions that they have made.

The question now is whether Python needs to evolve its own GUI toolset.


Regards,
Gerry

[Robert]

On 2010-12-30 19:43:21 -0500, Gerry Reno said:

> For those that are lurking, this might provide a little background:
>
> http://journal.dedasys.com/2010/03/30/where-tcl-and-tk-went-wrong
>
>
>
> Essentially, there is nothing "wrong" with Tcl and Tkinter. They are
> part of a long evolutionary chain of how we got to where we are today.
> They deserve to be respected for the contributions that they have made.
>
> The question now is whether Python needs to evolve its own GUI toolset.
>
>
> Regards,
> Gerry

You mean outside of wxPython or PySide/PyQt? I don't see the need really.

--
Robert

[rantingrick]

On Dec 30, 6:43?pm, Gerry Reno <gr... at verizon.net> wrote:
> For those that are lurking, this might provide a little background:
>
> ? ?http://journal.dedasys.com/2010/03/30/where-tcl-and-tk-went-wrong


That was a great and thought provoking article Gerry. Thanks!

[rantingrick]

On Dec 30, 6:32?pm, Robert <sigz... at gmail.com> wrote:
> Exactly how is Tcl too limited in your view?

Well Robert if have explain to you why C and Python make Tcl look
limited by comparison then explaining will probably do neither of us
any good. But if you think Tcl is so great by all means go spend the
next couple of years writing legacy code until you realize one day it
was all for nothing.

But let's get back on topic here shall we. I have some questions
specifically for you Robert...

1. Have you ever used Tkinter?
2. If so, explain what you created with it in detail?
3. What is your opinion of Tkinter as to it's usefulness within the
stdlib?
4. How long should we keep Tkinter in the stdlib?
5. Should Python even have a GUI in the stdlib?
6. If Python should have a GUI, then what traits would serve our
community best?

I will be really surprised if you answer any of these questions. And
sorry, but i did not have time to spec out a multiple choice Q&A for
you. So take your time Robert. :)

[Robert]

On 2010-12-30 19:46:24 -0500, rantingrick said:

> On Dec 30, 6:32?pm, Robert <sigz... at gmail.com> wrote:
>> Exactly how is Tcl too limited in your view?
>
> Well Robert if have explain to you why C and Python make Tcl look
> limited by comparison then explaining will probably do neither of us
> any good. But if you think Tcl is so great by all means go spend the
> next couple of years writing legacy code until you realize one day it
> was all for nothing.

You make a big assumption. That I program in Tcl. I do not. I am
simply curious why you are being such a non-gentleman. If I was going
to program in Tcl, I would use Gnocl (a GTk binding) and not Tk. Tcl
and C will get anyone just as far as Python and C or you suck as a
programmer.

Just to clarify...I like Python. I am learning it at the moment.

>
> But let's get back on topic here shall we. I have some questions
> specifically for you Robert...
>
> 1. Have you ever used Tkinter?

Yes...nothing big though.

> 2. If so, explain what you created with it in detail?

Simple utilities is all. Simple meaning ~500-1000 LOC. I have done a
few of those just to scratch an itch.

> 3. What is your opinion of Tkinter as to it's usefulness within the
> stdlib?

No, I really don't see the need for it to be in the stdlib but that
isn't my call. I am not a huge fan of Tk as it is.

> 4. How long should we keep Tkinter in the stdlib?

See the last answer. I would yank it.

> 5. Should Python even have a GUI in the stdlib?

I would say "no" but that is my opinion only and it doesn't matter.
Python's domain isn't GUI programming so having it readily available on
the sidelines would be fine for me.

> 6. If Python should have a GUI, then what traits would serve our
> community best?

This is a good one.

It should be:

- cross platform
- Pythonic
- as "native" as possible

Cross platform and native are hard. Just look at all the work with
PyQt/PySide and wxPython. It took them years to get where they are.

>
> I will be really surprised if you answer any of these questions. And
> sorry, but i did not have time to spec out a multiple choice Q&A for
> you. So take your time Robert. :)

Hey, there you go. At least I have real answers. :-)

--
Robert

[rantingrick]

On Dec 30, 8:41?pm, Robert <sigz... at gmail.com> wrote:
> On 2010-12-30 19:46:24 -0500, rantingrick said:
> Just to clarify...I like Python. I am learning it at the moment.

Glad to have you aboard Robert!

> > 3. What is your opinion of Tkinter as to it's usefulness within the
> > stdlib?
>
> No, I really don't see the need for it to be in the stdlib but that
> isn't my call.

But it is your call Robert. Anyone who writes Python code --whether
they be a beginner with no prior programming experience or a fire
breathing Python Guru-- has a right to inject their opinion into th
community. We really need input from first time users as they carry
the very perspective that we have completely lost!

> > 5. Should Python even have a GUI in the stdlib?
>
> I would say "no" but that is my opinion only and it doesn't matter.
> Python's domain isn't GUI programming so having it readily available on
> the sidelines would be fine for me.

I agree that Python's domain is not "specifically" GUI programming
however to understand why Tkinter and IDLE exists you need to
understand what Guido's dream was in the beginning. GvR wanted to
bring Programming to everyone (just one of his many heroic goals!). He
believed (i think) that GUI programming is very important , and that
was 20 years ago!!. So he included Tkinter mainly so new Python
programmers could hack away at GUI's with little or no effort. He also
created a wonderful IDE for beginners called IDLE. His idea was
perfect, however his faith in TclTk was flawed and so we find
ourselves in the current situation we have today. With the decay of
Tkinter the dream has faded. However we can revive this dream and
truly bring Python into the 21st century!


> > 6. If Python should have a GUI, then what traits would serve our
> > community best?
>
> This is a good one.
>
> It should be:
>
> - cross platform
> - Pythonic
> - as "native" as possible
>
> Cross platform and native are hard. Just look at all the work with
> PyQt/PySide and wxPython. It took them years to get where they are.

Hmm, wxPython is starting to look like the answer to all our problems.
WxPython already has an IDE so there is no need to rewrite IDLE
completely. What do we have to loose by integrating wx into the
stdlib, really?

[Gerry Reno]

On 12/30/2010 10:28 PM, rantingrick wrote:
>
> Hmm, wxPython is starting to look like the answer to all our problems.
> WxPython already has an IDE so there is no need to rewrite IDLE
> completely. What do we have to loose by integrating wx into the
> stdlib, really?
>
>

In the spirit of "batteries included", Python needs to have "something"
in the stdlib as far as gui. But it cannot be overwhelming.

The problem with wx is that it is BIG. And so if we want something like
wx to be in the stdlib then it would have to be refactored so that there
was a small basic wx that was part of stdlib and then import
wx-the-whole-enchilada if you need heavy gui artillery.

[Robert]

On 2010-12-30 22:44:52 -0500, Gerry Reno said:

> On 12/30/2010 10:28 PM, rantingrick wrote:
>>
>> Hmm, wxPython is starting to look like the answer to all our problems.
>> WxPython already has an IDE so there is no need to rewrite IDLE
>> completely. What do we have to loose by integrating wx into the
>> stdlib, really?
>>
>>
>
> In the spirit of "batteries included", Python needs to have "something"
> in the stdlib as far as gui. But it cannot be overwhelming.
>
> The problem with wx is that it is BIG. And so if we want something like
> wx to be in the stdlib then it would have to be refactored so that there
> was a small basic wx that was part of stdlib and then import
> wx-the-whole-enchilada if you need heavy gui artillery.

It's BIG.

The question really is, do we need a GUI toolkit in the stdlib. I would
say "no". In wxPython's case it is a no-brainer to install (even as a
second package). I am not sure if PySide is "that easy" but it could be.

--
Robert

[Robert]

On 2010-12-30 22:28:39 -0500, rantingrick said:

> On Dec 30, 8:41?pm, Robert <sigz... at gmail.com> wrote:
>> On 2010-12-30 19:46:24 -0500, rantingrick said:
>> Just to clarify...I like Python. I am learning it at the moment.
>
> Glad to have you aboard Robert!

Thanks!

>
>>> 3. What is your opinion of Tkinter as to it's usefulness within the
>>> stdlib?
>>
>> No, I really don't see the need for it to be in the stdlib but that
>> isn't my call.
>
> But it is your call Robert. Anyone who writes Python code --whether
> they be a beginner with no prior programming experience or a fire
> breathing Python Guru-- has a right to inject their opinion into th
> community. We really need input from first time users as they carry
> the very perspective that we have completely lost!

I speak up. :-)

>
>>> 5. Should Python even have a GUI in the stdlib?
>>
>> I would say "no" but that is my opinion only and it doesn't matter.
>> Python's domain isn't GUI programming so having it readily available on
>> the sidelines would be fine for me.
>
> I agree that Python's domain is not "specifically" GUI programming
> however to understand why Tkinter and IDLE exists you need to
> understand what Guido's dream was in the beginning. GvR wanted to
> bring Programming to everyone (just one of his many heroic goals!). He
> believed (i think) that GUI programming is very important , and that
> was 20 years ago!!. So he included Tkinter mainly so new Python
> programmers could hack away at GUI's with little or no effort. He also
> created a wonderful IDE for beginners called IDLE. His idea was
> perfect, however his faith in TclTk was flawed and so we find
> ourselves in the current situation we have today. With the decay of
> Tkinter the dream has faded. However we can revive this dream and
> truly bring Python into the 21st century!

I don't think Tkinter was in there for "large" programming. Tkinter is
crufty and probably should be moved out. For whipping up quick gui
things to scratch an itch it is good.

I lurk more on the Tcl side of things. When the mention of "separating"
Tcl and Tk development, I fall on the side of separating them. Tcl,
like Python should stand on its own. Widget frameworks are extras to
me. One way the Tcl community has "stagnated" has been its insistence
on Tk. There was a wxTcl project...it died. That would have been good
for the Tcl community. Luckily there is a GTk framework (Gnocl) that is
really good. But it still doesn't get the props that it deserves. The
second way the Tcl community irks me is the "not invented here"
attitude. I like the syntax of Tcl and I like the community. They are
some good folks. Try asking "I want to build a Nagios clone in Tcl"
type question and invariably you get "Why? There is already Nagios?".
That stems from the "glue" language roots I think but to me that is the
wrong attitude. You want people to take a look at a language (any
language), you build stuff with it that people want to use. Ruby would
not be as big as it is if Rails hadn't come along.

Nuff of that... ;-)

>
>
>>> 6. If Python should have a GUI, then what traits would serve our
>>> community best?
>>
>> This is a good one.
>>
>> It should be:
>>
>> - cross platform
>> - Pythonic
>> - as "native" as possible
>>
>> Cross platform and native are hard. Just look at all the work with
>> PyQt/PySide and wxPython. It took them years to get where they are.
>
> Hmm, wxPython is starting to look like the answer to all our problems.
> WxPython already has an IDE so there is no need to rewrite IDLE
> completely. What do we have to loose by integrating wx into the
> stdlib, really?

wxPython is really good. The downside is that is shows (or did show)
its C++ roots.

Nokia is making a run with PySide (their version of the PyQt framework)
and since it has a company behind it might go pretty far. Qt can be
used for a lot of problem domains.

Anyway, I wasn't meaning to be rough with you. Just trying to figure
out where you were coming from. I am acquianted with Kevin Walzer and
he is a good guy.

--
Robert

[Steven D'Aprano]

On Thu, 30 Dec 2010 23:04:33 -0500, Robert wrote:

> The
> second way the Tcl community irks me is the "not invented here"
> attitude. I like the syntax of Tcl and I like the community. They are
> some good folks. Try asking "I want to build a Nagios clone in Tcl" type
> question and invariably you get "Why? There is already Nagios?".

You're the one who wants to re-write Nagios in Tcl, the Tcl community are
perfectly happy using the existing Nagios instead of re-inventing the
wheel, and you accuse *them* of suffering from NIH syndrome.

Oh the irony.


--
Steven

[Robert]

On 2010-12-30 23:20:59 -0500, Steven D'Aprano said:

> On Thu, 30 Dec 2010 23:04:33 -0500, Robert wrote:
>
>> The
>> second way the Tcl community irks me is the "not invented here"
>> attitude. I like the syntax of Tcl and I like the community. They are
>> some good folks. Try asking "I want to build a Nagios clone in Tcl" type
>> question and invariably you get "Why? There is already Nagios?".
>
> You're the one who wants to re-write Nagios in Tcl, the Tcl community are
> perfectly happy using the existing Nagios instead of re-inventing the
> wheel, and you accuse *them* of suffering from NIH syndrome.
>
> Oh the irony.

No, that was just an example! My goodness....

--
Robert

[Antoine Pitrou]

On 31 Dec 2010 04:20:59 GMT
Steven D'Aprano <steve+comp.lang.python at pearwood.info> wrote:
> On Thu, 30 Dec 2010 23:04:33 -0500, Robert wrote:
>
> > The
> > second way the Tcl community irks me is the "not invented here"
> > attitude. I like the syntax of Tcl and I like the community. They are
> > some good folks. Try asking "I want to build a Nagios clone in Tcl" type
> > question and invariably you get "Why? There is already Nagios?".
>
> You're the one who wants to re-write Nagios in Tcl, the Tcl community are
> perfectly happy using the existing Nagios instead of re-inventing the
> wheel, and you accuse *them* of suffering from NIH syndrome.

Well, I don't know about Tcl but Nagios was re-written in Python:
http://www.shinken-monitoring.org/features/

Regards

Antoine.

[Robert]

On 2010-12-31 16:52:30 -0500, Antoine Pitrou said:

> On 31 Dec 2010 04:20:59 GMT
> Steven D'Aprano <steve+comp.lang.python at pearwood.info> wrote:
>> On Thu, 30 Dec 2010 23:04:33 -0500, Robert wrote:
>>
>>> The
>>> second way the Tcl community irks me is the "not invented here"
>>> attitude. I like the syntax of Tcl and I like the community. They are
>>> some good folks. Try asking "I want to build a Nagios clone in Tcl" type
>>> question and invariably you get "Why? There is already Nagios?".
>>
>> You're the one who wants to re-write Nagios in Tcl, the Tcl community are
>> perfectly happy using the existing Nagios instead of re-inventing the
>> wheel, and you accuse *them* of suffering from NIH syndrome.
>
> Well, I don't know about Tcl but Nagios was re-written in Python:
> http://www.shinken-monitoring.org/features/
>
> Regards
>
> Antoine.

It was forked to be written in Python, yes. The whole point (and it
wasn't a Nagios port to Tcl) was that the Tcl community (and I like the
Tcl community a lot) has a strange fixation with not reinventing the
wheel, even when the wheel would be in Tcl and it might give Tcl more
exposure. It is what it is though.

--
Robert

[rantingrick]

On Dec 30, 9:44?pm, Gerry Reno <gr... at verizon.net> wrote:

> In the spirit of "batteries included", Python needs to have "something"
> in the stdlib as far as gui. ?But it cannot be overwhelming.

Agreed!

> The problem with wx is that it is BIG. ?And so if we want something like
> wx to be in the stdlib then it would have to be refactored so that there
> was a small basic wx that was part of stdlib and then import
> wx-the-whole-enchilada if you need heavy gui artillery.

Exactly! All we need to do is replace the existing Tkinter with a
small sub-set of wxPython widgets that mirrors exactly what we have
now...

Toplevel
Label
Entry
Button
Radiobutton
Checkbutton
Canvas
Textbox
Listbox
Menu
Scale
Scrollbar

...thats all you need in the std library "widget wise". The rest of
what makes up wx can exist in the "wxPython Extension Library".
Python needs this change! We have already made incompatible changes so
now is the time to start seriously brainstorming on how we can
integrate the beauty, elegance, and feature rich power of wxPython.

[Adam Skutt]

On Dec 30, 11:24?pm, rantingrick <rantingr... at gmail.com> wrote:
>
> > The problem with wx is that it is BIG. ?And so if we want something like
> > wx to be in the stdlib then it would have to be refactored so that there
> > was a small basic wx that was part of stdlib and then import
> > wx-the-whole-enchilada if you need heavy gui artillery.
>
> Exactly! All we need to do is replace the existing Tkinter with a
> small sub-set of wxPython widgets that mirrors exactly what we have
> now...
>
> Toplevel
> Label
> Entry
> Button
> Radiobutton
> Checkbutton
> Canvas
> Textbox
> Listbox
> Menu
> Scale
> Scrollbar
>
> ...thats all you need in the std library "widget wise". The rest of
> what makes up wx can exist in the ?"wxPython Extension Library".
> Python needs this change! We have already made incompatible changes so
> now is the time to start seriously brainstorming on how we can
> integrate the beauty, elegance, and feature rich power of wxPython.

I have never, ever, made a GUI that consistent only of those options
excep when following a tutorial, sorry. While I won't claim to stand
for anyone else, I'm hardly alone, judging by /every application
running on my desktop right now/. Well, maybe notepad.

Interesting applications require interesting features. Anything you
end up writing is going to be at least as complicated as TkInter for
the standard library, if not vastly more so, and have all of the same
faults you find in TkInter. This would be because such problems are
fundamentally inescapable, a simple fact of reality you have yet to
even grasp, AFAICT, much yet acknowledge.

Adam

[rantingrick]

On Dec 30, 10:41?pm, Adam Skutt <ask... at gmail.com> wrote:
> On Dec 30, 11:24?pm, rantingrick <rantingr... at gmail.com> wrote:
> > Exactly! All we need to do is replace the existing Tkinter with a
> > small sub-set of wxPython widgets that mirrors exactly what we have
> > now...
>
> > Toplevel
> > Label
> > Entry
> > Button
> > Radiobutton
> > Checkbutton
> > Canvas
> > Textbox
> > Listbox
> > Menu
> > Scale
> > Scrollbar

> I have never, ever, made a GUI that consistent only of those options
> excep when following a tutorial, sorry. ?While I won't claim to stand
> for anyone else, I'm hardly alone, judging by /every application
> running on my desktop right now/. ?Well, maybe notepad.

Of course a tiny widget set like this is not going to handle extensive
GUI coding, thats a no brainer. But currently that is EXACTLY what we
have to work with in the stdlib. Sure you have TIX and a few other
extensions but they will never compare to the vast features of
wxPython. Have you even aquinted yourself with wxPython Adam?

What i (and others) are proposing is to replace the existing Tkinter
library with a matching wxPython libray. Then allocate the remaining
wxPython library (which is ginormous btw!) into a 3rd party module
available for download. My argument is that because wxPython is soooo
feature rich. We will break the glass ceiling that exist now with
Tkinter.


> Interesting applications require interesting features. ?Anything you
> end up writing is going to be at least as complicated as TkInter for
> the standard library, if not vastly more so,

Agreed! We need at least the same capability that Tkinter offers in
the stdlib. Why would we sacrifice?

> and have all of the same
> faults you find in TkInter.

Thats not true. Yes all projects have faults of some kind. I am not
suggesting that wxPython is some sort of "miracle" library. However
anyone of average intelligence can do a side by side comparison and
agree that wx is far superior to TclTk in many, many ways. If you have
a valid argument as to how Tkinter is better feel free to share this
information with us.

> ?This would be because such problems are
> fundamentally inescapable, a simple fact of reality you have yet to
> even grasp, AFAICT, much yet acknowledge.

Adam, Adam. I feel you are desperately trying to inject negative
energy into what is now the very beginnings of a healthy and positive
community discussion on the future of Python's GUI library. If you do
care about Python's future then you should get involved with this
discussion in a positive way. You can disagree with me and still be
positive. I wish you would spend more energy bringing forth your own
ideas and thoughtful discussion instead of resorting to these wasteful
and vengeful tactics.

So with that in mind i ask you some direct questions...

1. Do you use Tkinter yourself?
2. Explain some of the applications you have created with Tkinter.
3. How do you feel about Tkinter being in the stdlib?
4. Should Python even include a GUI library?
5. If so, what traits should this library encompass?
6. If you could choose what library do you think would be in the
communities best interest?

[Adam Skutt]

On Dec 31, 12:21?am, rantingrick <rantingr... at gmail.com> wrote:

> Of course a tiny widget set like this is not going to handle extensive
> GUI coding, thats a no brainer.

No, it's not going to handle any GUI coding except notepad.exe.
That's already been written, so we're left with no new application
that can be written with this proposed minimal widget set. Why do you
think Tix exists? Why do you think there are Python bindings for it
in the standard library (to say nothing of a bunch of other additional
Tk controls)?

> But currently that is EXACTLY what we
> have to work with in the stdlib. Sure you have TIX and a few other
> extensions but they will never compare to the vast features of
> wxPython. Have you even aquinted yourself with wxPython Adam?
>

It is nothing of the sort even if you erroneously believe it is. Have
you looked at Tix? The fact you dismiss it away as some "extension"
like it is a leper really betrays your argument. Others (not you)
have already described the legitimate deficiencies at length, I will
defer to them.

> ?What i (and others) are proposing is to replace the existing Tkinter
> library with a matching wxPython libray. Then allocate the remaining
> wxPython library (which is ginormous btw!) into a 3rd party module
> available for download. My argument is that because wxPython is soooo
> feature rich. We will break the glass ceiling that exist now with
> Tkinter.
>

And what I pointed out is that wxWidgets (and Qt, and Swing, and Tk+Tix
+whatever, and every other GUI toolkit in existence) is so feature
rich for a reason: you actually need all of that stuff in order to
build rich, functional, useful GUI applications. I think you'll find
that it's very hard to cut any functionality, even functionality
Python more or less entirely replicates (e.g., wxNet, wxODBC). Why?
Because useful widgets rely on such low-level functionality (blame C+
+'s rather anemic standard library).

Moreover, even if you find things to cut, coming to a consensus about
what belongs outside of the stdlib will be difficult, if not
impossible; plus, it's considerable work for very little gain: I still
need a full install of wxwidgets to even build your useless minimal
set. There's definitely no point in minimizing the python side of
things if it doesn't minimize the native code side of things. Note
how the divisions with the Tk bindings follow the divisions of the
native libraries.

> Agreed! We need at least the same capability that Tkinter offers in
> the stdlib. Why would we sacrifice?

I don't know, but a sacrifice is precisely what you proposed.

> Thats not true. Yes all projects have faults of some kind. I am not
> suggesting that wxPython is some sort of "miracle" library. However
> anyone of average intelligence can do a side by side comparison and
> agree that wx is far superior to TclTk in many, many ways. If you have
> a valid argument as to how Tkinter is better feel free to share this
> information with us.

>From this claim I've forced to conclude you are not of average
intelligence, because you haven't managed yet to do an actual, factual
side-by-side comparison of wxWidgets and Tk. Here is one to start: the
native footprint of Tk has fewer dependencies than the native
footprint of wxWidgets.

> Adam, Adam. I feel you are desperately trying to inject negative
> energy into what is now the very beginnings of a healthy and positive
> community discussion on the future of Python's GUI library.

There's nothing positive about this discussion, since it's being
spearheaded by arrogance and ignorance. It's highly improbable, in
fact, for this discussion to ever be healthy and positive without a
desperate attitude and behavior chance on your part.

Seriously, given that widget set you listed, what applications am I
supposed to write? I can't write a web browser. I can't write an
audio player. I can't write a terminal. I can't write an IM client.
I can't write a social media client/application/mashup. I can't write
a web browser. I can't write a game community client/launcher. I
can't write office productivity applications. So what can I write?

The fact your proposal shows you're entirely disconnected with reality
isn't my fault in the least, nor does it mean I'm "trying to inject
negative energy", nor that I'm "resorting to these wasteful and
vengeful tactics."

You want to be told your proposal isn't disconnected with reality?
Then propose ideas that actually have technical merit and that can be
actually accomplished, instead of proposing things that plainly lack
merit to anyone who's ever written a complicated GUI application
before and/or that are flat-out impossible. Calling a bad proposal a
bad proposal is a positive thing, like it or not. If you can't accept
that, you should consider a pastime that involves less criticism.

> If you do care about Python's future then you should get involved with this
> discussion in a positive way.

I have, I told you what you want to do isn't possible. The fact you
don't want to nor like to hear that doesn't mean it is not positive.
A pure Python GUI toolkit isn't really possible. Even if we agreed
that "pure" means something akin to AWT, it's still a really awful
idea (again, for really obvious reasons). Building something like WPF
would be worthwhile, but won't free you from needing a traditional GUI
library for quite some time, so you're still right back where we
started.

Replacing TkInter with some sort of minimized wxwidgets is a dumb idea
for some very obvious reasons, reasons that are obvious if you simply
look at a widget gallery and then the applications you run on your own
computer. Quite honestly, if you're not capable of that, there's
little reason to believe you'll ever be able to bring forth a
coherent, cogent proposal.

Adam

[rantingrick]

On Dec 31 2010, 8:47?am, Adam Skutt <ask... at gmail.com> wrote:


Ok, at this point i am not going to respond to the last few posts that
where directed at me. What i am going to do is to restate my
intentions at the time i started this thread.

First and foremost i want everyone to know that i have tons of GUI
code that utilizes the Tkinter module and feel very confident crating
GUI's with Tkinter. I am not some novice who tried to write up a hello
world GUI, got aggravated, and then decided to vent about it. Quite to
the contrary...

I actually like Tkinter's simplistic API. I especially love Tkinter
geometry management! However i realize that TclTk is lacking and
because of that fact we will always be at the mercy of another
community. This bothers me, and it should also bother you. Tk has a
glass ceiling that cannot be broken by you, or me, or anyone in the
Python community. If we are to have a GUI library it should be one
that is up to date and feature rich. In the latter case there may
still be a glass ceiling but it is so high they we will never notice
anyway!

However be aware that GUI's libraries are large beasts. You cannot
cram everything into the stdlib. So what should go into the stdlib
then? Well only a very limited subset of widgets. Some might say that
you will be limited with a limited subset, well i must agree with
argument :). Some might also say that a glass half full is also half
empty, duh!

Everyone needs to realize that the only reason for having ANY GUI in
the Python stdlib is for ease of learning and also for "batteries
included". We just want the basics of a GUI with an extension library
available for download. There are two major advantages to this
setup...

1. The basics never change. So the Python "stdlib GUI module" becomes
a "set it and forget it" module. The Python "GUI extension library"
can change all it wants and Python remain backwards compatible.

2. By relegating the bloat to an external download the stdlib is kept
as small as possible.

... These two talking points are the main idea behind this whole damn
discussion i initiated. We need to look beyond our own selfish needs
and think about the community first. Anyone who truly cares about
Python's stability and future will agree with these two points.

I'll repeat... TclTk has had a whole decade to become a 21st century
GUI library. I really don't think the motivation is there. Some will
argue that ttk brings in the new widgets necessary to compete with a
full featured GUI like wxPython -- and they could not be more wrong!

There is no real Tk::Grid. Sure as someone suggested you can mimic a
grid with another widget, it's just lipstick on a pig really. Go and
check out the wx::Grid with all its wonderful capabilities and then
you shall be enlightened!

This is also no real support for a true Listview widget. Again go
check out wx::ListView with all it's capabilities and ye shall be
further enlightened.

Wx is by far the best choice for Python. A small subset of wx widgets
in the stdlib and ONE (and only one!) downloadable extension library.
Yes the stdlib widgets are only going to cover the most minimal of
GUIs -- for learning purposes, utilities, or just simply toys) If you
plan to do professional GUI work than package the extension library.
It's very simple really.

Geesh! Now i know how the early scientist felt when trying to convince
the lemmings that the earth is not flat!

Flatearther said: """You heritic!. If the earth were round we would
fall off the bottom!"""

[Adam Skutt]

On Jan 1, 5:03?pm, rantingrick <rantingr... at gmail.com> wrote:

> I actually like Tkinter's simplistic API. I especially love Tkinter
> geometry management! However i realize that TclTk is lacking and
> because of that fact we will always be at the mercy of another
> community. This bothers me, and it should also bother you.

It's true of any widget library out there. It's inescapable. Python
bindings to the native widgets are still at the mercy of MS and Apple
(and GTK+ or Qt, whomever you pick for UNIX ). We've seen how much
Apple cares about 3rd-party developers, and while MS at least cares,
you never know when or how they'll implement something. Look at the
mess with the ribbon, for example. There's the Office version, an MFC/
Win32/COM version, and a WPF version. Not only do all three have
slightly different APIs, they all behave slightly differently too
w.r.t the end-user.

Even a "pure python" GUI library cannot get rid of this problem
entirely. Witness that Xlib is (slowly) being deprecated for XCB[1].
It's possible, though unlikely, that MS will eventually stop providing
new functionality through Win32 and/or make radical changes. It's
also possible, though unlikely, that Apple will eventually pull
another stunt on the level of deprecating Carbon and rip apart
Quartz. Any of those changes would require drastic implementation
changes on the part of the python GUI library.

It's inescapable, so it's generally best not to worry about it.

> However be aware that GUI's libraries are large beasts. You cannot
> cram everything into the stdlib.

Who says? Java does. Android does. Microsoft does. Apple does.

> So what should go into the stdlib then?
> Well only a very limited subset of widgets. Some might say that
> you will be limited with a limited subset, well i must agree with
> argument :). Some might also say that a glass half full is also half
> empty, duh!

No, not 'duh'. You have to explain what the utility of doing such a
thing is, as the utility is not apparent in the least. You also need
to explain how this is actually accomplished. I don't see it as a
trivial task, especially if the implementation path is to wrap
something else. What we have now is about as minimal as things are
going to get.

>
> Everyone needs to realize that the only reason for having ANY GUI in
> the Python stdlib is for ease of learning and also for "batteries
> included". We just want the basics of a GUI with an extension library
> available for download. There are two major advantages to this
> setup...
>
> 1. The basics never change. So the Python "stdlib GUI module" becomes
> a "set it and forget it" module. The Python "GUI extension library"
> can change all it wants and Python remain backwards compatible.
>

No, I don't see how this follows in the least, especially if the
implementation path is, "wrap something else". But even in the pure
Python case, most (nearly all) GUI applications will rely on the
extension library, so it will not be able to change all it wants.

> 2. By relegating the bloat to an external download the stdlib is kept
> as small as possible.
>
It's not apparent why this is desirable to me. Even if we take it as
a tautology, you need to show the value and means for splitting up a
GUI library. Your cutting may result in their being more value by not
including a GUI at all. Trivial proof: if everyone ends up needing to
download the extension library anyway, you incur no cost for anyone
and make the standard library smaller by not including any GUI
functionality.

So go on, show us a minimized, functional widget set and what we can
do with it. We're all pretty eagerly awaiting such a thing.

> There is no real Tk::Grid. Sure as someone suggested you can mimic a
> grid with another widget, it's just lipstick on a pig really. Go and
> check out the wx::Grid with all its wonderful capabilities and then
> you shall be enlightened!
>

TkTable seems to do everything wx::Grid[sic] can do. I didn't check
fully, as it's your claim, so your responsibility to show the
inadequacies, especially since you don't even seem to be aware of
TkTable's existence. The biggest missing feature seems to be DnD
support, AFAICT. BFD to me, since I've never actually encounterd DnD
support worth a damn ever and have always ended up doing it manually.

> Wx is by far the best choice for Python. A small subset of wx widgets
> in the stdlib and ONE (and only one!) downloadable extension library.
> Yes the stdlib widgets are only going to cover the most minimal of
> GUIs -- for learning purposes, utilities, or just simply toys) If you
> plan to do professional GUI work than package the extension library.
> It's very simple really.
>

Why split it, if you use wx[sic]? All that saves you is a few .py/.c
files in the stdlib. You still need the full wxWidgets install to
build even the "minimal set", which is pointless and stupid. The
costly part with wxWidgets is depending on the native library, not the
amount of code in the stdlib.

Again, do you think the various Tk bindings fall along library lines
just for fun, or that there just possibly might be a method to the
madness?

> Geesh! Now i know how the early scientist felt when trying to convince
> the lemmings that the earth is not flat!
>
> Flatearther said: """You heritic!. If the earth were round we would
> fall off the bottom!"""

You can pretend you're being persecuted all you want, but it really
only furthers the opinion that you're completely and fully
disconnected from reality. The torches you see are entirely of your
own imagination.

Adam

[1] In the case of X, you could write your own protocol library, but
then when the protocol changes...

[CM]

Rantingrick,

Find a closet in your home, go inside, turn off the lights, and shout
into a thermos; that will likely have a similar result as these posts
on the state of GUI libraries in Python. There is something admirable
about the FOSS philosophy of "You want it? You make it".

And I don't see this as a problem anyway. I wanted to do GUI
programming in Python, so I read a bit, chose wxPython, downloaded it,
and started learning it. Done.

[rantingrick]

On Jan 1, 5:39?pm, CM <cmpyt... at gmail.com> wrote:

> And I don't see this as a problem anyway. ?I wanted to do GUI
> programming in Python, so I read a bit, chose wxPython, downloaded it,
> and started learning it. ?Done.

I, I, I...Me,Me,Me.

Seems you are only concerned about yourself CM. However this a
community discussion. You must put your wants and needs in the
backseat before you can see what is best for the Python community as a
whole.

[Tim Chase]

On 01/01/2011 06:39 PM, rantingrick wrote:
> On Jan 1, 5:39 pm, CM<cmpyt... at gmail.com> wrote:
>
>> And I don't see this as a problem anyway. I wanted to do GUI
>> programming in Python, so I read a bit, chose wxPython, downloaded it,
>> and started learning it. Done.
>
> I, I, I...Me,Me,Me.
>
> Seems you are only concerned about yourself CM. However this a
> community discussion. You must put your wants and needs in the
> backseat before you can see what is best for the Python community as a
> whole.

Pot? Meet Kettle...

Given that the community response has largely been an
overwhelming "meh, show me some code" rather than an "I
whole-heartedly agree with rantingrick", your use of "we" in your
emails sounds more like a "royal we"[1] than a community-based
concern.

"best for the Python community" seems to be something that
doesn't break backwards compat. with existing code-bases, works
across a multitude of platforms, has a minimal install footprint,
and a proven track-record of meeting those needs. Tkinter and wx
both seem to satisfy most of those requirements, except that wx
seems to have a larger footprint and not have been
production-ready at the time a decision needed to be made for
inclusion of a gui-library in Python. (I also don't know if
there are licensing concerns with wx vs. tk and their interplay
with the Python license).

-tkc


[1]
http://en.wikipedia.org/wiki/Royal_we

[CM]

On Jan 1, 7:39?pm, rantingrick <rantingr... at gmail.com> wrote:
> On Jan 1, 5:39?pm, CM <cmpyt... at gmail.com> wrote:
>
> > And I don't see this as a problem anyway. ?I wanted to do GUI
> > programming in Python, so I read a bit, chose wxPython, downloaded it,
> > and started learning it. ?Done.
>
> I, I, I...Me,Me,Me.
>
> Seems you are only concerned about yourself CM. However this a
> community discussion. You must put your wants and needs in the
> backseat before you can see what is best for the Python community as a
> whole.

Must have been too many holiday baked goods that made me even try...

[rantingrick]

On Dec 30, 10:04?pm, Robert <sigz... at gmail.com> wrote:

> wxPython is really good. The downside is that is shows (or did show)
> its C++ roots.

Well i will admit the api is not as simplistic as Tkinter. However i
noticed over time that wx had started adopting a slight Tkinter "feel"
to the API and that is a good thing. So they are coming around. :)

> Anyway, I wasn't meaning to be rough with you. Just trying to figure
> out where you were coming from. I am acquianted with Kevin Walzer and
> he is a good guy.

No harm done Robert my skin is far thicker than your average grape. We
just ended up on opposite sides of a passionate argument. I hope you
stick around with us because I look forward to hearing more of your
opinions and ideas. And i agree that Kevin is a great guy! I've never
met him but i can tell from his writing style and mannerisms that he
is truly an honest and virtuous soul. And i totally understand why he
wants to keep Tkinter alive as he and i both have tons of code that
depends on Tkinter.

I wish we could keep Tkinter forever as it really is a great starter
GUI. I wrote my first GUI code with it and fell in love just like with
Python! However i know we will always be lacking our full potential
with Tkinter as developers and as a community. Sadly i see no other
way but to replace it with something more up-to-date. Sometimes we
have to "take one for the team". What is in our best interest may not
necessarily be in the community's best interest. If we *do* replace
Tkinter, it will be a very painful adjustment because it has been with
us for such a long time. However, just as Py3000 was painful at first,
and then started slowly gaining speed into a much better language, i
also believe this change will move us forward into an even greater
language.

[flebber]

On Dec 31, 3:04?pm, Robert <sigz... at gmail.com> wrote:
> On 2010-12-30 22:28:39 -0500, rantingrick said:
>
> > ?On Dec 30, 8:41???pm, Robert <sigz... at gmail.com> wrote:
> >> On 2010-12-30 19:46:24 -0500, rantingrick said:
> >> Just to clarify...I like Python. I am learning it at the moment.
>
> > Glad to have you aboard Robert!
>
> Thanks!
>
>
>
> >>> 3. What is your opinion of Tkinter as to it's usefulness within the
> >>> stdlib?
>
> >> No, I really don't see the need for it to be in the stdlib but that
> >> isn't my call.
>
> > But it is your call Robert. Anyone who writes Python code --whether
> > they be a beginner with no prior programming experience or a fire
> > breathing Python Guru-- has a right to inject their opinion into th
> > community. We really need input from first time users as they carry
> > the very perspective that we have completely lost!
>
> I speak up. ?:-)
>
>
>
>
>
> >>> 5. Should Python even have a GUI in the stdlib?
>
> >> I would say "no" but that is my opinion only and it doesn't matter.
> >> Python's domain isn't GUI programming so having it readily available on
> >> the sidelines would be fine for me.
>
> > I agree that Python's domain is not "specifically" GUI programming
> > however to understand why Tkinter and IDLE exists you need to
> > understand what Guido's dream was in the beginning. GvR wanted to
> > bring Programming to everyone (just one of his many heroic goals!). He
> > believed (i think) that GUI programming is very important , and that
> > was 20 years ago!!. So he included Tkinter mainly so new Python
> > programmers could hack away at GUI's with little or no effort. He also
> > created a wonderful IDE for beginners called IDLE. His idea was
> > perfect, however his faith in TclTk was flawed and so we find
> > ourselves in the current situation we have today. With the decay of
> > Tkinter the dream has faded. However we can revive this dream and
> > truly bring Python into the 21st century!
>
> I don't think Tkinter was in there for "large" programming. Tkinter is
> crufty and probably should be moved out. For whipping up quick gui
> things to scratch an itch it is good.
>
> I lurk more on the Tcl side of things. When the mention of "separating"
> Tcl and Tk development, I fall on the side of separating them. Tcl,
> like Python should stand on its own. Widget frameworks are extras to
> me. One way the Tcl community has "stagnated" has been its insistence
> on Tk. There was a wxTcl project...it died. That would have been good
> for the Tcl community. Luckily there is a GTk framework (Gnocl) that is
> really good. But it still doesn't get the props that it deserves. The
> second way the Tcl community irks me is the "not invented here"
> attitude. I like the syntax of Tcl and I like the community. They are
> some good folks. Try asking "I want to build a Nagios clone in Tcl"
> type question and invariably you get "Why? There is already Nagios?".
> That stems from the "glue" language roots I think but to me that is the
> wrong attitude. You want people to take a look at a language (any
> language), you build stuff with it that people want to use. Ruby would
> not be as big as it is if Rails hadn't come along.
>
> Nuff of that... ?;-)
>
>
>
>
>
> >>> 6. If Python should have a GUI, then what traits would serve our
> >>> community best?
>
> >> This is a good one.
>
> >> It should be:
>
> >> - cross platform
> >> - Pythonic
> >> - as "native" as possible
>
> >> Cross platform and native are hard. Just look at all the work with
> >> PyQt/PySide and wxPython. It took them years to get where they are.
>
> > Hmm, wxPython is starting to look like the answer to all our problems.
> > WxPython already has an IDE so there is no need to rewrite IDLE
> > completely. What do we have to loose by integrating wx into the
> > stdlib, really?
>
> wxPython is really good. The downside is that is shows (or did show)
> its C++ roots.
>
> Nokia is making a run with PySide (their version of the PyQt framework)
> and since it has a company behind it might go pretty far. Qt can be
> used for a lot of problem domains.
>
> Anyway, I wasn't meaning to be rough with you. Just trying to figure
> out where you were coming from. I am acquianted with Kevin Walzer and
> he is a good guy.
>
> --
> Robert

I thank this thread for putting me onto Pyside +1

[Albert van der Horst]

In article <fe37271c-793d-4018-ac70-6db528270f3e at f30g2000yqa.googlegroups.com>,
Adam Skutt <askutt at gmail.com> wrote:
<SNIP>
>
>Replacing TkInter with some sort of minimized wxwidgets is a dumb idea
>for some very obvious reasons, reasons that are obvious if you simply
>look at a widget gallery and then the applications you run on your own
>computer. Quite honestly, if you're not capable of that, there's
>little reason to believe you'll ever be able to bring forth a
>coherent, cogent proposal.

I really don't follow that. You need a tremendous set to write gimp.
Obviously you won't write gimp in Python.

Now you want to jot together three cooperating screens to specify
some properties for say bluetooth. The proposed set is ample for
that, no?
Such things make up a substantial part of the applications
as far as numbers is concerned. They are probably written by
people who don't want to dive very deeply into GUI.
(Maybe they are more bluetooth experts than GUI-experts, what
would you say?)

>
>Adam

Groetjes Albert

--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert at spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[Adam Skutt]

On Jan 14, 5:17?pm, Albert van der Horst <alb... at spenarnc.xs4all.nl>
wrote:
>
> I really don't follow that. You need a tremendous set to write gimp.
> Obviously you won't write gimp in Python.
>

You need a tremendous set to write /the majority of the applications
on your computer/.

On my desktop right now, I have running:
* Google Chrome
* TweetDeck
* PuTTY
* Pidgin
* Game for Windows Launcher
* Free Download Manager
* Steam Client
* A Windows Control Panel Window

None of those applications could be written with his proposed widget
set, he's literally 0/7 on running applications. If the situation
isn't the same on your computer then your application usage is highly
unusual or you don't understand what widgets are used to construct
your applications. You've just told me that Python would no longer be
suitable for constructing the majority of GUI applications on the
planet.

> Now you want to jot together three cooperating screens to specify
> some properties for say bluetooth. The proposed set is ample for
> that, no?

Yes, but why would I ever do such a thing? Such things are provided
for me by the operating system already, pretty much regardless of
platform. His widget set is quite truly only good for OS utilities,
but I already have those. I generally don't need nor want more of
them. Neither do Python users, because the majority of us aren't
writing OS utilities.

That leaves the logical equivalent of traditional terrible, awful
Visual Basic applications left, and even Microsoft gives them a full
widget set (and "real" programming language) now in VB.NET. The
effort involved in segmentation doesn't make things any easier and
doesn't save them, the library authors, much of anything.

> Such things make up a substantial part of the applications
> as far as numbers is concerned. They are probably written by
> people who don't want to dive very deeply into GUI.
> (Maybe they are more bluetooth experts than GUI-experts, what
> would you say?)
>

I could list every application on the my computer and make a table of
which ones would be workable given the list above, but I can already
tell you that the answer is, "Not very many, and most of the ones that
can were written by MS". And I'm entirely ignoring issues like
theming as well. Adding a few additional layout controls would expand
the list a moderate deal, but that's going to be true pretty much
regardless of which 3 or 4 additional widgets you pick.

And this ignores the obvious, "You'd still need a full WxWidgets
install in order to build the minimized set, so all you've saved is a
few .py files" part of the argument, which is just as compelling, if
not more so.

Really, if you believe the case to be otherwise, I truly believe you
aren't paying attention to your own computer(s), or don't understand
how the applications you use are constructed. What's out there isn't
interesting, it's what people use that's interesting, and people tend
to use GUIs that are moderately to highly complicated.

Adam

[rantingrick]

On Jan 16, 9:18?am, Adam Skutt <ask... at gmail.com> wrote:

> You need a tremendous set to write /the majority of the applications
> on your computer/.

[...snip incessant rambling...]

Adam your post is so incoherent that i cannot decide if you are FOR or
AGAINST changing the current Tkinter GUI module into a wxPython GUI
module. And this widget set that you keep referring to is a bit vague
also. So i will quote myself because i *think* this may be what "it"
referres to...

#######################
# Start Quote by Rick #
#######################
Exactly! All we need to do is replace the existing Tkinter with a
small sub-set of wxPython widgets that mirrors exactly what we have
now...
Toplevel
Label
Entry
Button
Radiobutton
Checkbutton
Canvas
Textbox
Listbox
Menu
Scale
Scrollbar
...thats all you need in the std library "widget wise".
#####################
# End Quote by Rick #
#####################

If you cannot relize that this is exactly what we have now in Tkinter
then you need to go and read the source for Tkinter. Oh hell, i'd
better do it for you. Watch this...

>>> f = open('C:\\Python26\\Lib\\lib-tk\\Tkinter.py')
>>> s = f.read()
>>> f.close()
>>> import re
>>> re.findall(r'class (\w+)\(', s)
['StringVar', 'IntVar', 'DoubleVar', 'BooleanVar', 'Tk', 'BaseWidget',
'Widget', 'Toplevel', 'Button', 'Canvas', 'Checkbutton', 'Entry',
'Frame', 'Label', 'Listbox', 'Menu', 'Menubutton', 'Message',
'Radiobutton', 'Scale', 'Scrollbar', 'Text', 'OptionMenu',
'PhotoImage', 'BitmapImage', 'Spinbox', 'LabelFrame', 'PanedWindow',
'Studbutton', 'Tributton']

Now what seems to be missing from my proposed widget set that hampers
you from re-creating every GUI app on your computer? And just in case
you did not notice "my proposed wxPython module" includes the exact
same widget set. Ok, Ok, i let out image support but in my mind PIL
should handle all of that. The IntVar, StringVar, and BooleanVar
classes are non-applicable in a wx GUI. So just for your sake i shall
"lower the bar of comprehension"...

>>> tkclasses = re.findall(r'class (\w+)\(', s)
>>> omit = ['StringVar', 'IntVar', 'DoubleVar', 'BooleanVar', 'Tk', 'BaseWidget', 'Widget', 'Frame', 'Message', 'OptionMenu', 'LabelFrame', 'PanedWindow', 'Studbutton', 'Tributton']
>>> [x for x in tkclasses if x not in omit]
['Toplevel', 'Button', 'Canvas', 'Checkbutton', 'Entry', 'Label',
'Listbox', 'Menu', 'Menubutton', 'Radiobutton', 'Scale', 'Scrollbar',
'Text', 'PhotoImage', 'BitmapImage', 'Spinbox']

There you have it. The same exact widget set we have now. Sure you
cannot re-create every GUI app on your stinking computer however if
you download the 3rd party wxPython extension module not only will you
be able to re-create every GUI app on your stinking computer it will
wipe your backside too! (psst: "it" refers to wxPython)

i hope you learned something from this exercise Adam.

[Kevin Walzer]

On 1/16/11 11:30 AM, rantingrick wrote:

>
> #######################
> # Start Quote by Rick #
> #######################
> Exactly! All we need to do is replace the existing Tkinter with a
> small sub-set of wxPython widgets that mirrors exactly what we have
> now...
> Toplevel
> Label
> Entry
> Button
> Radiobutton
> Checkbutton
> Canvas
> Textbox
> Listbox
> Menu
> Scale
> Scrollbar
> ...thats all you need in the std library "widget wise".

Rick,

So, after all this discussion, your idea (it's not quite a proposal
since you haven't initiated the PEP process for it) boils down to
replacing Tkinter in the stdlib with a very stripped-down subset of
wxPython?

I'm not quite clear on what this accomplishes. Some of these widgets in
Tkinter are ugly, but they have themed (ttk) equivalents (such as label,
entry, button) that wrap native widgets in a manner similar to wxPython.
So there's no real advantage to wx here.

Your suggestion that developers who want a larger widget set can
download the entire wxPython package is, again, answered by the
observation that numerous Tk extensions, with Tkinter wrappers, exist to
expand the standard Tk widget set. And there are pure-Python extension
packages that are not dependent on binary Tk extensions, cf. Python
Megawidgets. Again, no real advantage to wxPython.

Your initial criticism that Python's standard GUI toolkit should not
dependent on the priorities and development schedule of an outside
project (Tcl/Tk) seems to have gone by the wayside here, because
wxPython is an outside project (led by Robin Dunn) that is in turn
dependent on the timeline of yet another outside project--wxWidgets, the
underlying C++ library.

Finally, there are licensing issues to consider. Tcl/Tk's license is
very liberal, BSD-style, and it is quite similar to Python's. wxWidget's
library is basically LGPL with a couple of exceptions to make it
friendlier to proprietary software. Could code under such a license be
gracefully included in the stlib?

--Kevin
--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

[rantingrick]

On Jan 16, 11:39?am, Kevin Walzer <k... at codebykevin.com> wrote:

First of all welcome back to the discussion Kevin. You and i both
appreciate and use Tkinter extensively and your input is most welcome
here. You are a smart and level headed fella which makes for good
discussion. Thanks for that! Ok, let the battle begin! :-)

> So, after all this discussion, your idea (it's not quite a proposal
> since you haven't initiated the PEP process for it) ?boils down to
> replacing Tkinter in the stdlib with a very stripped-down subset of
> wxPython?

Exactly (almost). However I need to stress that nothing will be lost
to the user when this change happens! On the contrary, much will be
gained. You're going to have the same basic capabilities as you have
now in the stdlib with Tkinter HOWEVER, you can download all the
feature rich goodies that only wx can offer.

> I'm not quite clear on what this accomplishes. Some of these widgets in
> Tkinter are ugly, but they have themed (ttk) equivalents (such as label,
> entry, button) that wrap native widgets in a manner similar to wxPython.
> So there's no real advantage to wx here.

This statement is uninformed Kevin. Wx needs no themed widgets because
the default widgets where created equal from day one. TclTk has always
been behind in look and feel. Yes we do now FINALLY have themed
widgets however this does not make TclTk equal to wxPython in any
shape or form. Kevin i ask that you and everyone else who may be
interested in this community to download the wxPython demo. This demo
(which is a work of art in it's own right!) will be all you need to
understand the vast differences between TclTk and wxPython. You can
get it here...

http://www.wxpython.org/download.php#stable

If for some reason you cannot download this beautiful demo, then at
least look at the awesome screen shots here...

http://www.wxpython.org/screenshots.php


> Your suggestion that developers who want a larger widget set can
> download the entire wxPython package is, again, answered by the
> observation that numerous Tk extensions, with Tkinter wrappers, exist to
> expand the standard Tk widget set. And there are pure-Python extension
> packages that are not dependent on binary Tk extensions, cf. Python
> Megawidgets. Again, no real advantage to wxPython.

Wrong. Even with the hodgepodge of third party downloads and extension
packages Tkinter cannot hold a candle to the professional quality of
wxPython. Again i urge you to at least download the demo and see for
yourself. WxPython is a massive library of almost any widget you can
imagine using in the 21st century. All of the hard work has been done
for you, no need to create your own custom widgets again and again. Do
yourself a favor and download the demo. Here it is again...

http://www.wxpython.org/download.php#stable


> Your initial criticism that Python's standard GUI toolkit should not
> dependent on the priorities and development schedule of an outside
> project (Tcl/Tk) seems to have gone by the wayside here, because
> wxPython is an outside project (led by Robin Dunn) that is in turn
> dependent on the timeline of yet another outside project--wxWidgets, the
> underlying C++ library.

Yes, we will always be at the mercy of another development community
unless we build a real Python GUI. Well newsflash, that dream is not
going to happen because we would need to re-invent the wheel many
times over and not to mention the long bug fix time-line. However
let's get back to reality and compare wxPython to TclTk+Tkinter.

First of all wxPython IS a part of the Python community. They DO care
about Python and Python only. Yes WxWidgets IS NOT part of our
community, however the widget set is so mature that we don't need to
worry about version releases. We could live off the current widget set
unchanged for many years to come!! Compare that to TclTk who only
cares about TclTk and the fact that TclTk is not ANYWHERE near the
maturity of wxPython. With Tkinter we WILL need to update as new
widgets and functionality come into being. Oh did i forget to give
you a link to the beautiful wxDemo, ok here it is...

http://www.wxpython.org/download.php#stable


> Finally, there are licensing issues to consider. Tcl/Tk's license is
> very liberal, BSD-style, and it is quite similar to Python's. wxWidget's
> library is basically LGPL with a couple of exceptions to make it
> friendlier to proprietary software. Could code under such a license be
> gracefully included in the stlib?

Well we need the license lawyers to weigh in on that aspect. If
wxPythons license is weighed and found wanting then we must consider
something else. However, i will tell you that nothing else exists that
can match the maturity, cross-platform, and feature rich-ness of wx.
If someone knows of any such package by all means speak up!

In any event, the time to start looking for something more appropriate
to this community in the 21st century has long passed. We have allowed
Tkinter to rot and grow pungent for the sake of people's "feelings".
Yes, big changes alike this are going to piss off a few folks because
it is human nature to fear change. However i must stress that as
Python 3000 was a difficult --but very necessary change-- so too will
the ushering of a new GUI kit be. But in the the end, we will be a
better community and language for it. But we must start the
transformation now, because transformations take such a looong time!
We have dragged our collective feet long enough!

[Kevin Walzer]

On 1/16/11 1:27 PM, rantingrick wrote:
> On Jan 16, 11:39 am, Kevin Walzer<k... at codebykevin.com> wrote:
>
> First of all welcome back to the discussion Kevin. You and i both
> appreciate and use Tkinter extensively and your input is most welcome
> here. You are a smart and level headed fella which makes for good
> discussion. Thanks for that! Ok, let the battle begin! :-)

Glad to be back.
>
> Wrong. Even with the hodgepodge of third party downloads and extension
> packages Tkinter cannot hold a candle to the professional quality of
> wxPython. Again i urge you to at least download the demo and see for
> yourself. WxPython is a massive library of almost any widget you can
> imagine using in the 21st century. All of the hard work has been done
> for you, no need to create your own custom widgets again and again. Do
> yourself a favor and download the demo. Here it is again...

I'm quite familiar with the wxPython demo. I've got the latest
incarnation, from 2.9.x, installed on my machine. The latest version is
quite nice, especially with the AUI widgets, and the underlying
wxWidgets libraries are finally up-to-date on my Mac as they access the
Cocoa frameworks, rather than the deprecated Carbon frameworks.

However, wxPython does lack some things on my Mac, which I have been
able to implement in Tk. Specifically:

1. My Tkinter apps can access the Mac's Services menu, which provides a
form of inter-application communication that allows one application to
send data to another and have the target application perform some
manipulation of that data. wxPython does not support this feature of the
Mac.

2. Any wxPython application that attempts to display the filesystem on
the Mac looks out-of-place because wx has no support for displaying
native icons on the Mac, though it can display them in Windows. Tk on
the Mac has a few different ways of displaying icons natively.

3. wxPython applications do not make use of common window flags on the
Mac, such as sheets and drawers. Tk provides native support for some of
this, and extension packages provide further support.

So: while wxPython is quite capable of creating handsome applications,
even on the Mac, there are subtle things about wxPython applications
that make them feel not quite native, regardless of how rich the overall
widget set is.

Part of my preference for Tkinter is that, under the hood, Tk is much,
much easier to extend than wxWidgets. I have written several libraries
in Objective-C, using Tk's C API, that hook into various aspects of
native Mac functionality, such as the Services menu. Once this
functionality is accessible from Tk, it's trivial to write a Python
wrapper for it; it's often as easy as 'root.tk.call', 'nativetclcode here'.

As I understand it, extending wxWidgets requires coding in C++, and then
you'd need to run your code through SWIG in some fashion to be able to
access it from wxPython. In short, there are several more steps, and
it's likely more complicated at each step. For various reasons, the
things I think are missing from wxWidgets (native icons, sheets/drawers,
etc.) are not considered important by the core wxWidget developers, or
implementing them is a low priority.

> Well we need the license lawyers to weigh in on that aspect. If
> wxPythons license is weighed and found wanting then we must consider
> something else. However, i will tell you that nothing else exists that
> can match the maturity, cross-platform, and feature rich-ness of wx.
> If someone knows of any such package by all means speak up!

Well, PyQt comes to mind. Qt is better at native Mac implementation than
wx in many respects (window flags, accessing native Mac icons), and
overall it is a richer framework (its support for WebKit is amazing),
but PyQt remains licensed under the GPL, which makes it off-limits for
the stdlib. Plus, there are other Python-Qt implementations out there
(PySide) that may claim some of PyQt's mindshare in the future.

--Kevin

--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

[rantingrick]

On Jan 16, 12:59?pm, Kevin Walzer <k... at codebykevin.com> wrote:

> I'm quite familiar with the wxPython demo. I've got the latest
> incarnation, from 2.9.x, installed on my machine. The latest version is
> quite nice, especially with the AUI widgets, and the underlying
> wxWidgets libraries are finally up-to-date on my Mac as they access the
> Cocoa frameworks, rather than the deprecated Carbon frameworks.

Glad to hear that! :)

> However, wxPython does lack some things on my Mac, which I have been
> able to implement in Tk. Specifically:
>
> 1. My Tkinter apps can access the Mac's Services menu, which provides a
> form of inter-application communication that allows one application to
> send data to another and have the target application perform some
> manipulation of that data. wxPython does not support this feature of the
> Mac.

Ok so you're complaining about a "Mac specific" missing functionality?

> 2. Any wxPython application that attempts to display the filesystem on
> the Mac looks out-of-place because wx has no support for displaying
> native icons on the Mac, though it can display them in Windows. ?Tk on
> the Mac has a few different ways of displaying icons natively.

Ok, even if it looks "out of place" this is another "Mac Specific"
problem.

> 3. wxPython applications do not make use of common window flags on the
> Mac, such as sheets and drawers. Tk provides native support for some of
> this, and extension packages provide further support.

"Mac Specific"

> So: while wxPython is quite capable of creating handsome applications,
> even on the Mac, there are subtle things about wxPython applications
> that make them feel not quite native, regardless of how rich the overall
> widget set is.

I think the moral of this story is simple. Mac decided to implement an
OS that is completely different from the others. Also as you well know
Macs are at the bottom of the stack in terms of popularity. Windows,
Unix, Linix, Mac, in that order. Sure you "may" have the most
pretentious OS on the planet. However you must accept that with a
small user community also comes an equally small developer community.
And even if i give these "minor complaints" 100% merit you still only
have 0.25% of the market you are representing, so you lose the
argument in a big way. Your complaints are but a drop in the
proverbial bucket. But don't fret my friend with wxPython in the
stdlib i'll bet you could persuade or even help to bring Mac support
for these "small" annoyances.

> As I understand it, extending wxWidgets requires coding in C++, and then
> you'd need to run your code through SWIG in some fashion to be able to
> access it from wxPython. In short, there are several more steps, and
> it's likely more complicated at each step. ?For various reasons, the
> things I think are missing from wxWidgets (native icons, sheets/drawers,
> etc.) are not considered important by the core wxWidget developers, or
> implementing them is a low priority.

Well this is something that you need to attack at the source Kevin.
Specifically i mean for you to join the WxWidgets group and start a
grassroots movement for better mac support. Barking about a few small
"annoyances" with an OS that has a "last ranked" standing is a bit
bombastic to say the least. Yes?

> Well, PyQt comes to mind. Qt is better at native Mac implementation than
> wx in many respects (window flags, accessing native Mac icons), and
> overall it is a richer framework (its support for WebKit is amazing),
> but PyQt remains licensed under the GPL, which makes it off-limits for
> the stdlib. Plus, there are other Python-Qt implementations out there
> (PySide) that may claim some of PyQt's mindshare in the future.

I am willing to support any GUI library that will move us forward and
TclTk is dead weight. I like the feature rich nature of wx however i
will consider others if a "compelling" argument is put forward.

[Kevin Walzer]

On 1/16/11 2:44 PM, rantingrick wrote:

>
> Ok so you're complaining about a "Mac specific" missing functionality?

Um, yes.
>
> Ok, even if it looks "out of place" this is another "Mac Specific"
> problem.

Yes, it sure does. "Mac-specific"=="important."
>
>> 3. wxPython applications do not make use of common window flags on the
>> Mac, such as sheets and drawers. Tk provides native support for some of
>> this, and extension packages provide further support.
>
> "Mac Specific"

Ditto.
>

>
> I think the moral of this story is simple. Mac decided to implement an
> OS that is completely different from the others. Also as you well know
> Macs are at the bottom of the stack in terms of popularity. Windows,
> Unix, Linix, Mac, in that order. Sure you "may" have the most
> pretentious OS on the planet. However you must accept that with a
> small user community also comes an equally small developer community.
> And even if i give these "minor complaints" 100% merit you still only
> have 0.25% of the market you are representing, so you lose the
> argument in a big way. Your complaints are but a drop in the
> proverbial bucket. But don't fret my friend with wxPython in the
> stdlib i'll bet you could persuade or even help to bring Mac support
> for these "small" annoyances.

Rick, your statements here are entirely untroubled by facts.:-) First of
all, Mac OS X *is* Unix, at least according to The Open Group, which
controls the UNIX trademark and is actually in charge of certifying an
OS as valid UNIX. Next, in terms of market share, Apple's machines
exceeded 10% of the U.S. market (placing them third in shipments behind
HP and Dell), and run about 4-5% of the market globally. (See
http://bit.ly/cqxl6L.) In any event, it's a bit more than 0.25%.
(Actually, according to http://bit.ly/c4PBlm, Linux comes in at around
0.77%, while Mac OS X comes int around 5%.)

>
> Well this is something that you need to attack at the source Kevin.
> Specifically i mean for you to join the WxWidgets group and start a
> grassroots movement for better mac support. Barking about a few small
> "annoyances" with an OS that has a "last ranked" standing is a bit
> bombastic to say the least. Yes?

I have commit rights to the Tk core, so it's much easier for me to
submit bug fixes and patches there. It's not worth my while to do the
same for wxWidgets.

--Kevin


--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

[Terry Reedy]

On 1/16/2011 1:27 PM, rantingrick wrote:

> least look at the awesome screen shots here...
>
> http://www.wxpython.org/screenshots.php

I did. Well, they say, "Beauty is in the eye of the beholder!". To me,
these are mostly awesomely ugly, ugly, ugly. Shot 1: Ugly gray field
followed by shot2: ugly black on gray. These first two examples look
like Windows 95/8 -- ie, 20th century look, not 21st.

Based on this page, wxwidgets would be a regression from tk. Current
tkinter on Windows looks like it use native Windows windows. IDLE on
WinXP looks like a WinXP app; on Windows 7 it looks like a Windows 7
app. If wxwidgets/wxpython does the same, this page hides it very well.
And this is apparently an update from 'the old Screen shots' page.

The above is based on presented looks. I have no idea whether, to what
extent, and how easily one could duplicate the layout and performance of
the examples with tk. There are, however, other problems with wx that I
have and will point out in other posts.

--
Terry Jan Reedy

[Terry Reedy]

On 1/16/2011 11:30 AM, rantingrick wrote:

> Toplevel
> Label
> Entry
> Button
> Radiobutton
> Checkbutton
> Canvas
> Textbox
> Listbox
> Menu
> Scale
> Scrollbar
> ...thats all you need in the std library "widget wise".

Once IDLE is revised to use some of the widgets in ttk that are not in
tk (such as Notebook) the set would need expansion. But the details of
any such set are irrelevant to the main problems of replacement.

--
Terry Jan Reedy

[rantingrick]

On Jan 16, 12:49?pm, Terry Reedy <tjre... at udel.edu> wrote:

> Once IDLE is revised to use some of the widgets in ttk that are not in
> tk (such as Notebook) the set would need expansion.

The IDLE library has had a NoteBook widget for ages. They just choose
to call it TabPages instead. And what is a NoteBook exactly? Well a
Notebook is a compound widget consisting of a "main frame that holds
two sub frames -- which are a "tab" frame and "pages" frame. When any
"tab" is clicked the page it is linked to is either *raised-to-the-top-
of-the-stack* OR *made-visible* depending on the design. Each "tab"
within the "tab frame" is a Radiobutton. Technically you could even
consider a RadioButton as a compound widget consisting of a button and
a label widget. And one could even dissect further the components of
any such widget however we must stop at some point. The widgets i
outlined are the highest of the lowest you'd want to consider.

I believe compound widgets have no business in the stdlib. When Guido
included Tkinter in the stdlib it was mainly for ease of introductory
GUI programming to the uninitiaed and for batteries included. However
since we do have a "batteries included" mantra we will need to hash
out which compound widgets should be included in the stdlib -- at a
later time! At this time the discussion needs to focus on defending OR
replacing Tkinter with something better. And my position is that we
cannot keep lugging around this ancient TclTk library.

> But the details of
> any such set are irrelevant to the main problems of replacement.

Not exactly. Once a library has been chosen we will need to consider a
small subset for inclusion in the stdlib and ONE large extension
library. So these problems are very relevant -- albeit out of
chronological order.

[Adam Skutt]

On Jan 16, 11:30?am, rantingrick <rantingr... at gmail.com> wrote:

> Adam your post is so incoherent that i cannot decide if you are FOR or
> AGAINST changing the current Tkinter GUI module into a wxPython GUI
> module. And this widget set that you keep referring to is a bit vague
> also.

If you found my post incoherent then you shouldn't be attempting to
respond, you should ask me to fucking clarify! Funny how when I ask
you technical questions you refuse to respond, but when you find my
post incoherent you find plenty of time to attempt to twist my words
to support your own mental masturbation.

> If you cannot relize that this is exactly what we have now in Tkinter
> then you need to go and read the source for Tkinter. Oh hell, i'd
> better do it for you. Watch this...

As I already told you, if you think that what's contained only in
TkInter is relevant or interesting, then you're hopelessly lost. In
fact, you're outright trolling. Python's standard library don't only
include TkInter so only talking about TkInter is entirely
disingenuous.

> Now what seems to be missing from my proposed widget set that hampers
> you from re-creating every GUI app on your computer?

Go download the applications and run them yourself! If you can't
figure it out from a visual examination, you lack the competence to
bring forward your proposal. Being able to identify what widgets are
used to create an application is a fundamental, rudimentary skill. If
you lack that skill, you're tacitly calling all of your credibility
(not that you haven't already done a fine job of demolishing any
assumed credibility on your part) into question.

> Ok, Ok, i let out image support but in my mind PIL
> should handle all of that.

It fundamentally cannot. That's not how image rendering in native
widgets works.

> There you have it. The same exact widget set we have now. Sure you
> cannot re-create every GUI app on your stinking computer however if
> you download the 3rd party wxPython extension module not only will you
> be able to re-create every GUI app on your stinking computer it will
> wipe your backside too! (psst: "it" refers to wxPython)
>

Again, I've already responded to this in detail, in other postings,
posted serious and detailed technical questions, and asked for your
clarifications. So instead of posting the same tired, idiotic tripe,
why don't you go find those postings, read them, and respond to them?
Your refusal and/or inability to do so harms your position immensely.

> i hope you learned something from this exercise Adam.

I'm not the one who needs to learn anything.

Adam

[Steven D'Aprano]

On Sun, 16 Jan 2011 07:18:16 -0800, Adam Skutt wrote:

[...]

I'm afraid I found most of your post hard to interpret, because you
didn't give sufficient context for me to understand it. You refer to "his
proposed widget set", but with no clue as to who he is, or what the
widget set is, or what essential widgets you continue missing. I can
guess "he" is rantingrick, but am not sure -- there's only so much of his
time-wasting I can read before reaching for the killfile. Rantingrick
believes he is doing us a service by haranguing us incessantly into
scratching *his* poorly thought-out itches, regardless of practicality or
actual need.

But putting that aside, I'd like to comment on a few points:

[...]
> If the situation isn't
> the same on your computer then your application usage is highly unusual
> or you don't understand what widgets are used to construct your
> applications. You've just told me that Python would no longer be
> suitable for constructing the majority of GUI applications on the
> planet.

No, that does not follow. Unless "he" (I'll assume it is rantingrick) has
proposed hunting down and destroying all third-party GUI tool sets, what
you've been told is that *one specific* tool set is unsuitable for
constructing the majority of GUI apps.


[...]
> Really, if you believe the case to be otherwise, I truly believe you
> aren't paying attention to your own computer(s), or don't understand how
> the applications you use are constructed. What's out there isn't
> interesting, it's what people use that's interesting, and people tend to
> use GUIs that are moderately to highly complicated.

Well, true, but people tend to *use* the parts of the GUIs that are
simple and basic. Not only do the big complicated apps get all the press
even when they are actually a niche product (everyone knows about
Photoshop, but more people use MS Paint) but it's a truism that most
people use something like 20% of the functionality of big, complicated
GUI apps. Most people use Microsoft Word or OpenOffice for little more
than text editing with formatting.

It's easy for power users to overestimate how much of their complicated
GUIs are actually used by the average user. Or even the *above* average
user.

I suspect that a variation of Zipf's Law probably holds for GUI
complexity -- if you rank the widgets in order of most to least commonly
used, I expect that you'll see actual use drop away rapidly and at an
accelerated rate. E.g. the widget in second place might be used roughly
half as often as the widget in first place place, the widget in third
place one third as often, the widget in fourth place one quarter as
often, and so forth.


--
Steven

[Adam Skutt]

On Jan 16, 6:04?pm, Steven D'Aprano <steve
+comp.lang.pyt... at pearwood.info> wrote:
> > If the situation isn't
> > the same on your computer then your application usage is highly unusual
> > or you don't understand what widgets are used to construct your
> > applications. ?You've just told me that Python would no longer be
> > suitable for constructing the majority of GUI applications on the
> > planet.
>
> No, that does not follow. Unless "he" (I'll assume it is rantingrick) has
> proposed hunting down and destroying all third-party GUI tool sets, what
> you've been told is that *one specific* tool set is unsuitable for
> constructing the majority of GUI apps.
>

If you're going to expect me to be that pedantic, then pay me the
courtesy of taking the time to find the necessary context.
Nevertheless, it's not the least bit unreasonable to address
deficiencies in the standard library as deficiencies in the language,
like it or not; and since rick's proposal involves regressing the
standard library..

> > Really, if you believe the case to be otherwise, I truly believe you
> > aren't paying attention to your own computer(s), or don't understand how
> > the applications you use are constructed. ?What's out there isn't
> > interesting, it's what people use that's interesting, and people tend to
> > use GUIs that are moderately to highly complicated.
>
> Well, true, but people tend to *use* the parts of the GUIs that are
> simple and basic. Not only do the big complicated apps get all the press
> even when they are actually a niche product (everyone knows about
> Photoshop, but more people use MS Paint) but it's a truism that most
> people use something like 20% of the functionality of big, complicated
> GUI apps. Most people use Microsoft Word or OpenOffice for little more
> than text editing with formatting.

First, you can't even build MS Paint from Rick's set / the TkInter set
alone, so you're already way off mark (even ignoring the ribbon in the
latest versions).

Second, relevance? If I cannot ship the application with only 20% of
the functionality, then your point is meaningless. Plus, look at my
list more closely: TweetDeck is really little more than a bunch of
listboxes stuck side by side, but we cannot even construct that
without replicating what would be considered standard widgets (mostlu
layout widgets, but still, that's the hardest stuff to get right and
therefore the most important stuff to include). It is not, from a GUI
L&F perspective, "complicated". Yet, I still need quite a few widgets
in order to assemble it and make it work. And many of those widgets
need fairly rich functionality: buttons must support text and images,
listboxes must support embedding more than text, text controls must
support hyperlinks, the various layout panes must support scrollbars,
sizing, and dynamic updates.

> I suspect that a variation of Zipf's Law probably holds for GUI
> complexity -- if you rank the widgets in order of most to least commonly
> used, I expect that you'll see actual use drop away rapidly and at an
> accelerated rate. E.g. the widget in second place might be used roughly
> half as often as the widget in first place place, the widget in third
> place one third as often, the widget in fourth place one quarter as
> often, and so forth.

Perhaps, but the drop off isn't relevant till we approach well over 30
widgets, at least, quite arguably more (since GUI toolkits include
both things that are common, and things that absolutely suck to
program, even if they're not used often).

Adam

[Owen Jacobson]

On 2010-12-30 19:43:21 -0500, Gerry Reno said:

> For those that are lurking, this might provide a little background:
>
> http://journal.dedasys.com/2010/03/30/where-tcl-and-tk-went-wrong
>
>
>
> Essentially, there is nothing "wrong" with Tcl and Tkinter. They are
> part of a long evolutionary chain of how we got to where we are today.
> They deserve to be respected for the contributions that they have made.
>
> The question now is whether Python needs to evolve its own GUI toolset.

My two cents, given freely: I'd rather have better integration with
each platform's GUI libraries and desktop services than one
cross-platform GUI library. There are so many fundamental differences
in accepted behaviour between each of the major GUI platforms (Gnome,
KDE, Mac OS, and Windows, at minimum; you could include Blackberry,
iOS, and Android in here as well, if you wanted something really
different) that being able to put the same window with the same widgets
on all of them is of limited value.

Consider Java's Swing toolkit - a passable cross-platform GUI library,
whether you like its API or not. Swing apps almost *never* feel as
pleasant to use as a native application, even on modern JVMs where
performance isn't the problem and even using the native look & feel.
Little things like keyboard shortcut conventions, mouse button
conventions, and menu organization guidelines don't quite mesh. Then
there are more complex issues, like process management, library
packaging, software updates, and user notification, where the
conventions on each platform differ more dramatically.

Python's native UI capabilities, on the other hand, give programmers
the tools they need to write the core of their application using
portable code while being able to write a UI (or UIs) that actually
takes advantage of the underlying platform's features and that plays
nicely with the underlying platform's conventions and interfaces - all
without switching languages. I don't see having to maintain two or
three UI codebases as being that much worse than riddling a single UI
codebase with conditionals or extension points for handling each
platform's idiosyncracies.

Fortunately for me and my opinions, Python is already shaped like that.
PyObjC provides bindings for writing OS X applications; PyGTK and PyQt
support Gnome and KDE respectively (as well as any other X11 desktop);
PyWin32 provides passable support for Windows UIs, or you can use
IronPython and .Net's GUI APIs. It is absolutely zero skin off of my
nose if someone decides I'm utterly out of my tree, figures out that
cross-platform GUIs are the future, and goes on to write an amazing
pure-Python GUI stack that works everywhere with a colour monitor.

Cheers,

-o

[Hank Fay]

On Thursday, December 30, 2010 9:59:09 AM UTC-5, kw 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.
>
> --
> Kevin Walzer
> Code by Kevin
> http://www.codebykevin.com

So I thought. Then I came across a framework (Cappucinno.org) and a Visual Designer (280Atlas.com) written entirely in JavaScript (well, Objective-J which gets compiled to JavaScript). Check out 280Slides.com or http://githubissues.heroku.com/#280north/cappuccino for examples of what can be done using JavaScript, and 280Atlas.com for a video of their visual designer. If that designer can be written in JavasScript (it runs on the web, BTW, and only as an after-thought as a desktop app), then it can be done in Python.

Having worked for 20 years in a windows-based development tool that painted controls (giving them fake hwnd's) to get enough speed to run on Windows, this was a real game-changer for me.

Hank

[Kevin Walzer]

On 12/30/10 10:28 AM, Hank Fay wrote:
> On Thursday, December 30, 2010 9:59:09 AM UTC-5, kw 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.
>>
>> --
>> Kevin Walzer
>> Code by Kevin
>> http://www.codebykevin.com
>
> So I thought. Then I came across a framework (Cappucinno.org) and a Visual Designer (280Atlas.com) written entirely in JavaScript (well, Objective-J which gets compiled to JavaScript). Check out 280Slides.com or http://githubissues.heroku.com/#280north/cappuccino for examples of what can be done using JavaScript, and 280Atlas.com for a video of their visual designer. If that designer can be written in JavasScript (it runs on the web, BTW, and only as an after-thought as a desktop app), then it can be done in Python.
>
> Having worked for 20 years in a windows-based development tool that painted controls (giving them fake hwnd's) to get enough speed to run on Windows, this was a real game-changer for me.
>
> Hank
>
Yes, this is slick, and it looks nearly native, but, um...it's still
running inside a browser. It's not a desktop app.

--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

[Stefan Behnel]

rantingrick, 30.12.2010 00:58:
> So what should we do?
> ------------------------
> The answer is simple. We need a 100% Python GUI. A GUI coded in Python
> from top to bottom. A GUI that is cross platform to the big three
> (Windows, Linux, and Mac). A GUI that not only is easy as Tkinter but
> also a GUI that can be manipulated by the average python programmer. A
> GUI that not only teaches the fundamentals of using a GUI, but also a
> GUI that teaches how a GUI works under the hood

I hope you invested as much time into writing this "expose" as you did
searching the web before writing it.

http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/

(the site is currently broken for me, you can use the following instead:

http://webcache.googleusercontent.com/search?q=cache:WsGrJKw6ABoJ:www.cosc.canterbury.ac.nz/greg.ewing/python_gui/

Stefan

[Kevin Walzer]

On 12/30/10 10:52 AM, Stefan Behnel wrote:
> rantingrick, 30.12.2010 00:58:
>> So what should we do?
>> ------------------------
>> The answer is simple. We need a 100% Python GUI. A GUI coded in Python
>> from top to bottom. A GUI that is cross platform to the big three
>> (Windows, Linux, and Mac). A GUI that not only is easy as Tkinter but
>> also a GUI that can be manipulated by the average python programmer. A
>> GUI that not only teaches the fundamentals of using a GUI, but also a
>> GUI that teaches how a GUI works under the hood
>
> I hope you invested as much time into writing this "expose" as you did
> searching the web before writing it.
>
> http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/
>
> (the site is currently broken for me, you can use the following instead:
>
> http://webcache.googleusercontent.com/search?q=cache:WsGrJKw6ABoJ:www.cosc.canterbury.ac.nz/greg.ewing/python_gui/

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.
--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

[rantingrick]

On Dec 30, 10:02?am, Kevin Walzer <k... at codebykevin.com> wrote:

> >http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/

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


hmm. And what is Tkinter exactly? And more importantly how is it
better than pyGUI (design wise)? And even more importanly, how will it
be better in the long run? Is this just more FUD Kevin "Gates"?

[Robert]

On 2010-12-30 13:04:19 -0500, rantingrick said:

> On Dec 30, 10:02?am, Kevin Walzer <k... at codebykevin.com> wrote:
>
>>> http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/
>
>> 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.
>
>
> hmm. And what is Tkinter exactly? And more importantly how is it
> better than pyGUI (design wise)? And even more importanly, how will it
> be better in the long run? Is this just more FUD Kevin "Gates"?

I am sorry, are you always an inconsiderate idiot? That is exactly what
you are coming across as.

--
Robert

[rantingrick]

On Dec 30, 9:52?am, Stefan Behnel <stefan... at behnel.de> wrote:

> I hope you invested as much time into writing this "expose" as you did
> searching the web before writing it.

And ditto to you. If you would have followed the thread so far, in my
second post i said...

"""However i need to stress that my intention is towards a 100% Python
GUI. Not a binding, not a wrapping (except for OS calls!) but a *real*
Python GUI. The only thing that i know of at this point is pyGUI
although there are probably others."""[198:203]

[Stefan Behnel]

rantingrick, 30.12.2010 17:02:
> On Dec 30, 9:52 am, Stefan Behnel wrote:
>
>> I hope you invested as much time into writing this "expose" as you did
>> searching the web before writing it.
>
> in my second post i said...
>
> """However i need to stress that my intention is towards a 100% Python
> GUI. Not a binding, not a wrapping (except for OS calls!) but a *real*
> Python GUI. The only thing that i know of at this point is pyGUI
> although there are probably others."""

Sure, fine, just making sure you know the terrain. If that's not enough for
you, you should follow Steven's advice to get started implementing
something, because this may become a lengthy undertaking.

Stefan

[Robert]

On 2010-12-30 11:02:46 -0500, rantingrick said:

> On Dec 30, 9:52?am, Stefan Behnel <stefan... at behnel.de> wrote:
>
>> I hope you invested as much time into writing this "expose" as you did
>> searching the web before writing it.
>
> And ditto to you. If you would have followed the thread so far, in my
> second post i said...
>
> """However i need to stress that my intention is towards a 100% Python
> GUI. Not a binding, not a wrapping (except for OS calls!) but a *real*
> Python GUI. The only thing that i know of at this point is pyGUI
> although there are probably others."""[198:203]

Good luck with that.

--
Robert

[Hank Fay]

That (the desktop app issue) was the big game-change for me. It looks like a desktop app, it acts like a desktop app, and our enterprise customers would be delighted to a) have no installs to do for fat clients; or b) not have to run a TS or Citrix farm.

[Octavian Rasnita]

From: "Hank Fay" <hankfay at gmail.com>
Subject: Re: Tkinter: The good, the bad, and the ugly!

> That (the desktop app issue) was the big game-change for me. It looks like a desktop app, it acts like a desktop app, and our enterprise customers would be delighted to a) have no installs to do for fat clients; or b) not have to run a TS or Citrix farm.
>


It looks like a desktop app, but it doesn't fully act like a desktop app.

Not all the computer users are using a mouse and not all of them can see, but the good desktop apps are very accessible for those users who can't do those things.

Octavian

[Adam Skutt]

On Friday, December 31, 2010 9:56:02 PM UTC-5, Robert H wrote:
> It was forked to be written in Python, yes. The whole point (and it
> wasn't a Nagios port to Tcl) was that the Tcl community (and I like the
> Tcl community a lot) has a strange fixation with not reinventing the
> wheel, even when the wheel would be in Tcl and it might give Tcl more
> exposure. It is what it is though.
>
> --

Perhaps because they'd rather do something useful with the tool they've created instead of trying to win some sort of nonexistent popularity contest? What value would there be in that?

Not trying to reinvent the wheel whenever feasible is both good programming and good engineering most of the time. Unfortunately, the fact you see this as irksome only paints you in a negative light.

Adam

[Robert]

On 2010-12-31 23:57:24 -0500, Adam Skutt said:

> On Friday, December 31, 2010 9:56:02 PM UTC-5, Robert H wrote:
>> It was forked to be written in Python, yes. The whole point (and it
>> wasn't a Nagios port to Tcl) was that the Tcl community (and I like the
>> Tcl community a lot) has a strange fixation with not reinventing the
>> wheel, even when the wheel would be in Tcl and it might give Tcl more
>> exposure. It is what it is though.
>>
>> --
>
> Perhaps because they'd rather do something useful with the tool they've
> created instead of trying to win some sort of nonexistent popularity
> contest? What value would there be in that?
>
> Not trying to reinvent the wheel whenever feasible is both good
> programming and good engineering most of the time. Unfortunately, the
> fact you see this as irksome only paints you in a negative light.
>
> Adam

Right, just because you say it paints me in a negative light. Look at
every language out there and look within the groups. Everyone is trying
to revinvent the wheel to (in their view) make it better. Your argument
is sad to me.

--
Robert

[Adam Skutt]

On Friday, December 31, 2010 9:56:02 PM UTC-5, Robert H wrote:
> It was forked to be written in Python, yes. The whole point (and it
> wasn't a Nagios port to Tcl) was that the Tcl community (and I like the
> Tcl community a lot) has a strange fixation with not reinventing the
> wheel, even when the wheel would be in Tcl and it might give Tcl more
> exposure. It is what it is though.
>
> --

Perhaps because they'd rather do something useful with the tool they've created instead of trying to win some sort of nonexistent popularity contest? What value would there be in that?

Not trying to reinvent the wheel whenever feasible is both good programming and good engineering most of the time. Unfortunately, the fact you see this as irksome only paints you in a negative light.

Adam

[Adam Skutt]

On Saturday, January 1, 2011 10:00:06 AM UTC-5, Robert H wrote:
>
> Right, just because you say it paints me in a negative light. Look at
> every language out there and look within the groups. Everyone is trying
> to revinvent the wheel to (in their view) make it better.

"Everyone" is doing nothing of the sort, hence why Tcl "irks" you. Or are you so forgetful that you can't even remember what you said a few days ago?

> Your argument is sad to me.

At least I've made an argument, whereas you've done nothing of the sort. Just because you take wheel reinvention == good as a tautology doesn't mean everyone else does. Again, what point is there in attempting to win a non-existent popularity contest?

Adam

[Robert]

On 2011-01-01 10:34:46 -0500, Adam Skutt said:

> On Saturday, January 1, 2011 10:00:06 AM UTC-5, Robert H wrote:
>>
>> Right, just because you say it paints me in a negative light. Look at
>> every language out there and look within the groups. Everyone is trying
>> to revinvent the wheel to (in their view) make it better.
>
> "Everyone" is doing nothing of the sort, hence why Tcl "irks" you. Or
> are you so forgetful that you can't even remember what you said a few
> days ago?

Really? How many templating systems does Python have? More than one?
Why is that? How many web frameworks does Perl have? More than one? Why
is that?

Why *was* Nagios forked and re-written in Python?

There are too many examples to count.

>
>> Your argument is sad to me.
>
> At least I've made an argument, whereas you've done nothing of the
> sort. Just because you take wheel reinvention == good as a tautology
> doesn't mean everyone else does. Again, what point is there in
> attempting to win a non-existent popularity contest?
>
> Adam

Just gave you a bunch. You have totally missed the whole point of the
original argument. Nice job. Done with you now.

--
Robert

[Robert]

On 2011-01-01 10:34:46 -0500, Adam Skutt said:

> On Saturday, January 1, 2011 10:00:06 AM UTC-5, Robert H wrote:
>>
>> Right, just because you say it paints me in a negative light. Look at
>> every language out there and look within the groups. Everyone is trying
>> to revinvent the wheel to (in their view) make it better.
>
> "Everyone" is doing nothing of the sort, hence why Tcl "irks" you. Or
> are you so forgetful that you can't even remember what you said a few
> days ago?
>
>> Your argument is sad to me.
>
> At least I've made an argument, whereas you've done nothing of the
> sort. Just because you take wheel reinvention == good as a tautology
> doesn't mean everyone else does. Again, what point is there in
> attempting to win a non-existent popularity contest?
>
> Adam

I want to apologize for my part. We just aren't going to see the same
side of this.

--
Robert

[Adam Skutt]

On Jan 1, 6:21?pm, Robert <sigz... at gmail.com> wrote:
>
> Really? How many templating systems does Python have? More than one?
> Why is that? How many web frameworks does Perl have? More than one? Why
> is that?
>
> Why *was* Nagios forked and re-written in Python?
>
> There are too many examples to count.
>

You're missing the point: you've yet to provide any sort of argument
whatsoever. It's not automatically true that rewriting Nagios in Tcl
would gain the Tcl community more exposure, nor is it automatically
true that more exposure is a good or desirable thing.

You first have to show how rewriting Nagios in Tcl would gain them
more exposure. Then you have to show that the exposure would be a
good thing. Until you've done both, you're arguing with very
fundamental and conventional engineering wisdom; and you have not
actually presented an argument just tautologies.

Neither will be easy to prove, by and by large, most people don't give
a shit what language their applications are written in and rightly so.

> Just gave you a bunch.

No, you've given me examples of wheel reinvention. Just because the
people reinventing the wheel thought it was a good thing doesn't
actually make it so. You personally have to present the case as to
why it is a good thing.

> I want to apologize for my part. We just aren't going to see the same
> side of this.

You can apologize, but I don't accept it. You want to actually
apologize? Admit you were wrong and retract, or act like an adult and
present an actual argument instead of wasting time.

Adam

[Adam Skutt]

On Saturday, January 1, 2011 10:00:06 AM UTC-5, Robert H wrote:
>
> Right, just because you say it paints me in a negative light. Look at
> every language out there and look within the groups. Everyone is trying
> to revinvent the wheel to (in their view) make it better.

"Everyone" is doing nothing of the sort, hence why Tcl "irks" you. Or are you so forgetful that you can't even remember what you said a few days ago?

> Your argument is sad to me.

At least I've made an argument, whereas you've done nothing of the sort. Just because you take wheel reinvention == good as a tautology doesn't mean everyone else does. Again, what point is there in attempting to win a non-existent popularity contest?

Adam