WxPython versus Tkinter (A code battle to the death!)

by Rick Johnson.

I have in many threads declared that Tkinter (and TclTk) is currently
--and has been for a decade-- the wrong choice for Python's stdlib
GUI. Throughout the 90's Tkinter was fine. However we have been in the
21st century for more than a decade and Tkinter is no longer relevant.
Many people have argued (weakly) that Tkinter is still valid. However
their arguments have been mostly baseless opinions that sadly lack
vision for the future.

In this thread i intend to slay my enemies with cold hard facts based
on code. It is time to put your code where your mouth is (or you
foot). This will be an open challenge to *anyone* in this community,
in the world, and *even* the great Guido van Rossum himself! It is now
time for you (python community) to prove the worth of Tkinter or
accept its demise at my hands!

Some of you may think this sounds like an impossible challenge. How
can one man defend his position against the entire world! Yes, it
would seem impossible for one man to face an entire community in open
challenge! And in most cases only a fool would challenge the world.
However, i have not one ounce of fear within me while facing these
odds because my position is the correct position. My position is based
on facts and NOT friendship, truth and NOT tantrums, and finally
vision NOT vengance! I am on the correct side of history!

It is time to prove once and for all how dated and worthless Tkinter
is compared to wxPython. Yes, WxPython is not as advanced as i would
like it to be for a 21st century GUI library. However compared to
Tkinter, Wx is light years ahead! Wx is our best hope to move Python
into the 21st century.

So now is the time for all you naysayers, trolls, and minions to face
me in mortal combat within the arena of truth and righteousness. Ready
your minds and wield your text editors for we shall battle for the
glory of Python! And when i have slayed the fools with their own
foolishness then ye all shall be enlightened!

So PUT UP OR SHUT THE HELL UP!


---------------------------------------
 Challenge 1: (Simple Directory Viewer)
---------------------------------------

Create a simple Directory Viewer GUI. You CANNOT use a treectrl!  The
point of this challenge is to show that Tkinter has no support for a
true ListCtrl widget. However the Wx::ListCtrl is fully featured! For
wxPython the code is simply wielding a few built in classes. For
Tkinter no such ListCtrl functionality exists. You CAN create the
functionality yourself (and i know this because i HAVE created it!)
however it involves tons of work and still can't hold a candle to the
wx::ListCtrl

---------------
 Requirements:
---------------

How the user navigates to a folder is not important but you must
display the list of files/folders in two view modes with icons;

 1. Display files in both ReportView and ListView.

  * Reportview:
    ...scrollable vertical list with three columns.

  * Listview:
    ...scrollable horizontal-ly wrapping list.

Note: If you do not understand the view modes just run my code for an
example. But the user must be able to switch between these two modes
easily. How the switching is done is unimportant -- I simply used two
buttons.

 2. Columns
  * Minimum of three cols; Name, Size, and Type (reportview).
  * the "Name" column must include an icon AND label (both views).
  * columns must be sortable by the user (reportview).
  * columns must be sizable by the user (reportview).

 3. Items
  * All must be editable in place (no popup editing allowed!).
  * All items must be selectable/deselectable by user.
  * All items must be delete-able by the user.

That is the challenge. Step forth and battle if you can!

-----------------
 WxPython code:
-----------------

https://sites.google.com/site/thefutureofpython/home/code-challenges


I await any challengers...

On 1/22/2011 7:07 PM, rantingrick wrote:

Near the beginning of this thread, I gently challenged you to produce a 
concrete, practical proposal for an stdlib addition that could be 
critiqued and improved. When you asked for problems with 
wxwidgets/wxpython, I gave some. Still waiting.

> So PUT UP OR SHUT THE HELL UP!

-- 
Terry Jan Reedy

From: "rantingrick" <rantingrick@gmail.com>
>=20
> WxPython versus Tkinter (A code battle to the death!)
>=20
> by Rick Johnson.
>=20
> I have in many threads declared that Tkinter (and TclTk) is currently
> --and has been for a decade-- the wrong choice for Python's stdlib
> GUI. Throughout the 90's Tkinter was fine. However we have been in the
> 21st century for more than a decade and Tkinter is no longer relevant.
> Many people have argued (weakly) that Tkinter is still valid. However
> their arguments have been mostly baseless opinions that sadly lack
> vision for the future.
>=20
> In this thread i intend to slay my enemies with cold hard facts based
> on code. It is time to put your code where your mouth is (or you
> foot). This will be an open challenge to *anyone* in this community,
> in the world, and *even* the great Guido van Rossum himself! It is now
> time for you (python community) to prove the worth of Tkinter or
> accept its demise at my hands!
>=20
> Some of you may think this sounds like an impossible challenge. How
> can one man defend his position against the entire world! Yes, it
> would seem impossible for one man to face an entire community in open
> challenge! And in most cases only a fool would challenge the world.
> However, i have not one ounce of fear within me while facing these
> odds because my position is the correct position. My position is based
> on facts and NOT friendship, truth and NOT tantrums, and finally
> vision NOT vengance! I am on the correct side of history!
>=20
> It is time to prove once and for all how dated and worthless Tkinter
> is compared to wxPython. Yes, WxPython is not as advanced as i would
> like it to be for a 21st century GUI library. However compared to
> Tkinter, Wx is light years ahead! Wx is our best hope to move Python
> into the 21st century.
>=20
> So now is the time for all you naysayers, trolls, and minions to face
> me in mortal combat within the arena of truth and righteousness. Ready
> your minds and wield your text editors for we shall battle for the
> glory of Python! And when i have slayed the fools with their own
> foolishness then ye all shall be enlightened!
>=20
> So PUT UP OR SHUT THE HELL UP!
>=20
>=20
> ---------------------------------------
> Challenge 1: (Simple Directory Viewer)
> ---------------------------------------
>=20
> Create a simple Directory Viewer GUI. You CANNOT use a treectrl!  The
> point of this challenge is to show that Tkinter has no support for a
> true ListCtrl widget. However the Wx::ListCtrl is fully featured! For
> wxPython the code is simply wielding a few built in classes. For
> Tkinter no such ListCtrl functionality exists. You CAN create the
> functionality yourself (and i know this because i HAVE created it!)
> however it involves tons of work and still can't hold a candle to the
> wx::ListCtrl
>=20
> ---------------
> Requirements:
> ---------------
>=20
> How the user navigates to a folder is not important but you must
> display the list of files/folders in two view modes with icons;
>=20
> 1. Display files in both ReportView and ListView.
>=20
>  * Reportview:
>    ...scrollable vertical list with three columns.
>=20
>  * Listview:
>    ...scrollable horizontal-ly wrapping list.
>=20
> Note: If you do not understand the view modes just run my code for an
> example. But the user must be able to switch between these two modes
> easily. How the switching is done is unimportant -- I simply used two
> buttons.
>=20
> 2. Columns
>  * Minimum of three cols; Name, Size, and Type (reportview).
>  * the "Name" column must include an icon AND label (both views).
>  * columns must be sortable by the user (reportview).
>  * columns must be sizable by the user (reportview).
>=20
> 3. Items
>  * All must be editable in place (no popup editing allowed!).
>  * All items must be selectable/deselectable by user.
>  * All items must be delete-able by the user.
>=20
> That is the challenge. Step forth and battle if you can!
>=20
> -----------------
> WxPython code:
> -----------------
>=20
> https://sites.google.com/site/thefutureofpython/home/code-challenges



I have downloaded that simple program, launched it, and I've tested it =
with JAWS screen reader.
It was fully accessible out of the box.

Have you done something special for making it accessible for screen =
readers? (I guess not).

Can be the same thing done with Tkinter?

Octavian

rantingrick, 23.01.2011 01:07:
> I have in many threads declared that Tkinter (and TclTk) is currently
> --and has been for a decade-- the wrong choice for Python's stdlib
> GUI.  [...]
> It is time to prove once and for all how dated and worthless Tkinter
> is compared to wxPython.

What's the aim of that prove? If you are trying to pave the ground for 
getting wxPython in the stdlib instead of tkinter, I think that's bound to 
fail. Similar proposals have been rejected with the simple argument that 
adding a large library with a huge C dependency to the standard library 
without having a rock solid maintainer for both of them is not going to happen.

Are you volunteering to maintain both wxPython and wxWidgets in the 
standard library for, say, twenty years to come?

Stefan

On Jan 23, 5:07=A0am, rantingrick <rantingr...@gmail.com> wrote:
> WxPython versus Tkinter (A code battle to the death!)
>
> by Rick Johnson.
>
> I have in many threads declared that Tkinter (and TclTk) is currently
> --and has been for a decade-- the wrong choice for Python's stdlib
> GUI. Throughout the 90's Tkinter was fine. However we have been in the
> 21st century for more than a decade and Tkinter is no longer relevant.
> Many people have argued (weakly) that Tkinter is still valid. However
> their arguments have been mostly baseless opinions that sadly lack
> vision for the future.
>
> In this thread i intend to slay my enemies with cold hard facts based
> on code. It is time to put your code where your mouth is (or you
> foot). This will be an open challenge to *anyone* in this community,
> in the world, and *even* the great Guido van Rossum himself! It is now
> time for you (python community) to prove the worth of Tkinter or
> accept its demise at my hands!
>
> Some of you may think this sounds like an impossible challenge. How
> can one man defend his position against the entire world! Yes, it
> would seem impossible for one man to face an entire community in open
> challenge! And in most cases only a fool would challenge the world.
> However, i have not one ounce of fear within me while facing these
> odds because my position is the correct position. My position is based
> on facts and NOT friendship, truth and NOT tantrums, and finally
> vision NOT vengance! I am on the correct side of history!
>
> It is time to prove once and for all how dated and worthless Tkinter
> is compared to wxPython. Yes, WxPython is not as advanced as i would
> like it to be for a 21st century GUI library. However compared to
> Tkinter, Wx is light years ahead! Wx is our best hope to move Python
> into the 21st century.
>
> So now is the time for all you naysayers, trolls, and minions to face
> me in mortal combat within the arena of truth and righteousness. Ready
> your minds and wield your text editors for we shall battle for the
> glory of Python! And when i have slayed the fools with their own
> foolishness then ye all shall be enlightened!
>
> So PUT UP OR SHUT THE HELL UP!
>
> ---------------------------------------
> =A0Challenge 1: (Simple Directory Viewer)
> ---------------------------------------
>
> Create a simple Directory Viewer GUI. You CANNOT use a treectrl! =A0The
> point of this challenge is to show that Tkinter has no support for a
> true ListCtrl widget. However the Wx::ListCtrl is fully featured! For
> wxPython the code is simply wielding a few built in classes. For
> Tkinter no such ListCtrl functionality exists. You CAN create the
> functionality yourself (and i know this because i HAVE created it!)
> however it involves tons of work and still can't hold a candle to the
> wx::ListCtrl
>
> ---------------
> =A0Requirements:
> ---------------
>
> How the user navigates to a folder is not important but you must
> display the list of files/folders in two view modes with icons;
>
> =A01. Display files in both ReportView and ListView.
>
> =A0 * Reportview:
> =A0 =A0 ...scrollable vertical list with three columns.
>
> =A0 * Listview:
> =A0 =A0 ...scrollable horizontal-ly wrapping list.
>
> Note: If you do not understand the view modes just run my code for an
> example. But the user must be able to switch between these two modes
> easily. How the switching is done is unimportant -- I simply used two
> buttons.
>
> =A02. Columns
> =A0 * Minimum of three cols; Name, Size, and Type (reportview).
> =A0 * the "Name" column must include an icon AND label (both views).
> =A0 * columns must be sortable by the user (reportview).
> =A0 * columns must be sizable by the user (reportview).
>
> =A03. Items
> =A0 * All must be editable in place (no popup editing allowed!).
> =A0 * All items must be selectable/deselectable by user.
> =A0 * All items must be delete-able by the user.
>
> That is the challenge. Step forth and battle if you can!
>
> -----------------
> =A0WxPython code:
> -----------------
>
> https://sites.google.com/site/thefutureofpython/home/code-challenges
>
> I await any challengers...

Tried the code with debian sid and default python (2.6)

I get (after some loading... statements)

Segmentation fault

[Actually this is the first time in my 10 years of python that Ive
seen a pure python module segfault :-) ]

On Sun, 23 Jan 2011 02:18:34 -0800, rusi wrote:

>>  WxPython code:
[...] 
> Tried the code with debian sid and default python (2.6)
> 
> I get (after some loading... statements)
> 
> Segmentation fault
> 
> [Actually this is the first time in my 10 years of python that Ive seen
> a pure python module segfault :-) ]

wxPython is a front end to the wxWidgets (formerly wxWindows) toolkit, 
which is C++. I imagine that's what seg faulted.



-- 
Steven

On Jan 22, 7:07=A0pm, rantingrick <rantingr...@gmail.com> wrote:
> So PUT UP OR SHUT THE HELL UP!

You first.  Write actual working code first and then you can challenge
people. I found 5 bugs in your code before I quit looking[1].  Can you
find and fix them all?  Also, I'm entirely ignoring the bad styling,
bad default sizing, horrible UI, the fact you call rename "Edit", and
the fact the context menu doesn't do anything.  All of the are
legitimate technical errors, i.e., you coded the program wrong.

In the spirit of community I open the bug finding to everyone, but
humbly ask you don't tell Mr. "rantingrick" Johnson about them.  It
can be our little secret ;)

Adam

[1] I think there might even be more, but I got lazy.

On Jan 22, 9:39=A0pm, Terry Reedy <tjre...@udel.edu> wrote:
> On 1/22/2011 7:07 PM, rantingrick wrote:
>
> Near the beginning of this thread, I gently challenged you to produce a
> concrete, practical proposal for an stdlib addition that could be
> critiqued and improved. When you asked for problems with
> wxwidgets/wxpython, I gave some. Still waiting.

You may have done this however i do not remember. With all the
trolling that was going on (not you) i may have missed it.

On Jan 23, 1:53=A0am, "Octavian Rasnita" <orasn...@gmail.com> wrote:

> I have downloaded that simple program, launched it, and I've tested it wi=
th JAWS screen reader.
> It was fully accessible out of the box.

Excellent!

> Have you done something special for making it accessible for screen reade=
rs? (I guess not).

I did nothing to make the code more accessible, that is just another
great attribute of 21st cenury GUI libraries.

> Can be the same thing done with Tkinter?

Not that i am aware of.

rantingrick schrieb:

[snip]

1. You cannot define the terms--restrict your opponent--
    and battle it yourselves.
2. Your specified directory browser is useless.
    --At least define that the directory browser must have
      constant complexity to work with volatile
      data over a network...

-roger

On Jan 23, 4:18=A0am, rusi <rustompm...@gmail.com> wrote:
> On Jan 23, 5:07=A0am, rantingrick <rantingr...@gmail.com> wrote:
>
>
>
>
>
>
>
>
>
> > WxPython versus Tkinter (A code battle to the death!)
>
> > by Rick Johnson.
>
> > I have in many threads declared that Tkinter (and TclTk) is currently
> > --and has been for a decade-- the wrong choice for Python's stdlib
> > GUI. Throughout the 90's Tkinter was fine. However we have been in the
> > 21st century for more than a decade and Tkinter is no longer relevant.
> > Many people have argued (weakly) that Tkinter is still valid. However
> > their arguments have been mostly baseless opinions that sadly lack
> > vision for the future.
>
> > In this thread i intend to slay my enemies with cold hard facts based
> > on code. It is time to put your code where your mouth is (or you
> > foot). This will be an open challenge to *anyone* in this community,
> > in the world, and *even* the great Guido van Rossum himself! It is now
> > time for you (python community) to prove the worth of Tkinter or
> > accept its demise at my hands!
>
> > Some of you may think this sounds like an impossible challenge. How
> > can one man defend his position against the entire world! Yes, it
> > would seem impossible for one man to face an entire community in open
> > challenge! And in most cases only a fool would challenge the world.
> > However, i have not one ounce of fear within me while facing these
> > odds because my position is the correct position. My position is based
> > on facts and NOT friendship, truth and NOT tantrums, and finally
> > vision NOT vengance! I am on the correct side of history!
>
> > It is time to prove once and for all how dated and worthless Tkinter
> > is compared to wxPython. Yes, WxPython is not as advanced as i would
> > like it to be for a 21st century GUI library. However compared to
> > Tkinter, Wx is light years ahead! Wx is our best hope to move Python
> > into the 21st century.
>
> > So now is the time for all you naysayers, trolls, and minions to face
> > me in mortal combat within the arena of truth and righteousness. Ready
> > your minds and wield your text editors for we shall battle for the
> > glory of Python! And when i have slayed the fools with their own
> > foolishness then ye all shall be enlightened!
>
> > So PUT UP OR SHUT THE HELL UP!
>
> > ---------------------------------------
> > =A0Challenge 1: (Simple Directory Viewer)
> > ---------------------------------------
>
> > Create a simple Directory Viewer GUI. You CANNOT use a treectrl! =A0The
> > point of this challenge is to show that Tkinter has no support for a
> > true ListCtrl widget. However the Wx::ListCtrl is fully featured! For
> > wxPython the code is simply wielding a few built in classes. For
> > Tkinter no such ListCtrl functionality exists. You CAN create the
> > functionality yourself (and i know this because i HAVE created it!)
> > however it involves tons of work and still can't hold a candle to the
> > wx::ListCtrl
>
> > ---------------
> > =A0Requirements:
> > ---------------
>
> > How the user navigates to a folder is not important but you must
> > display the list of files/folders in two view modes with icons;
>
> > =A01. Display files in both ReportView and ListView.
>
> > =A0 * Reportview:
> > =A0 =A0 ...scrollable vertical list with three columns.
>
> > =A0 * Listview:
> > =A0 =A0 ...scrollable horizontal-ly wrapping list.
>
> > Note: If you do not understand the view modes just run my code for an
> > example. But the user must be able to switch between these two modes
> > easily. How the switching is done is unimportant -- I simply used two
> > buttons.
>
> > =A02. Columns
> > =A0 * Minimum of three cols; Name, Size, and Type (reportview).
> > =A0 * the "Name" column must include an icon AND label (both views).
> > =A0 * columns must be sortable by the user (reportview).
> > =A0 * columns must be sizable by the user (reportview).
>
> > =A03. Items
> > =A0 * All must be editable in place (no popup editing allowed!).
> > =A0 * All items must be selectable/deselectable by user.
> > =A0 * All items must be delete-able by the user.
>
> > That is the challenge. Step forth and battle if you can!
>
> > -----------------
> > =A0WxPython code:
> > -----------------
>
> >https://sites.google.com/site/thefutureofpython/home/code-challenges
>
> > I await any challengers...
>
> Tried the code with debian sid and default python (2.6)
>
> I get (after some loading... statements)
>
> Segmentation fault
>
> [Actually this is the first time in my 10 years of python that Ive
> seen a pure python module segfault :-) ]

Congratulations genius! However if you are really smart you would have
read the note in the source that says "tested on windows only!".
Segfault. Thanks for the laugh!

On Jan 23, 7:35=A0am, Adam Skutt <ask...@gmail.com> wrote:
> On Jan 22, 7:07=A0pm, rantingrick <rantingr...@gmail.com> wrote:

> You first. =A0Write actual working code first and then you can challenge
> people.

The code does work. You just lack the skill to run it.

> I found 5 bugs in your code before I quit looking[1].

What are these "so-called" bugs exactly? Remember this code is not
meant to WOW anyone. It is a challenge to anybody who can reproduce
the same functionality in Tkinter. The main point is to create a
ListCtrl that has two view modes, icons, and editable items. You lack
simple reading and comprehension skills Adam.

> Can you
> find and fix them all? =A0Also, I'm entirely ignoring the bad styling,

This is not a challenge about code styling.

> bad default sizing,

This is not a challenge about pretty GUIs.

>  horrible UI, the fact you call rename "Edit",

pedantic troll!

>  and
> the fact the context menu doesn't do anything.

THIS IS A SIMPLE EXAMPLE FILE VIEWER. We don't to actually rename and
delete files you moron. Get a life.

Adam you were one of the biggest trolls in the "other" thread. We
don't need you trolling up this one too. Can you write any code? I
have produced code and no one has offered a rebuttal using the Tkinter
module. This is because only a handful of the entire community has the
skills to create something like this with Tkinter. I am one of them,
Kevin is another, Guido is another, and there are a very few more.
HOWEVER YOU ARE NOT IN THIS GROUP ADAM. You are a troll, and that is
all you can do. Prove me wrong if you can...

On Jan 23, 4:10=A0am, Stefan Behnel <stefan...@behnel.de> wrote:
> rantingrick, 23.01.2011 01:07:
>
> > I have in many threads declared that Tkinter (and TclTk) is currently
> > --and has been for a decade-- the wrong choice for Python's stdlib
> > GUI. =A0[...]
> > It is time to prove once and for all how dated and worthless Tkinter
> > is compared to wxPython.
>
> What's the aim of that prove? If you are trying to pave the ground for
> getting wxPython in the stdlib instead of tkinter, I think that's bound t=
o
> fail. Similar proposals have been rejected with the simple argument that
> adding a large library with a huge C dependency to the standard library
> without having a rock solid maintainer for both of them is not going to h=
appen.

Wait a minute, i am confused? What language is Python written in? Oh
thats right Lisp! I am so dumb. How did i even get this job? :-)

> Are you volunteering to maintain both wxPython and wxWidgets in the
> standard library for, say, twenty years to come?

WxPython needs lots of proper documentation aimed at beginners (so
does Tkinter!). WxPython also needs a better API (however only VERY
sightly!!). These are some areas where i can be very helpful.

On Jan 23, 11:06=A0am, Arndt Roger Schneider <arndt.ro...@addcom.de>
wrote:
> rantingrick schrieb:
>
> [snip]
>
> 1. You cannot define the terms--restrict your opponent--
> =A0 =A0 and battle it yourselves.
> 2. Your specified directory browser is useless.
> =A0 =A0 --At least define that the directory browser must have
> =A0 =A0 =A0 constant complexity to work with volatile
> =A0 =A0 =A0 data over a network...
>
> -roger

Get a life moron and post some code, if you can!

On Jan 22, 6:07=A0pm, rantingrick <rantingr...@gmail.com> wrote:

> I await any challengers...


So far only trolls (besides Terry, Octavian, D'Aprano) have replied.
In my time here within the Python community i have only met one person
who shares my in-depth knowledge of Tkinter. That person is Kevin
Waltzer. So outside of Python-dev and Guido. Kevin and I are are the
ONLY people qualified to offer opinions on the worth or worthlessness
of Tkinter. If anyone in this entire community thinks that they also
are qualified then prove your worth by creating a ListCtrl in Tkinter
that mirrors the wxPython ListCtrl in functionality. When you have
done that, i will elevate you to my circle of enlightenment. Than and
only then shall i even entertain you BS.

Until then, anyone who tries to devalue my argument is just an
ignorant troll.

On Sun, 23 Jan 2011 09:31:25 -0800, rantingrick wrote:

> So far only trolls (besides Terry, Octavian, D'Aprano) have replied.

So apart from the non-trolls, only trolls have replied?



-- 
Steven

On 01/23/2011 05:18 AM, rusi wrote:
>
> Tried the code with debian sid and default python (2.6)
>
> I get (after some loading... statements)
>
> Segmentation fault
>
> [Actually this is the first time in my 10 years of python that Ive
> seen a pure python module segfault :-) ]

I also have a segfault. You should fix that, rantingrick :)

On Sun, 23 Jan 2011 09:21:57 -0800, rantingrick wrote:

> Wait a minute, i am confused? What language is Python written in? Oh
> thats right Lisp! I am so dumb. How did i even get this job? :-)

Python is written in C, Java, C#, Javascript, Haskell, Ocaml, and, yes, 
even Lisp. There's even a Python interpreter written in Python. 
Admittedly, the Ocaml implementation seems to be abandoned, and some of 
the others are more experimental, but they're all Python.


-- 
Steven

On Jan 23, 12:21=A0pm, rantingrick <rantingr...@gmail.com> wrote:
> The code does work. You just lack the skill to run it.

I not only possess the skill to run it, but to find fault it in
through simple inspection.  All of the bugs I found, but one, I found
through reading the .py file. Heck, I'm so good that I guessed two of
the bugs before I downloaded the code because both are rank amateur
mistakes, and I'm not convinced you even rise to the level of amateur.

>
> What are these "so-called" bugs exactly?

1. There's a bug related to loading of your resources.
2. There's a bug related to when file I/O is performed.
3/4. There's at least two bugs related to handling of a specific mouse
event.
5. There's a bug related to reporting errors to the user.

All of these bugs, except one[1], show a grave misunderstanding about
how GUI toolkits operate and/or how the underlying operating systems
behave.

>Remember this code is not meant to WOW anyone.

That's apparent from simple inspection of the code!  Not only does it
not wow, it doesn't even illustrate your own example to a degree that
could be reasonably considered competent.  It demonstrates you didn't
even test the functionality you provided in your own code, or that if
you did, you're entirely clueless about GUI design fundamentals.

> The main point is to create a
> ListCtrl that has two view modes, icons, and editable items. You lack
> simple reading and comprehension skills Adam.

And your code will not do that in a whole host of common situations
that a GUI application is reasonably expected to handle.  It is not
sufficiently robust to be interesting.

> Adam you were one of the biggest trolls in the "other" thread. We
> don't need you trolling up this one too. Can you write any code? I
> have produced code and no one has offered a rebuttal using the Tkinter
> module. This is because only a handful of the entire community has the
> skills to create something like this with Tkinter.

No, it's because your code is complete and utter shite and there's
zero point in attempting to replicate it.  Your code does not work,
even if you think it does.  I'm not the only person who's noted this.

> HOWEVER YOU ARE NOT IN THIS GROUP ADAM. You are a troll, and that is
> all you can do. Prove me wrong if you can...

I already have.  Confirmation of some of the bugs I've noted exists in
this very thread.  Thus, I'm quite capable of reading and
comprehending Python code.  The same remains to be seen with you.

Adam

[1] Which is only because wxWidgets has a bug in this regard.  That
being said, a workaround exists and trivial to find online.

On Jan 23, 12:09=A0pm, Adam Skutt <ask...@gmail.com> wrote:
> On Jan 23, 12:21=A0pm, rantingrick <rantingr...@gmail.com> wrote:

> > What are these "so-called" bugs exactly?
>
> 1. There's a bug related to loading of your resources.
> 2. There's a bug related to when file I/O is performed.
> 3/4. There's at least two bugs related to handling of a specific mouse
> event.
> 5. There's a bug related to reporting errors to the user.

Well then post a traceback.

 However you still miss the point. You will do anything to distract
from the point. And what IS that point? Well that Tkinter is
lackluster 20 years old rotware and you need to resort to these BS
tactics to discredit me because 1). You cannot even create a Tkinter
GUI at the basic level, and 2) you have no real argument based on
facts!

Post CODE Adam. Code! Surely you can handle copy/pasting a traceback i
hope!

On Jan 23, 2:07=A0pm, rantingrick <rantingr...@gmail.com> wrote:
> Well then post a traceback.

None of these issues will supply a traceback; in fact, in some of
these cases, you went out of your way to ensure that would not
happen.  That's an additional bug (or 5 additional bugs depending how
mean your tester/QA staff are).

> =A0However you still miss the point. You will do anything to distract
> from the point. And what IS that point? Well that Tkinter is
> lackluster 20 years old rotware

The fact it doesn't provide a control found almost exclusively in file
browsers and open/save dialogs does not mean that it is "20 years old
rotware".

> and you need to resort to these BS tactics to discredit me because 1). Yo=
u cannot even create a Tkinter
> GUI at the basic level,

I certainly can, but there's no point in demonstrating my skill when
you cannot create a wxWidgets GUI at a basic level.  You made the
challenge, you intentionally styled it as "rantingrick v. the world",
so you need to actually bring something challenge worthy to the table
first.

That includes picking a challenge that's interesting and not over a
relatively minor widget in the grand scheme of things.  Qt, Swing,
Gtk, and Win32 common controls[1] don't provide the same exact control
either, should we view it as deficient?

But regardless of the challenge, I don't think you're capable of
posting a worthwhile example, which is why you dismiss all the
problems found with it instead of actually fixing the code.

> Post CODE Adam. Code! Surely you can handle copy/pasting a traceback i
> hope!

I certainly can.  I don't have much hope for you writing code that
provides tracebacks, much less actually useful ones.

Adam

[1] Hell, I'm not sure /any/ toolkit provides the whole of wxListCtrl
functionality OOB, besides wxWidgets itself.  Like I said, it's
specific functionality isn't well suited.

On Jan 23, 1:42=A0pm, Adam Skutt <ask...@gmail.com> wrote:
> On Jan 23, 2:07=A0pm, rantingrick <rantingr...@gmail.com> wrote:
>
> > Well then post a traceback.
>
> None of these issues will supply a traceback; in fact, in some of
> these cases, you went out of your way to ensure that would not
> happen. =A0

psst: thats because they are FEATURES and NOT BUGS you idiot! I am not
trying to create a working file browser so you can steal my code. No.
I am displaying one use case for a very useful widget. I repeat, i am
not going to code up a free file browser for you Adam. Get a life!

> > =A0However you still miss the point. You will do anything to distract
> > from the point. And what IS that point? Well that Tkinter is
> > lackluster 20 years old rotware
>
> The fact it doesn't provide a control found almost exclusively in file
> browsers and open/save dialogs does not mean that it is "20 years old
> rotware".

A ListCtrl is useful for many, many purposes. Just one of them happens
to be a file browser. Your statement comes as no great surprise to us
because we all know how you severely lack any kind of vision or
abstract reasoning abilities.

> > and you need to resort to these BS tactics to discredit me because 1). =
You cannot even create a Tkinter
> > GUI at the basic level,
>
> I certainly can, but there's no point in demonstrating my skill when
> you cannot create a wxWidgets GUI at a basic level.

BS. You're scared, You're under qualified. And it shows. BIGTIME!

> =A0You made the
> challenge, you intentionally styled it as "rantingrick v. the world",
> so you need to actually bring something challenge worthy to the table
> first.

Where is the world Adam? I am the only one who has summited code.


> That includes picking a challenge that's interesting and not over a
> relatively minor widget in the grand scheme of things.

ListCtrl's are very useful. And i have many more challenges coming.
WxPython outshines all the competition by leaps and bounds. The
ListCtrl is just the beginning.

> =A0Qt, Swing,
> Gtk, and Win32 common controls[1] don't provide the same exact control
> either, should we view it as deficient?

Yes.

> But regardless of the challenge,

You keep trying to divert attention from the point. Sorry but you're
not going to fool anyone with this foolishness.

> I don't think you're capable of
> posting a worthwhile example, which is why you dismiss all the
> problems found with it instead of actually fixing the code.

Ditto! But at least i have some code to work with. Something to create
a fact based argument from. You have nothing but your own foolishness
to build from.

> > Post CODE Adam. Code! Surely you can handle copy/pasting a traceback i
> > hope!
>
> I certainly can. =A0I don't have much hope for you writing code that
> provides tracebacks, much less actually useful ones.

I suppose you gauge the quality of code by how many tracebacks are
printed. And it seems even more perverse that you expect code to spit
exceptions! And when code fails to spit exceptions you get angry about
it and claim the programmer is insufficient. Hmm, this would explain
why you have yet to provide us with working (or even semi-working)
code. Adam you are by far the most foolish person i have ever met.

RR,
I have not seen anything useful from you thus far, except:
1) "you disagree with me, troll you must be,"
"2) who cares if my programs have bugs and don't compile cross-platform, 
defective code is code, none the less.
3) And a lot of unfounded arrogance in stating that no one understands 
Tkinter quite like yourself and a select handful of people.

I hardly think that your tone, attitude and arguments are going to help 
you in your battle to prove that WXPython is superior to anything at 
all, if you can't manage to provide cross-platform bug-free code. No, no 
one else has yet provided code in this thread from what I have seen, 
since that's the point you keep making time and time again in numerous 
messages that keep cluttering my inbox, but no one really has to. You 
are making an argument with a lot of anger and faulty code, which is 
supposed to prove that the library, in which you can't write an 
application that is bug free (or as bug free as any program can be) and 
also maintain the cross-platform goal, which is a huge part of Python 
currently, is superior to another that you are screaming and throwing 
tantrums over. So I await your response, though my psychic powers tells 
me the response will be one of silence, "stfu, you're just a troll," or 
"where's the code, I'm not going to produce bug-free code so you can rip 
off -my- top security amazing file browser," since such things don't 
already exist anyway.
On 1/23/2011 1:23 PM, rantingrick wrote:
> On Jan 23, 1:42 pm, Adam Skutt<ask...@gmail.com>  wrote:
>> On Jan 23, 2:07 pm, rantingrick<rantingr...@gmail.com>  wrote:
>>
>>> Well then post a traceback.
>> None of these issues will supply a traceback; in fact, in some of
>> these cases, you went out of your way to ensure that would not
>> happen.
> psst: thats because they are FEATURES and NOT BUGS you idiot! I am not
> trying to create a working file browser so you can steal my code. No.
> I am displaying one use case for a very useful widget. I repeat, i am
> not going to code up a free file browser for you Adam. Get a life!
>
>>>   However you still miss the point. You will do anything to distract
>>> from the point. And what IS that point? Well that Tkinter is
>>> lackluster 20 years old rotware
>> The fact it doesn't provide a control found almost exclusively in file
>> browsers and open/save dialogs does not mean that it is "20 years old
>> rotware".
> A ListCtrl is useful for many, many purposes. Just one of them happens
> to be a file browser. Your statement comes as no great surprise to us
> because we all know how you severely lack any kind of vision or
> abstract reasoning abilities.
>
>>> and you need to resort to these BS tactics to discredit me because 1). You cannot even create a Tkinter
>>> GUI at the basic level,
>> I certainly can, but there's no point in demonstrating my skill when
>> you cannot create a wxWidgets GUI at a basic level.
> BS. You're scared, You're under qualified. And it shows. BIGTIME!
>
>>   You made the
>> challenge, you intentionally styled it as "rantingrick v. the world",
>> so you need to actually bring something challenge worthy to the table
>> first.
> Where is the world Adam? I am the only one who has summited code.
>
>
>> That includes picking a challenge that's interesting and not over a
>> relatively minor widget in the grand scheme of things.
> ListCtrl's are very useful. And i have many more challenges coming.
> WxPython outshines all the competition by leaps and bounds. The
> ListCtrl is just the beginning.
>
>>   Qt, Swing,
>> Gtk, and Win32 common controls[1] don't provide the same exact control
>> either, should we view it as deficient?
> Yes.
>
>> But regardless of the challenge,
> You keep trying to divert attention from the point. Sorry but you're
> not going to fool anyone with this foolishness.
>
>> I don't think you're capable of
>> posting a worthwhile example, which is why you dismiss all the
>> problems found with it instead of actually fixing the code.
> Ditto! But at least i have some code to work with. Something to create
> a fact based argument from. You have nothing but your own foolishness
> to build from.
>
>>> Post CODE Adam. Code! Surely you can handle copy/pasting a traceback i
>>> hope!
>> I certainly can.  I don't have much hope for you writing code that
>> provides tracebacks, much less actually useful ones.
> I suppose you gauge the quality of code by how many tracebacks are
> printed. And it seems even more perverse that you expect code to spit
> exceptions! And when code fails to spit exceptions you get angry about
> it and claim the programmer is insufficient. Hmm, this would explain
> why you have yet to provide us with working (or even semi-working)
> code. Adam you are by far the most foolish person i have ever met.


-- 

Thanks,
Ty

On Jan 23, 3:23=A0pm, rantingrick <rantingr...@gmail.com> wrote:
> psst: thats because they are FEATURES and NOT BUGS you idiot!

Your application not displaying a directory listing, due to one of
these "features", is desirable behavior?  I think not.  Your
application hanging, due to one of these "features" is desirable
behavior? I think not, nor do the wxWidgets, Qt, Swing, Cocoa, Gtk,
Win32, et al. toolkit developers.

> I am not trying to create a working file browser so you can steal my code=
..

I have ethics, morals, and standards, all of which forbid me from
stealing anything you write.

> I am displaying one use case for a very useful widget.

So useful that you've only found one toolkit that provides it OOB!

> A ListCtrl is useful for many, many purposes. Just one of them happens
> to be a file browser.

The specific functionality the wxWidgets ListCtrl has over its
alternatives in other toolkits is only really seen in file browsers.
Your challenge explicitly relies on making use of that functionality
and in no way, shape, or form illustrates the general utility of a
wxListCtrl.

When you amend the challenge, you can make the claim it's not about
wxListCtrl's unique functionality.

> >  Qt, Swing,
> > Gtk, and Win32 common controls[1] don't provide the same exact control
> > either, should we view it as deficient?

> Yes.

Funny, given that the original purpose of wxWidgets was to provide a
cross-platform MFC wrapper, I think you're in the minority of thought
among those developers, to say nothing of developers in general.

> I suppose you gauge the quality of code by how many tracebacks are
> printed. And it seems even more perverse that you expect code to spit
> exceptions!

You're the one who asked for them originally, not I.  I merely posited
that since you provided code that prints no tracebacks and expected
them (i.e., what you expect your code to do and what it does are two
different things), that it is highly unlikely you're capable of
providing me code that actually prints tracebacks, much less
tracebacks that assist you in debugging.

Put plainly, you have no clue whatsoever what your code actually does
or how it accomplishes it, which is exactly what we'd expect.

Adam

Hi Adam,

I'm still learning my way around wxPython and gui programming, been 
mostly linux and CLI since Visual Basic 5, and only recently started 
learning it.

On 23/01/2011 18:09, Adam Skutt wrote:
> 1. There's a bug related to loading of your resources.
> 2. There's a bug related to when file I/O is performed.
> 3/4. There's at least two bugs related to handling of a specific mouse
> event.
> 5. There's a bug related to reporting errors to the user.
>
> All of these bugs, except one[1], show a grave misunderstanding about
> how GUI toolkits operate and/or how the underlying operating systems
> behave.
 >
> [1] Which is only because wxWidgets has a bug in this regard.  That
> being said, a workaround exists and trivial to find online.

I'd be curious as to what these bugs are, as a learning exercise, if you 
don't mind. I don't mind a direct mail if you wish not to subject 
yourself to any more abuse on the list, as would almost certainly come. 
I'd especially like to be pointed at the error you refer to in [1].


On to the topic of the program direct, the 'List view' button doesn't 
seem to work on my platform, showing a blank folder icon and nothing 
else, but I don't know if that is related to any of these bugs.

I actually looked around when I wanted to start learning gui 
programming, and chose wxPython because it seemed to use 'native' 
controls on all of the platforms. This file viewer just looks awful (is 
it supposed to flicker so much when I try to change the column size?) so 
I'm not exactly sure what it is supposed to prove.

Nick

On Jan 23, 3:11=A0pm, "Littlefield, Tyler" <ty...@tysdomain.com> wrote:

> if you can't manage to provide cross-platform bug-free code.

No one has posted even one traceback Tyler (including yourself!). And
until they do i will assume that my code is bug free. I know it to be
bug free on windows. If and when someone *actually* provides proof
(supported by a traceback) then i will take them seriously.

On Sunday 23 January 2011 17:57, rantingrick wrote:

> On Jan 22, 9:39�pm, Terry Reedy <tjre...@udel.edu> wrote:
>> On 1/22/2011 7:07 PM, rantingrick wrote:
>>
>> Near the beginning of this thread, I gently challenged you to produce a
>> concrete, practical proposal for an stdlib addition that could be
>> critiqued and improved. When you asked for problems with
>> wxwidgets/wxpython, I gave some. Still waiting.
> 
> You may have done this however i do not remember. With all the
> trolling that was going on (not you) i may have missed it.

^^^ +1 QOTW

David

On 01/23/2011 05:08 PM, rantingrick wrote:
> On Jan 23, 3:11 pm, "Littlefield, Tyler"<ty...@tysdomain.com>  wrote:
>
>> if you can't manage to provide cross-platform bug-free code.
>
> No one has posted even one traceback Tyler (including yourself!). And
> until they do i will assume that my code is bug free. I know it to be
> bug free on windows. If and when someone *actually* provides proof
> (supported by a traceback) then i will take them seriously.
>
>


There are more types of bugs than syntax errors, which are one of the 
only types of bug that raise exceptions in Python. Try looking at [1] or 
[2].

Here is the output on my system (Linux Mint 64bit):

/home/corey/Downloads/Wx_Tk_Challenge/Bitmaps
Loading Images:
  -- /home/corey/Downloads/Wx_Tk_Challenge/Bitmaps/file.bmp file.bmp
  -- /home/corey/Downloads/Wx_Tk_Challenge/Bitmaps/folder.bmp folder.bmp
  -- /home/corey/Downloads/Wx_Tk_Challenge/Bitmaps/link.bmp link.bmp
['folder', 'link', 'file']
Segmentation fault



[1] http://en.wikipedia.org/wiki/Software_bug#Common_types_of_computer_bugs
[2] http://msdn.microsoft.com/en-us/library/s9ek7a19%28v=vs.80%29.aspx

On Sun, 23 Jan 2011 12:23:13 -0800, rantingrick wrote:

> I am not
> trying to create a working file browser so you can steal my code.

Dammit! There goes my brilliant idea for getting rich.

Step 1: Start company.
Step 2: Steal working file browser from Internet.
Step 4: Profit!



I think rantingrick's comment inadvertently shows in a nutshell 
everything wrong with this thread and why there is so little interest in 
his proposal. If RR is right about the GUI toolkit making or breaking the 
entire Python community, there should be hundreds of people with an 
opinion, not just a handful.

(1) rantingrick is willing to spend *hours* brow-beating people, 
insulting them, and cajoling them into doing things *his* way, supposedly 
because of his deep concern for the Python community, but isn't willing 
to donate a lousy *file browser* to the community.

(2) GUI programming is TOO DAMN HARD, and until that fact is addressed, 
it's difficult for the majority of people to care whether the toolkit 
used (or, more likely, not used at all) is Tkinter, or wxPython, or 
something else.

For something as common as displaying a file browser, it should be as 
simple as this:

import gui_toolkit  # whichever
path = gui_toolkit.select_file()

Something like zenity:

[steve@sylar ~]$ zenity --file-selection
/home/steve/python/findsingle.py


Of course there are times when you need to do more complicated things, 
and a decent toolkit should allow you to do so. But simple things should 
be simple, and as far as I can see, there are no GUI toolkits that make 
*anything* simple.


-- 
Steven

I found this code in the Demo/tkinter/ttk directory of the Python 2.7.1 
source distribution. I'm NOT the author (credit should probably go to 
Guilherme Polo, developer of the Tkinter wrapper for the ttk themed 
widgets that is now in the stdlib). But, using a tree/listview widget 
that is part of the Tk/Tkinter core (NOT an extension),  it presents a 
decent, simple file browser:

"""A directory browser using Ttk Treeview.

Based on the demo found in Tk 8.5 library/demos/browse
"""
import os
import glob
import Tkinter
import ttk

def populate_tree(tree, node):
     if tree.set(node, "type") != 'directory':
         return

     path = tree.set(node, "fullpath")
     tree.delete(*tree.get_children(node))

     parent = tree.parent(node)
     special_dirs = [] if parent else glob.glob('.') + glob.glob('..')

     for p in special_dirs + os.listdir(path):
         ptype = None
         p = os.path.join(path, p).replace('\\', '/')
         if os.path.isdir(p): ptype = "directory"
         elif os.path.isfile(p): ptype = "file"

         fname = os.path.split(p)[1]
         id = tree.insert(node, "end", text=fname, values=[p, ptype])

         if ptype == 'directory':
             if fname not in ('.', '..'):
                 tree.insert(id, 0, text="dummy")
                 tree.item(id, text=fname)
         elif ptype == 'file':
             size = os.stat(p).st_size
             tree.set(id, "size", "%d bytes" % size)


def populate_roots(tree):
     dir = os.path.abspath('.').replace('\\', '/')
     node = tree.insert('', 'end', text=dir, values=[dir, "directory"])
     populate_tree(tree, node)

def update_tree(event):
     tree = event.widget
     populate_tree(tree, tree.focus())

def change_dir(event):
     tree = event.widget
     node = tree.focus()
     if tree.parent(node):
         path = os.path.abspath(tree.set(node, "fullpath"))
         if os.path.isdir(path):
             os.chdir(path)
             tree.delete(tree.get_children(''))
             populate_roots(tree)

def autoscroll(sbar, first, last):
     """Hide and show scrollbar as needed."""
     first, last = float(first), float(last)
     if first <= 0 and last >= 1:
         sbar.grid_remove()
     else:
         sbar.grid()
     sbar.set(first, last)

root = Tkinter.Tk()

vsb = ttk.Scrollbar(orient="vertical")
hsb = ttk.Scrollbar(orient="horizontal")

tree = ttk.Treeview(columns=("fullpath", "type", "size"),
     displaycolumns="size", yscrollcommand=lambda f, l: autoscroll(vsb, 
f, l),
     xscrollcommand=lambda f, l:autoscroll(hsb, f, l))

vsb['command'] = tree.yview
hsb['command'] = tree.xview

tree.heading("#0", text="Directory Structure", anchor='w')
tree.heading("size", text="File Size", anchor='w')
tree.column("size", stretch=0, width=100)

populate_roots(tree)
tree.bind('<<TreeviewOpen>>', update_tree)
tree.bind('<Double-Button-1>', change_dir)

# Arrange the tree and its scrollbars in the toplevel
tree.grid(column=0, row=0, sticky='nswe')
vsb.grid(column=1, row=0, sticky='ns')
hsb.grid(column=0, row=1, sticky='ew')
root.grid_columnconfigure(0, weight=1)
root.grid_rowconfigure(0, weight=1)

root.mainloop()




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

>> Segmentation fault
>>
>> [Actually this is the first time in my 10 years of python that Ive
>> seen a pure python module segfault :-) ]
> 
> Congratulations genius! However if you are really smart you would have
> read the note in the source that says "tested on windows only!".
> Segfault. Thanks for the laugh!

I get the same:

/tmp/Wx_Tk_Challenge/Bitmaps
Loading Images:
 -- /tmp/Wx_Tk_Challenge/Bitmaps/file.bmp file.bmp
 -- /tmp/Wx_Tk_Challenge/Bitmaps/link.bmp link.bmp
 -- /tmp/Wx_Tk_Challenge/Bitmaps/folder.bmp folder.bmp
['folder', 'link', 'file']
Speicherzugriffsfehler

Since you are asking for a traceback, here is one:

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff554c8cd in wxListMainWindow::InsertItem(wxListItem&) () from
/usr/lib/libwx_gtk2u_core-2.6.so.0
(gdb) bt
#0  0x00007ffff554c8cd in wxListMainWindow::InsertItem(wxListItem&) ()
from /usr/lib/libwx_gtk2u_core-2.6.so.0
#1  0x00007ffff554c940 in wxGenericListCtrl::InsertItem(wxListItem&) ()
from /usr/lib/libwx_gtk2u_core-2.6.so.0
#2  0x00007ffff554f012 in wxGenericListCtrl::InsertItem(long, wxString
const&, int) () from /usr/lib/libwx_gtk2u_core-2.6.so.0
#3  0x00007fffee58c460 in ?? () from
/usr/lib/python2.6/dist-packages/wx-2.6-gtk2-unicode/wx/_controls_.so
#4  0x00000000004a794b in PyEval_EvalFrameEx ()
#5  0x00000000004a95c1 in PyEval_EvalCodeEx ()
#6  0x00000000004a7752 in PyEval_EvalFrameEx ()
#7  0x00000000004a84a0 in PyEval_EvalFrameEx ()
#8  0x00000000004a95c1 in PyEval_EvalCodeEx ()
#9  0x0000000000538b0d in ?? ()
#10 0x000000000041ef47 in PyObject_Call ()
#11 0x0000000000427c1f in ?? ()
#12 0x000000000041ef47 in PyObject_Call ()
#13 0x00000000004778ff in ?? ()
#14 0x000000000046f16f in ?? ()
#15 0x000000000041ef47 in PyObject_Call ()
#16 0x00000000004a72b8 in PyEval_EvalFrameEx ()
#17 0x00000000004a95c1 in PyEval_EvalCodeEx ()
#18 0x00000000004a9692 in PyEval_EvalCode ()
#19 0x00000000004c98be in PyRun_FileExFlags ()
#20 0x00000000004c9ad4 in PyRun_SimpleFileExFlags ()
#21 0x000000000041a6bd in Py_Main ()
#22 0x00007ffff69eac4d in __libc_start_main () from /lib/libc.so.6
#23 0x00000000004198d9 in _start ()

If you had expected a Python traceback, sorry Rick: it didn't produce
one, since it crashed.

So Rick you managed to crash wxPython, in just 248 lines of code. This
doesn't give a very good impression of wxPython - "regular" Python
libraries shouldn't crash the interpreter.

Regards,
Martin

> For something as common as displaying a file browser, it should be as 
> simple as this:
> 
> import gui_toolkit  # whichever
> path = gui_toolkit.select_file()
> 
> Something like zenity:
> 
> [steve@sylar ~]$ zenity --file-selection
> /home/steve/python/findsingle.py

And indeed, it is that simple:

python -c "import tkFileDialog as tkfd;print tkfd.askopenfilename()"

Regards,
Martin

On Jan 22, 6:07=A0pm, rantingrick <rantingr...@gmail.com> wrote:

> I await any challengers...


WxPython Challenge 1 code updated...

 * Fixed tab traveral
 * Removed hand-holding code
 * Removed some cruft

  https://sites.google.com/site/thefutureofpython/home/code-challenges

Good luck!

On 01/23/2011 07:07 PM, rantingrick wrote:
> On Jan 22, 6:07 pm, rantingrick<rantingr...@gmail.com>  wrote:
>
>> I await any challengers...
>
>
> WxPython Challenge 1 code updated...
>
>   * Fixed tab traveral
>   * Removed hand-holding code
>   * Removed some cruft
>
>    https://sites.google.com/site/thefutureofpython/home/code-challenges
>
> Good luck!

Still doesn't fix the problem of the code not working on Linux boxes. 
Maybe wxPython isn't the best option, it doesn't appear very cross-platform.
Still getting:

Loading Images:
  -- /home/corey/Downloads/Wx_Tk_Challenge/Bitmaps/file.bmp, file.bmp
  -- /home/corey/Downloads/Wx_Tk_Challenge/Bitmaps/folder.bmp, folder.bmp
  -- /home/corey/Downloads/Wx_Tk_Challenge/Bitmaps/link.bmp, link.bmp
imageMap.keys -> ['folder', 'link', 'file']
Segmentation fault

> WxPython Challenge 1 code updated...
> 
>  * Fixed tab traveral
>  * Removed hand-holding code
>  * Removed some cruft
> 
>   https://sites.google.com/site/thefutureofpython/home/code-challenges
> 
> Good luck!

Still crashes the interpreter.

Regards,
Martin

On Jan 23, 5:23=A0pm, Kevin Walzer <k...@codebykevin.com> wrote:
> I found this code in the Demo/tkinter/ttk directory of the Python 2.7.1
> source distribution. I'm NOT the author (credit should probably go to
> Guilherme Polo, developer of the Tkinter wrapper for the ttk themed
> widgets that is now in the stdlib). But, using a tree/listview widget
> that is part of the Tk/Tkinter core (NOT an extension), =A0it presents a
> decent, simple file browser:
>
> """A directory browser using Ttk Treeview.

The only way i can respond to this is to quite the requirements for my
challenge...

---------------------------------------
 Challenge 1: (Simple Directory Viewer)
---------------------------------------
Create a simple Directory Viewer GUI. You CANNOT use a treectrl!


Any questions?

On 1/23/11 8:12 PM, rantingrick wrote:

> The only way i can respond to this is to quite the requirements for my
> challenge...
>
> ---------------------------------------
>   Challenge 1: (Simple Directory Viewer)
> ---------------------------------------
> Create a simple Directory Viewer GUI. You CANNOT use a treectrl!
>
>
> Any questions?

Why not?

I'd understand if this code made use of some Tk extension, as that's not 
quite an apples-to-apples comparison. But the treectrl is part of the 
core Tkinter widget set. There's no reason to exclude it unless you are 
deliberately trying to handicap Tk in your comparison.

--Kevin

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

On Mon, 24 Jan 2011 00:44:57 +0100, Martin v. Loewis wrote:

>> For something as common as displaying a file browser, it should be as
>> simple as this:
>> 
>> import gui_toolkit  # whichever
>> path = gui_toolkit.select_file()
>> 
>> Something like zenity:
>> 
>> [steve@sylar ~]$ zenity --file-selection
>> /home/steve/python/findsingle.py
> 
> And indeed, it is that simple:
> 
> python -c "import tkFileDialog as tkfd;print tkfd.askopenfilename()"

Brilliant! Pity that it is so ugly under Linux :(



-- 
Steven

On Jan 23, 5:27=A0pm, "Martin v. Loewis" <mar...@v.loewis.de> wrote:

> Since you are asking for a traceback, here is one:

[...snip: barf...]

> If you had expected a Python traceback, sorry Rick: it didn't produce
> one, since it crashed.

Well i did "expect" that you would at least include some info as to
your OS and version. That would be helpful also. Obviously the
wx.ImageList is barfing. Do you have the Bitmap folder containing the
three images. Did you try to comment out the "_createImages()" line.
Simple debug skills we are talking about here Martin, simple. But yet
again this is only tested on Windows. I clearly noted that in the
source.

On Jan 23, 5:44=A0pm, "Martin v. Loewis" <mar...@v.loewis.de> wrote:
> > For something as common as displaying a file browser, it should be as
> > simple as this:
>
> > import gui_toolkit =A0# whichever
> > path =3D gui_toolkit.select_file()
>
> > Something like zenity:
>
> > [steve@sylar ~]$ zenity --file-selection
> > /home/steve/python/findsingle.py
>
> And indeed, it is that simple:
>
> python -c "import tkFileDialog as tkfd;print tkfd.askopenfilename()"


Martin the tkFileDialog.ask* uses the platform specific Open, Save
dialogs which DO contain a ListCtrl. Obviously this ListCtrl is not
available to Tkinter uses. You just exposed your weak knowledge of
Tkinter and sadly you are very high on the community totem pole. Very
sad :(

On Jan 23, 6:31=A0pm, "Martin v. Loewis" <mar...@v.loewis.de> wrote:
> > WxPython Challenge 1 code updated...
>
> > =A0* Fixed tab traveral
> > =A0* Removed hand-holding code
> > =A0* Removed some cruft
>
> > =A0https://sites.google.com/site/thefutureofpython/home/code-challenges
>
> > Good luck!
>
> Still crashes the interpreter.


 What OS are you using? You failed to answer this last question
lastime.

On Jan 23, 6:30=A0pm, Corey Richardson <kb1...@aim.com> wrote:
> On 01/23/2011 07:07 PM, rantingrick wrote:
>
> > On Jan 22, 6:07 pm, rantingrick<rantingr...@gmail.com> =A0wrote:
>
> >> I await any challengers...
>
> > WxPython Challenge 1 code updated...
>
> > =A0 * Fixed tab traveral
> > =A0 * Removed hand-holding code
> > =A0 * Removed some cruft
>
> > =A0 =A0https://sites.google.com/site/thefutureofpython/home/code-challe=
nges
>
> > Good luck!
>
> Still doesn't fix the problem of the code not working on Linux boxes.
> Maybe wxPython isn't the best option, it doesn't appear very cross-platfo=
rm.
> Still getting:
>
> Loading Images:
> =A0 -- /home/corey/Downloads/Wx_Tk_Challenge/Bitmaps/file.bmp, file.bmp
> =A0 -- /home/corey/Downloads/Wx_Tk_Challenge/Bitmaps/folder.bmp, folder.b=
mp
> =A0 -- /home/corey/Downloads/Wx_Tk_Challenge/Bitmaps/link.bmp, link.bmp
> imageMap.keys -> ['folder', 'link', 'file']
> Segmentation fault

Have you tried any debugging? Maybe Linux has some specific needs and
NOT wxPython. Stop jumping to conclusions.

On Jan 23, 7:16=A0pm, Kevin Walzer <k...@codebykevin.com> wrote:
> On 1/23/11 8:12 PM, rantingrick wrote:
>
> > The only way i can respond to this is to quite the requirements for my
> > challenge...
>
> > ---------------------------------------
> > =A0 Challenge 1: (Simple Directory Viewer)
> > ---------------------------------------
> > Create a simple Directory Viewer GUI. You CANNOT use a treectrl!
>
> > Any questions?
>
> Why not?
>
> I'd understand if this code made use of some Tk extension, as that's not
> quite an apples-to-apples comparison. But the treectrl is part of the
> core Tkinter widget set.

Well wxPython ha a treectrl too. And if we were comparing apples to
apples then we would compare the wx.TreeCtrl to the Tk::TreeCtrl.
However there are many things that a ListCtrl can do that a treectrl
can't. The biggest difference.... COLUMNS

> There's no reason to exclude it (Tk::TreeCtrl) unless you are
> deliberately trying to handicap Tk in your comparison.

I am not handicapping TclTk. They already did that themselves by
refusing to keep up with  21st century GUI libraries. Sure, you can
say Tkinter is a knife and wxPython is an AK47 but who's to blame when
you bring a knife to gun fight Kevin? Switch to wx and enjoy the
bloodbath.

On Jan 23, 7:18=A0pm, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:
> On Mon, 24 Jan 2011 00:44:57 +0100, Martin v. Loewis wrote:
> >> For something as common as displaying a file browser, it should be as
> >> simple as this:
>
> >> import gui_toolkit =A0# whichever
> >> path =3D gui_toolkit.select_file()
>
> >> Something like zenity:
>
> >> [steve@sylar ~]$ zenity --file-selection
> >> /home/steve/python/findsingle.py
>
> > And indeed, it is that simple:
>
> > python -c "import tkFileDialog as tkfd;print tkfd.askopenfilename()"
>
> Brilliant!


No, that was even weaker than Guido's tag argument. At LEAST when
Guido parrots off minor issues he uses some fact based argument. This
is just pathetic! Only the lemmings would believe such nonsense.

> Pity that it is so ugly under Linux :(

And who's fault is that i wonder?

On 01/23/2011 08:25 PM, rantingrick wrote:
> On Jan 23, 5:44 pm, "Martin v. Loewis"<mar...@v.loewis.de>  wrote:
>>> For something as common as displaying a file browser, it should be as
>>> simple as this:
>>
>>> import gui_toolkit  # whichever
>>> path = gui_toolkit.select_file()
>>
>>> Something like zenity:
>>
>>> [steve@sylar ~]$ zenity --file-selection
>>> /home/steve/python/findsingle.py
>>
>> And indeed, it is that simple:
>>
>> python -c "import tkFileDialog as tkfd;print tkfd.askopenfilename()"
>
>
> Martin the tkFileDialog.ask* uses the platform specific Open, Save
> dialogs which DO contain a ListCtrl. Obviously this ListCtrl is not
> available to Tkinter uses. You just exposed your weak knowledge of
> Tkinter and sadly you are very high on the community totem pole. Very
> sad :(
>

Actually, the people on the top of the totem pole were of less social 
status. 
http://podcasts.howstuffworks.com/hsw/podcasts/sysk/2009-11-17-sysk-totem-poles.mp3?_kip_ipx=1723793795-1295833113

(Finally, useful knowledge from listening to podcasts in my off-time!)

You have also ignored that I gave the same information as him (minus the 
traceback), saying that I am on Linux Mint 64bit.

Why can't we use a TreeCtrl? If we can't use all our widgets, why can 
you use all yours?

~Corey

On Jan 23, 7:40=A0pm, Corey Richardson <kb1...@aim.com> wrote:

> Why can't we use a TreeCtrl? If we can't use all our widgets, why can
> you use all yours?
>
> ~Corey

Columns Corey, the key word here is "columns". One more
time...COOOOOOLLLLLUUUMMMNNNSSSS. Is this starting to sink in yet
Corey?

On 01/23/2011 08:50 PM, rantingrick wrote:
> On Jan 23, 7:40 pm, Corey Richardson<kb1...@aim.com>  wrote:
>
>> Why can't we use a TreeCtrl? If we can't use all our widgets, why can
>> you use all yours?
>>
>> ~Corey
>
> Columns Corey, the key word here is "columns". One more
> time...COOOOOOLLLLLUUUMMMNNNSSSS. Is this starting to sink in yet
> Corey?

I sent that email before you sent your email explaining why (responded 
to Kevin), sorry that I can't see the future.

On 01/23/2011 08:28 PM, rantingrick wrote:
> On Jan 23, 6:30 pm, Corey Richardson<kb1...@aim.com>  wrote:
>> On 01/23/2011 07:07 PM, rantingrick wrote:
>>
>>> On Jan 22, 6:07 pm, rantingrick<rantingr...@gmail.com>    wrote:
>>
>>>> I await any challengers...
>>
>>> WxPython Challenge 1 code updated...
>>
>>>    * Fixed tab traveral
>>>    * Removed hand-holding code
>>>    * Removed some cruft
>>
>>>     https://sites.google.com/site/thefutureofpython/home/code-challenges
>>
>>> Good luck!
>>
>> Still doesn't fix the problem of the code not working on Linux boxes.
>> Maybe wxPython isn't the best option, it doesn't appear very cross-platform.
>> Still getting:
>>
>> Loading Images:
>>    -- /home/corey/Downloads/Wx_Tk_Challenge/Bitmaps/file.bmp, file.bmp
>>    -- /home/corey/Downloads/Wx_Tk_Challenge/Bitmaps/folder.bmp, folder.bmp
>>    -- /home/corey/Downloads/Wx_Tk_Challenge/Bitmaps/link.bmp, link.bmp
>> imageMap.keys ->  ['folder', 'link', 'file']
>> Segmentation fault
>
> Have you tried any debugging? Maybe Linux has some specific needs and
> NOT wxPython. Stop jumping to conclusions.


Python (and supposedly wxPython) are cross-platform. Code that runs on 
one should run on the other unmodified. This is obviously not the case.

Line 151 fails (determined from a simple binary search using print 
statements):

index = self.InsertImageStringItem(sys.maxint, name, imageIdx)

Maybe wxPython (really wxwidgets, python doesn't throw segfaults...that 
I've ever seen) isn't suited for the stdlib, unless this is a just a 
really silly bug somewhere in your programming (which I doubt it is).
Looks like an issue with the method, because imageIdx is just a 
dictionary, sys.maxint is a (surprise!) integer, and name is a string.

On 1/23/11 8:33 PM, rantingrick wrote:

> Well wxPython ha a treectrl too. And if we were comparing apples to
> apples then we would compare the wx.TreeCtrl to the Tk::TreeCtrl.
> However there are many things that a ListCtrl can do that a treectrl
> can't. The biggest difference.... COLUMNS

The ttk::treeview widget can also function as a multi-column listbox, 
and can include both tree and multi-column listbox features in a single 
window. It's a very flexible widget.

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

On Jan 23, 8:06=A0pm, Corey Richardson <kb1...@aim.com> wrote:

> > Columns Corey, the key word here is "columns". One more
> > time...COOOOOOLLLLLUUUMMMNNNSSSS. Is this starting to sink in yet
> > Corey?
>
> I sent that email before you sent your email explaining why (responded
> to Kevin), sorry that I can't see the future.

Don't worry, I forgive you Corey. We can't *all* be visionaries ;-)

On Jan 23, 8:07=A0pm, Corey Richardson <kb1...@aim.com> wrote:

> because imageIdx is just a dictionary,

No, imageIdx is an integer.

On Jan 23, 8:16=A0pm, Kevin Walzer <k...@codebykevin.com> wrote:

> The ttk::treeview widget can also function as a multi-column listbox,
> and can include both tree and multi-column listbox features in a single
> window. It's a very flexible widget.

Can we see some working code? I would love to see some code Kevin. You
might satisfy the column requirement however you also need editable
labels and two veiw modes;  reportview and listview. Actually it
sounds pretty much like a (wait for it...) TreeCtrl to me.

PS: Be sure not to cause any segfaults because these linux folks can't
debug for shite!

On 01/23/2011 09:29 PM, rantingrick wrote:
> On Jan 23, 8:07 pm, Corey Richardson<kb1...@aim.com>  wrote:
>
>> because imageIdx is just a dictionary,
>
> No, imageIdx is an integer.

You're right.
imageIdx = self.imageMap[iconname]

I confused imageIdx with self.imageMap. But that still doesn't fix my 
problem, so before I go diving into the wxPython source, anyone have a 
'quick fix'?

On Jan 22, 6:07=A0pm, rantingrick <rantingr...@gmail.com> wrote:

> I await any challengers...

CODE UPDATE:

 * removed sys.maxint (not sure how it got there?)


https://sites.google.com/site/thefutureofpython/home/code-challenges

On Sun, 23 Jan 2011 17:50:24 -0800, rantingrick wrote:

> On Jan 23, 7:40 pm, Corey Richardson <kb1...@aim.com> wrote:
> 
>> Why can't we use a TreeCtrl? If we can't use all our widgets, why can
>> you use all yours?
>>
>> ~Corey
> 
> Columns Corey, the key word here is "columns". One more
> time...COOOOOOLLLLLUUUMMMNNNSSSS. Is this starting to sink in yet Corey?

When I run the code snippet Martin provided under Linux, the file 
selection box shows files in columns. That's part of the reason why I 
consider it ugly -- I'm an old Mac guy, and I still dislike file 
selection tools that use the Windows 95 style 2-D layout:


a-file      e-file      ...
b-file      f-file      y-file
c-file      g-file      z-file
d-file      h-file


instead of a simple vertical list:

a-file
b-file
c-file
....
z-file


Call me a dinosaur if you will, but I hate horizontal scrolling.



-- 
Steven

On 01/23/2011 09:47 PM, rantingrick wrote:
> On Jan 22, 6:07 pm, rantingrick<rantingr...@gmail.com>  wrote:
>
>> I await any challengers...
>
> CODE UPDATE:
>
>   * removed sys.maxint (not sure how it got there?)
>
>
> https://sites.google.com/site/thefutureofpython/home/code-challenges

In the example at 
http://www.wxpython.org/OSCON2004/advanced/wxPython-Advanced-OSCON2004.pdf 
they use sys.maxint, which may be where you got it (wild shot in the dark!).

The following result in a segfault:
-------item-1---------------------
list_item = wx.ListItem()
list_item.SetId(idx)
list_item.SetText(name)
list_item.SetWidth(50)
index = self.InsertItem(list_item)
-----------end--------------------

------item-2----------------------
self.InsertStringItem(idx, name)
-----------end--------------------


The following will launch the application:
(drop in replacement for line 151):

index = self.SetStringItem(idx, 0, name)

No idea why, I've never used wxPython before today.
Unfortunately, it doesn't actually show the items in the directory.
Since I'm definitely not a wxPython user, would you mind making the
above work, rantingrick? Not trying to worm out of anything, but this
is way over my head.

~Corey

 >PS: Be sure not to cause any segfaults because these linux folks can't
 >debug for shite!
Or maybe it is that the person fighting and throwing insults around like 
candy at a parade can't code for shite. Or *gasp* the library that is 
supposedly cross-platform has issues on certain platforms. You provided 
a challenge to show how superior wxPython was. If it segfaults, that 
tells me that: 1) you can't code worth "shite," or 2) the library you 
are drooling over sucks and shouldn't be cross-platform. Which is it? I 
highly doubt there is a third option, but please feel free to tell me, 
rather than insulting again.
On 1/23/2011 7:34 PM, rantingrick wrote:
> On Jan 23, 8:16 pm, Kevin Walzer<k...@codebykevin.com>  wrote:
>
>> The ttk::treeview widget can also function as a multi-column listbox,
>> and can include both tree and multi-column listbox features in a single
>> window. It's a very flexible widget.
> Can we see some working code? I would love to see some code Kevin. You
> might satisfy the column requirement however you also need editable
> labels and two veiw modes;  reportview and listview. Actually it
> sounds pretty much like a (wait for it...) TreeCtrl to me.
>
> PS: Be sure not to cause any segfaults because these linux folks can't
> debug for shite!


-- 

Thanks,
Ty

On Jan 24, 9:16=A0am, "Littlefield, Tyler" <ty...@tysdomain.com> wrote:
> =A0>PS: Be sure not to cause any segfaults because these linux folks can'=
t
> =A0>debug for shite!
> Or maybe it is that the person fighting and throwing insults around like
> candy at a parade can't code for shite. Or *gasp* the library that is
> supposedly cross-platform has issues on certain platforms. You provided
> a challenge to show how superior wxPython was. If it segfaults, that
> tells me that: 1) you can't code worth "shite," or 2) the library you
> are drooling over sucks and shouldn't be cross-platform. Which is it? I
> highly doubt there is a third option, but please feel free to tell me,
> rather than insulting again.

I think there is a third option
About rr's code-ing ability... this thread is long enough  :-)
Likewise if a certain library not in python standard distribution does
not work properly its the problem of the library.
But if python crashes its not good for the image of python.

Personal note 1: I am often teaching python with code I am seeing for
the first time -- typically something the class presents me which we
understand/debug/refactor together.
Usually I am not afraid of python because errors are helpful and
gentle.
Segfaulting on the other hand is the last thing I want to see in such
a context :-)

Personal note 2: I dont regard myself as a gui programmer and Ive
often wondered which toolkit to demonstrate.  I probably wont be
looking at wx now unless someone gives a convincing argument that the
segfault did not happen "inside" wx.

Of course as Steven pointed out wx is written in C++ which is almost
certainly where the crash is occurring.
But this is technical nitpicking.
The real issue is that when coding in C/C++ segfaults are a daily
affair.
Whereas for python its the first time I am seeing it in 10 years...

From: "Kevin Walzer" <kw@codebykevin.com>
>I found this code in the Demo/tkinter/ttk directory of the Python 2.7.1 
>source distribution. I'm NOT the author (credit should probably go to 
>Guilherme Polo, developer of the Tkinter wrapper for the ttk themed widgets 
>that is now in the stdlib). But, using a tree/listview widget that is part 
>of the Tk/Tkinter core (NOT an extension),  it presents a decent, simple 
>file browser:
>


Well, I have also tested the program dirbrowser.py, but it is not decent at 
all.
I have tested it with JAWS screen reader and it is absolutely inaccessible.

The single "accessible" things in it are the title bar which is "tk".
It can't compare with the same program made using WxPython.
And it can't be made to be more accessible than it is, because it uses Tk.

So Tkinter is really bad.

Octavian

From: "Kevin Walzer" <kw@codebykevin.com>
> The ttk::treeview widget can also function as a multi-column listbox, and 
> can include both tree and multi-column listbox features in a single 
> window. It's a very flexible widget.


But unfortunately it is not accessible for screen readers and it 
discriminates many potential users.

Octavian

From: "Littlefield, Tyler" <tyler@tysdomain.com>
> >PS: Be sure not to cause any segfaults because these linux folks can't
> >debug for shite!
> Or maybe it is that the person fighting and throwing insults around like 
> candy at a parade can't code for shite. Or *gasp* the library that is 
> supposedly cross-platform has issues on certain platforms. You provided a 
> challenge to show how superior wxPython was. If it segfaults, that tells 
> me that: 1) you can't code worth "shite," or 2) the library you are 
> drooling over sucks and shouldn't be cross-platform. Which is it? I highly 
> doubt there is a third option, but please feel free to tell me, rather 
> than insulting again.


Hi Tyler,

Are you able to use Tkinter-based applications under Windows?
Or you have started to use Linux and now you don't care about the majority 
of users that need to use a screen reader?

Octavian

From: "rantingrick" <rantingrick@gmail.com>
On Jan 23, 5:44 pm, "Martin v. Loewis" <mar...@v.loewis.de> wrote:
> > For something as common as displaying a file browser, it should be as
> > simple as this:
>
> > import gui_toolkit # whichever
> > path = gui_toolkit.select_file()
>
> > Something like zenity:
>
> > [steve@sylar ~]$ zenity --file-selection
> > /home/steve/python/findsingle.py
>
> And indeed, it is that simple:
>
> python -c "import tkFileDialog as tkfd;print tkfd.askopenfilename()"


Martin the tkFileDialog.ask* uses the platform specific Open, Save
dialogs which DO contain a ListCtrl. Obviously this ListCtrl is not
available to Tkinter uses. You just exposed your weak knowledge of
Tkinter and sadly you are very high on the community totem pole. Very
sad :(




Aha, that's why that Open File window was accessible for JAWS screen reader, 
although it uses Tk... because actually it doesn't use Tk.

Octavian

On Sun, Jan 23, 2011 at 5:31 PM, rantingrick <rantingrick@gmail.com> wrote:
> So far only trolls (besides Terry, Octavian, D'Aprano) have replied.
> In my time here within the Python community i have only met one person
> who shares my in-depth knowledge of Tkinter. That person is Kevin
> Waltzer. So outside of Python-dev and Guido. Kevin and I are are the
> ONLY people qualified to offer opinions on the worth or worthlessness
> of Tkinter. If anyone in this entire community thinks that they also
> are qualified then prove your worth by creating a ListCtrl in Tkinter
> that mirrors the wxPython ListCtrl in functionality. When you have
> done that, i will elevate you to my circle of enlightenment. Than and
> only then shall i even entertain you BS.


Wow, someone's certainly feeling very self-important, ignoring the
fact he can't follow conventions nor write cross-platform software.
And before you start, no, I don't want to steal your "file browser".

> Well i did "expect" that you would at least include some info as to
> your OS and version.

OS is Linux, wxPython is Debian python-wxgtk2.6 2.6.3.2.2-5+b1.

> That would be helpful also. Obviously the
> wx.ImageList is barfing. Do you have the Bitmap folder containing the
> three images. Did you try to comment out the "_createImages()" line.

If I do, I get

Traceback (most recent call last):
  File "wxtk_challenge_1.py", line 222, in <module>
    frame = AppFrame()
  File "wxtk_challenge_1.py", line 206, in __init__
    self.listWidget.showDirectory(sys.prefix)
  File "wxtk_challenge_1.py", line 150, in showDirectory
    imageIdx = self.imageMap[iconname]
KeyError: 'folder'

If I then also comment out lines 150..154, I get a window, but it's
empty (of course).

> Simple debug skills we are talking about here Martin, simple. But yet
> again this is only tested on Windows. I clearly noted that in the
> source.

Well Rick, this doesn't make look wxPython any better.

Regards,
Martin

On Jan 23, 11:31=A0am, rantingrick <rantingr...@gmail.com> wrote:
> On Jan 22, 6:07=A0pm, rantingrick <rantingr...@gmail.com> wrote:
>
> > I await any challengers...
>
> So far only trolls (besides Terry, Octavian, D'Aprano) have replied.
> In my time here within the Python community i have only met one person
> who shares my in-depth knowledge of Tkinter. That person is Kevin
> Waltzer. So outside of Python-dev and Guido. Kevin and I are are the
> ONLY people qualified to offer opinions on the worth or worthlessness
> of Tkinter. If anyone in this entire community thinks that they also
> are qualified then prove your worth by creating a ListCtrl in Tkinter
> that mirrors the wxPython ListCtrl in functionality. When you have
> done that, i will elevate you to my circle of enlightenment. Than and
> only then shall i even entertain you BS.
>
> Until then, anyone who tries to devalue my argument is just an
> ignorant troll.

I think I'm qualified, though I guess only you can tell me if I
measure up to your standards. I have 15 years or so of tk development,
though admittedly mostly with Tcl. Most recently I've spent about the
past year and a half with wxPython. For what it's worth, I am the only
person on stackoverflow.com with the "tkinter" badge, which only means
I've answered a bunch of questions on tkinter that others find
helpful, nothing more.

No offense, but your challenge is worthless, and your own entry in the
challenge is remarkably weak. About the only thing you've proven is
that wxPython has some built-in widgets that tkinter does not have,
and that wxPython makes it hard to do cross-platform development. Does
that surprise anyone? I'll give you a challenge: create a vector
graphics program. wxPython doesn't have anything that can compare to
the ease of use and power of tkinter's canvas. What does that prove?
Only that tkinter has widgets wxPython does not. I don't think that
will come as news to anyone. I could easily come up with other
challenges where tkinter shines and wxPython falls flat on its face,
but that proves nothing.

What's really amusing is that your program segfaults on linux yet is
supposed to show wxPython superiority. In my 15-20 years of tk
development, you know how many segfaults I've seen? Approximately
zero. Maybe there was one or two there somewhere, I don't know for
certain. wxPython? It segfaults on me on a weekly basis (literally,
thats not hyperbole). Which is the better toolkit? Fortunately for
wxPython, the segfaults are mostly due to coding errors (typically,
for lack of documentation). For the most part they don't happen once I
release the code.

All your challenges are going to prove is what we already know: both
toolkits have strengths and weaknesses, and neither is perfect. I'll
choose the tkinter binding event handling over wxPython any day of the
week and twice on Sundays. It is _clearly_ and _by_far_ superior in
every way. In fact, of the dozen or so toolkits I've used extensively
over the last 20+ years, nothing comes close to the power of tkinter
bindtags.

The same can be said about tkinter's pack, place and grid geometry
managers over wxPython's sizers. Tkinter wins _hands_down_. Easily.
Not even close. Does that make tkinter better? No, just easier to use
to do layout. Ultimately you can do pretty much the same thing with
wxPython, just with more (and, arguably, less readable) code.

On the other hand, wxPython clearly has more widgets. Some are very
useful for very common tasks, such as file and image browsers.
wxPython has the nice ability to draw on top of any widget, and the
aui library shows a lot of promise. I spend a little less of my time
"rolling my own" with wxPython.

If you're doing a programmers editor it's hard to beat (and hard to
program!) the styledtextctrl available with wxPython. It has features
unique to coding editors that the tkinter text editor does not. That
being said, the tkinter text editor is a marvel of simplicity and
power. A project I'm doing now with a very specialized editor would be
orders of magnitude easier to do with tkinter's text widget.

So, all you've proven is that wxPython has different widgets than
tkinter, and that it's hard to create a cross-platform GUI that looks
nice in wxPython. It would be hard (but not impossible, by any
stretch) for me to duplicate your code. Certainly, it would take more
lines of code but that's about it. OTOH, it would be very difficult
indeed to create a tkinter program that works on windows but segfaults
on linux. That's also quite hard in tkinter.

Frankly, I think a set of real-world challenges for all toolkits would
be useful. The problem is, you have no intention of staging a fair
fight. Your very first choice was to tie the hands of tkinter behind
its back, so it's hard to take your challenge seriously. If you're
serious, you'll find a disinterested third party and ask them to come
up with a handful of use cases for testing toolkits, without giving
them knowledge of which toolkits you intend to test. Anything less
will be just a bunch of grandstanding.

On Jan 23, 8:48=A0pm, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:

> When I run the code snippet Martin provided under Linux, the file
> selection box shows files in columns. That's part of the reason why I
> consider it ugly -- I'm an old Mac guy, and I still dislike file
> selection tools that use the Windows 95 style 2-D layout:
>
> a-file =A0 =A0 =A0e-file =A0 =A0 =A0...
> b-file =A0 =A0 =A0f-file =A0 =A0 =A0y-file
> c-file =A0 =A0 =A0g-file =A0 =A0 =A0z-file
> d-file =A0 =A0 =A0h-file
>
> instead of a simple vertical list:
>
> a-file
> b-file
> c-file
> ...
> z-file
>
> Call me a dinosaur if you will, but I hate horizontal scrolling.


Oh gawd Steven i hope you are just playing devils advocate here
because now you are just being completely ridiculous. And if you want
to see the list in vertical mode push the "Reportveiw" button. Wait,
you *really* are a dinosaur!

On Jan 24, 2:56=A0am, "Martin v. Loewis" <mar...@v.loewis.de> wrote:

> Well Rick, this doesn't make look wxPython any better.

Well Martin this seems to be a Linux problem. And it may be a debian
problem. Every Google search i landed on with wxPython+imagelist
+sefault the user mentioned "debian"...hmm?. Has anybody tested this
on Unbuntu? And if it segfaults on Ubuntu that just means you Linux
guys need to do some debugging and offer a solution instead of
pointing fingers. Linux OS is not a hand holding OS so stop your belly
aching.

All you guys know damn good and we can make wxPython completely cross
platform. However the fact is that you DO NOT want to consider
wxPython so you're NOT going to actually put forth some solutions.
This thread has been an eye opener for myself and many people in the
fact that this community has both lost vision and the apathy is so
demoralizing that we cannot even work together to get some simple code
debugged. The spirit of community, and each helping one another, does
not exists!

Congratulations python community, you have failed yourself! :(

On Jan 23, 5:13=A0pm, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:
> On Sun, 23 Jan 2011 12:23:13 -0800, rantingrick wrote:
> > I am not
> > trying to create a working file browser so you can steal my code.
>
> Dammit! There goes my brilliant idea for getting rich.
>
> Step 1: Start company.
> Step 2: Steal working file browser from Internet.
> Step 4: Profit!
>
> I think rantingrick's comment inadvertently shows in a nutshell
> everything wrong with this thread and why there is so little interest in
> his proposal. If RR is right about the GUI toolkit making or breaking the
> entire Python community, there should be hundreds of people with an
> opinion, not just a handful.
>
> (1) rantingrick is willing to spend *hours* brow-beating people,
> insulting them, and cajoling them into doing things *his* way, supposedly
> because of his deep concern for the Python community, but isn't willing
> to donate a lousy *file browser* to the community.
>
> (2) GUI programming is TOO DAMN HARD, and until that fact is addressed,
> it's difficult for the majority of people to care whether the toolkit
> used (or, more likely, not used at all) is Tkinter, or wxPython, or
> something else.
>
> For something as common as displaying a file browser, it should be as
> simple as this:
>
> import gui_toolkit =A0# whichever
> path =3D gui_toolkit.select_file()

>
You mean like:

>>> import tkFileDialog
>>> path=3DtkFileDialog.askopenfiles()
>>> print path
[<open file '/Users/bryan/Documents/1.gif', mode 'r' at 0x5bf50>]

:-)

(I think the actual point of contention isn't a file dialog, but a
file browser like the windows explorer.

On Jan 23, 7:12=A0pm, rantingrick <rantingr...@gmail.com> wrote:
> On Jan 23, 5:23=A0pm, Kevin Walzer <k...@codebykevin.com> wrote:
>
> > I found this code in the Demo/tkinter/ttk directory of the Python 2.7.1
> > source distribution. I'm NOT the author (credit should probably go to
> > Guilherme Polo, developer of the Tkinter wrapper for the ttk themed
> > widgets that is now in the stdlib). But, using a tree/listview widget
> > that is part of the Tk/Tkinter core (NOT an extension), =A0it presents =
a
> > decent, simple file browser:
>
> > """A directory browser using Ttk Treeview.
>
> The only way i can respond to this is to quite the requirements for my
> challenge...
>
> ---------------------------------------
> =A0Challenge 1: (Simple Directory Viewer)
> ---------------------------------------
> Create a simple Directory Viewer GUI. You CANNOT use a treectrl!
>
> Any questions?

So, what you're saying is, the real challenge you are presenting is
"using the toolkit of your choice, open up a wx.ListCtrl widget".

If you want a fair challenge don't say "you can't use widget X". All
you're trying to prove is that tkinter doesn't have a wx.ListCtrl
widget. I think most people can agree with you on that point.

On Jan 23, 7:33=A0pm, rantingrick <rantingr...@gmail.com> wrote:
> On Jan 23, 7:16=A0pm, Kevin Walzer <k...@codebykevin.com> wrote:
>
>
>
>
>
> > On 1/23/11 8:12 PM, rantingrick wrote:
>
> > > The only way i can respond to this is to quite the requirements for m=
y
> > > challenge...
>
> > > ---------------------------------------
> > > =A0 Challenge 1: (Simple Directory Viewer)
> > > ---------------------------------------
> > > Create a simple Directory Viewer GUI. You CANNOT use a treectrl!
>
> > > Any questions?
>
> > Why not?
>
> > I'd understand if this code made use of some Tk extension, as that's no=
t
> > quite an apples-to-apples comparison. But the treectrl is part of the
> > core Tkinter widget set.
>
> Well wxPython ha a treectrl too. And if we were comparing apples to
> apples then we would compare the wx.TreeCtrl to the Tk::TreeCtrl.
> However there are many things that a ListCtrl can do that a treectrl
> can't. The biggest difference.... COLUMNS
>
> > There's no reason to exclude it (Tk::TreeCtrl) unless you are
> > deliberately trying to handicap Tk in your comparison.
>
> I am not handicapping TclTk. They already did that themselves by
> refusing to keep up with =A021st century GUI libraries. Sure, you can
> say Tkinter is a knife and wxPython is an AK47 but who's to blame when
> you bring a knife to gun fight Kevin? Switch to wx and enjoy the
> bloodbath.

"switch to wx and enjoy the bloodbath"

That has *got* to be quote-of-the-week material. Sometimes when I've
spent a day wrestling with wxPython I do indeed feel like I've been in
a bloodbath!

(I'm not picking on wxPython per se -- it's what I'm using for my
current project -- just that the analogy was perhaps a bit more on
target than rantingrick intended :-)

On Jan 24, 7:13=A0am, Bryan <bryan.oak...@gmail.com> wrote:

> So, what you're saying is, the real challenge you are presenting is
> "using the toolkit of your choice, open up a wx.ListCtrl widget".

read the very first post which outlines the challenge.

> If you want a fair challenge don't say "you can't use widget X". All
> you're trying to prove is that tkinter doesn't have a wx.ListCtrl
> widget. I think most people can agree with you on that point.

Bryan you are clearly an idiot. I am demanding that from now on, you
must have at least a 120 or higher IQ before participating in any of
my threads. Really, if you are an idiot then you should not be allowed
to vote or reproduce. However for this group i may have set the bar
too high!

On Jan 24, 12:06=A0am, rusi <rustompm...@gmail.com> wrote:
> On Jan 24, 9:16=A0am, "Littlefield, Tyler" <ty...@tysdomain.com> wrote:
>
> Of course as Steven pointed out wx is written in C++ which is almost
> certainly where the crash is occurring.
> But this is technical nitpicking.
> The real issue is that when coding in C/C++ segfaults are a daily
> affair.
> Whereas for python its the first time I am seeing it in 10 years...

In my experience, segfaults with wxPython aren't daily, but they are
pretty much weekly. There are weeks that can go by without them, but
then I'll have several in a week to bump up the average.

wxPython is fairly sensitive to coding mistakes, and the documentation
is sufficiently weak that it's easy to make coding mistakes. There are
a lot of things you can do that aren't valid in particular contexts,
and instead of throwing a catchable error you get a segfault. Plus, as
we've seen, it's platform specific. So it's easy to create code that
works great on one platform even with some bad code in it, and that
same code will segfault on another platform.

This shouldn't be enough to keep you from using wxPython, it just
means you have to be a bit more diligent and you can't assume that
your linux code will work on windows or visa versa without testing.
tkinter seems far less susceptible to that. Mostly with tkinter the
platform issues are true platform issues (font availability, file
paths, etc).

From: "Bryan" <bryan.oakley@gmail.com>
> It would be hard (but not impossible, by any
> stretch) for me to duplicate your code. Certainly, it would take more
> lines of code but that's about it. OTOH, it would be very difficult
> indeed to create a tkinter program that works on windows but segfaults
> on linux. That's also quite hard in tkinter.


I doubt you could do a program that offers the same features using Tkinter.
That program will not be accessible for screen readers and this is a big 
problem, a vital problem for those that use a screen reader, because the 
program won't be accessible at all.

Octavian

rantingrick wrote:

> I am demanding that from now on, you
> must have at least a 120 or higher IQ before participating in any of
> my threads.

You mean, you are putting yourself in your own killfile ;)

On Jan 24, 7:24=A0am, Bryan <bryan.oak...@gmail.com> wrote:
> On Jan 24, 12:06=A0am, rusi <rustompm...@gmail.com> wrote:
>
> > On Jan 24, 9:16=A0am, "Littlefield, Tyler" <ty...@tysdomain.com> wrote:
>
> > Of course as Steven pointed out wx is written in C++ which is almost
> > certainly where the crash is occurring.
> > But this is technical nitpicking.
> > The real issue is that when coding in C/C++ segfaults are a daily
> > affair.
> > Whereas for python its the first time I am seeing it in 10 years...
>
> In my experience, segfaults with wxPython aren't daily, but they are
> pretty much weekly.

hmm

> There are weeks that can go by without them, but
> then I'll have several in a week to bump up the average.

Yes, and this could not be your problem, it must be wxPython. Right?
*rolls-eyes*


> wxPython is fairly sensitive to coding mistakes,

Oh so now we get the picture...

>  and the documentation
> is sufficiently weak that it's easy to make coding mistakes.

That is somewhat true.


>  There are
> a lot of things you can do that aren't valid in particular contexts,
> and instead of throwing a catchable error you get a segfault.

And we need to fix that instead just disqualifying a feature rich
toolkit.

> Plus, as
> we've seen, it's platform specific. So it's easy to create code that
> works great on one platform even with some bad code in it, and that
> same code will segfault on another platform.

Again, were is the community spirit. I have windows and you have
linux. Let's write some code and do cross testing and then fix the
bugs.

> This shouldn't be enough to keep you from using wxPython, it just
> means you have to be a bit more diligent and you can't assume that
> your linux code will work on windows or visa versa without testing.

Thank you!

> tkinter seems far less susceptible to that. Mostly with tkinter the
> platform issues are true platform issues (font availability, file
> paths, etc).

Yes because Tkinter is lacking. Because Tkinter is not even half the
library that wx is.

2011/1/24 rantingrick <rantingrick@gmail.com>:
> On Jan 24, 2:56=A0am, "Martin v. Loewis" <mar...@v.loewis.de> wrote:
>
>> Well Rick, this doesn't make look wxPython any better.
>
> Well Martin this seems to be a Linux problem. And it may be a debian
> problem. Every Google search i landed on with wxPython+imagelist
> +sefault the user mentioned "debian"...hmm?. Has anybody tested this
> on Unbuntu? And if it segfaults on Ubuntu that just means you Linux
> guys need to do some debugging and offer a solution instead of
> pointing fingers. Linux OS is not a hand holding OS so stop your belly
> aching.
>
> All you guys know damn good and we can make wxPython completely cross
> platform. However the fact is that you DO NOT want to consider
> wxPython so you're NOT going to actually put forth some solutions.
> This thread has been an eye opener for myself and many people in the
> fact that this community has both lost vision and the apathy is so
> demoralizing that we cannot even work together to get some simple code
> debugged. The spirit of community, and each helping one another, does
> not exists!
>
> Congratulations python community, you have failed yourself! :(
> --
> http://mail.python.org/mailman/listinfo/python-list
>

This is nonsense and you are clearly a troll. =3D)


--- Giampaolo Rodol=E0
http://code.google.com/p/pyftpdlib/
http://code.google.com/p/psutil/

On 1/24/11 1:52 AM, Octavian Rasnita wrote:

>
> Well, I have also tested the program dirbrowser.py, but it is not decent
> at all.
> I have tested it with JAWS screen reader and it is absolutely inaccessible.
>
> The single "accessible" things in it are the title bar which is "tk".
> It can't compare with the same program made using WxPython.
> And it can't be made to be more accessible than it is, because it uses Tk.
>
> So Tkinter is really bad.

If accessibility leads your criteria, then yes, Tk may be deficient. I 
can't speak to this on other platforms or with other toolkits.

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

On 1/24/11 8:24 AM, rantingrick wrote:

>
> Bryan you are clearly an idiot. I am demanding that from now on, you
> must have at least a 120 or higher IQ before participating in any of
> my threads. Really, if you are an idiot then you should not be allowed
> to vote or reproduce. However for this group i may have set the bar
> too high!

Rick,

I've tried to give you the benefit of the doubt during this discussion, 
but I've had enough. Bryan Oakley is no idiot. You said elsewhere in 
this thread that my expertise with Tkinter was worth something, but 
Bryan's is worth far more. He is one of the foremost Tcl/Tk developers 
alive, author of many widely-used Tk widgets, and a long-term helpful 
presence on comp.lang.tcl. He's patiently answered many inflammatory 
questions from inexperienced or arrogant developers, and I've learned a 
tremendous amount from him. Job circumstances forced him to move into 
Python development a few years ago, and he now uses wxPython on a daily 
basis, while being active on Stack Overflow and elsewhere with answering 
questions about Tkinter.  In short, I'd have a hard time imagining 
anyone more qualified to compare wxPython and Tkinter than Bryan Oakley.

Also, it's not helpful for you to respond to people who disagree with 
you with this kind of name-calling. It certainly does not earn any 
respect for your arguments.

--Kevin

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

On Jan 24, 6:33=A0am, Bryan <bryan.oak...@gmail.com> wrote:

> I think I'm qualified, though I guess only you can tell me if I
> measure up to your standards.

Go on...

> I have 15 years or so of tk development,
> though admittedly mostly with Tcl. Most recently I've spent about the
> past year and a half with wxPython.

A year and a half and you are still producing buggy code? (you
yourself admitted this!)

> For what it's worth, I am the only
> person on stackoverflow.com with the "tkinter" badge, which only means
> I've answered a bunch of questions on tkinter that others find
> helpful, nothing more.

Well could we see a link to a few answered questions or get your nick
so we can corroborate this statement ourselves?

> No offense, but your challenge is worthless, and your own entry in the
> challenge is remarkably weak.

First rule when given a challenge you cannot answer due to ignorance:
question the validity of the challenge.

>  About the only thing you've proven is
> that wxPython has some built-in widgets that tkinter does not have,

Well this is ONLY the first challenge Bryan. More will come. However,
not until someone has the balls to answer my first challenge.

> and that wxPython makes it hard to do cross-platform development.

I don't think that is completely accurate Bryan. Harder than Tkinter,
yes. Anything else is hyperbole.

> Does
> that surprise anyone? I'll give you a challenge: create a vector
> graphics program.

Answer my challenge first, then we talk. And obviously you do not
understand the power of wx's Open Graphics Library (OGL). You'd better
go check that out before you stick your Tkinter loving foot into your
big mouth.

> wxPython doesn't have anything that can compare to
> the ease of use and power of tkinter's canvas.

Thats more uninformed BS. You are really hurting your public image
here bryan!

> What does that prove?
> Only that tkinter has widgets wxPython does not. I don't think that
> will come as news to anyone. I could easily come up with other
> challenges where tkinter shines and wxPython falls flat on its face,

And these challenges are what? You see when you make empty challenges
like this you look dumb.

> What's really amusing is that your program segfaults on linux yet is
> supposed to show wxPython superiority.

Segfault or not wx is superior.

> In my 15-20 years of tk
> development, you know how many segfaults I've seen? Approximately
> zero.

BULLSHITE!

> Maybe there was one or two there somewhere,

Ah yes, the old conscience catches up fast to the habitual liars.

> I don't know for
> certain.

Finally some truth!

> wxPython? It segfaults on me on a weekly basis (literally,
> thats not hyperbole).

LIAR! LIAR! PANTS ON FIRE!
------------bryan-------------
In my experience, segfaults with wxPython aren't daily, but they are
pretty much weekly. There are weeks that can go by without them
------------bryan-------------

> Which is the better toolkit? Fortunately for
> wxPython, the segfaults are mostly due to coding errors

Yea, ya think?

> For the most part they don't happen once I
> release the code.

And yet you cannot offer a solution for this segfault. Interesting.

> All your challenges are going to prove is what we already know: both
> toolkits have strengths and weaknesses, and neither is perfect.

And sadly that IS ALL you know. More fruits must be weighed in this
decision. Like the fact that Tkinter is legacy and wxPython is current
technology.

>  I'll
> choose the tkinter binding event handling over wxPython any day of the
> week and twice on Sundays.

So will i. We should change the wxPython API!

> It is _clearly_ and _by_far_ superior in
> every way.

True. We should change the wxPython API!

> In fact, of the dozen or so toolkits I've used extensively
> over the last 20+ years, nothing comes close to the power of tkinter
> bindtags.

*yawn*. Guido's advocate!

> The same can be said about tkinter's pack, place and grid geometry
> managers over wxPython's sizers.

Agreed! We should change the wxPython API!

> Does that make tkinter better? No, just easier to use
> to do layout.

Agreed! Because if we were really smart we would just change the
wxPython API so that we have the simplicity of Tkinter and the feature
richness of wxPython. See wax for ideas...

   http://wiki.wxpython.org/Wax

> Ultimately you can do pretty much the same thing with
> wxPython, just with more (and, arguably, less readable) code.

Wrong. You can do much much more with wxPython. The ugliness of the
code depends on the coders ability to create good or bad code.

> On the other hand, wxPython clearly has more widgets. Some are very
> useful for very common tasks, such as file and image browsers.

and spreadsheets, and validated input, and multi-choice directory
choosing, and multi choice lists, and Rich Text, and book controls,
and Calendars, and Toolbars, and full image support, and masked edit
controls, and scrolled panels, and styled text, and print support, and
listctrl, and virtual listctrl and editable list ctrl, and REAL
DND ,and GC, and GLCanvas, and JoyStick, and OGL, and shaped windows,
and more, more, more...

> wxPython has the nice ability to draw on top of any widget, and the
> aui library shows a lot of promise. I spend a little less of my time
> "rolling my own" with wxPython.

You will always spend less time rolling in wxPython.

> If you're doing a programmers editor it's hard to beat (and hard to
> program!) the styledtextctrl available with wxPython. It has features
> unique to coding editors that the tkinter text editor does not. That
> being said, the tkinter text editor is a marvel of simplicity and
> power. A project I'm doing now with a very specialized editor would be
> orders of magnitude easier to do with tkinter's text widget.

Which do you want, simplistic confinement or expansive elegance. You
can't have both. And besides. One could easily create a simplistic
"Tkinter like" textbox API using wxPython. You lack vision Bryan. We
can bring all this into reality!

> It would be hard (but not impossible, by any
> stretch) for me to duplicate your code.

PUT UP OR SHUT THE HELL UP!

 >Or you have started to use Linux and now you don't care about the 
majority of >users that need to use a screen reader?
I said nothing the like. TkInter does have problemns with Jaws, but I'm 
not going to sit here and say the same thing over and over as you are 
doing. Get off the soapbox already.
On 1/23/2011 11:58 PM, Octavian Rasnita wrote:
> From: "Littlefield, Tyler" <tyler@tysdomain.com>
>> >PS: Be sure not to cause any segfaults because these linux folks can't
>> >debug for shite!
>> Or maybe it is that the person fighting and throwing insults around 
>> like candy at a parade can't code for shite. Or *gasp* the library 
>> that is supposedly cross-platform has issues on certain platforms. 
>> You provided a challenge to show how superior wxPython was. If it 
>> segfaults, that tells me that: 1) you can't code worth "shite," or 2) 
>> the library you are drooling over sucks and shouldn't be 
>> cross-platform. Which is it? I highly doubt there is a third option, 
>> but please feel free to tell me, rather than insulting again.
>
>
> Hi Tyler,
>
> Are you able to use Tkinter-based applications under Windows?
> Or you have started to use Linux and now you don't care about the 
> majority of users that need to use a screen reader?
>
> Octavian
>


-- 

Thanks,
Ty

On Jan 24, 7:48=A0am, Kevin Walzer <k...@codebykevin.com> wrote:

> Rick,
>
> I've tried to give you the benefit of the doubt during this discussion,
> but I've had enough. Bryan Oakley is no idiot.

He is obviously lying to discredit me. And I have posted evidence of
his hyperbole.

> You said elsewhere in
> this thread that my expertise with Tkinter was worth something, but
> Bryan's is worth far more. He is one of the foremost Tcl/Tk developers
> alive, author of many widely-used Tk widgets, and a long-term helpful
> presence on comp.lang.tcl. He's patiently answered many inflammatory
> questions from inexperienced or arrogant developers, and I've learned a
> tremendous amount from him. Job circumstances forced him to move into
> Python development a few years ago, and he now uses wxPython on a daily
> basis, while being active on Stack Overflow and elsewhere with answering
> questions about Tkinter. =A0In short, I'd have a hard time imagining
> anyone more qualified to compare wxPython and Tkinter than Bryan Oakley.

Yet he has NO knowledge of wxPython and his Tkinter knowledge is
lacking.

> Also, it's not helpful for you to respond to people who disagree with
> you with this kind of name-calling. It certainly does not earn any
> respect for your arguments.

Well i agree with that. However these people keep coming back with the
same BS arguments...

 * the challenge is impossible.

No the challenge is not impossible to complete. However due to
Tkinters lacking richness. It is impossible to win against wxPython.
So they resort to all this BS because they KNOW they cannot win. Just
admit that wxPython wins this round and i'll move on to the next
challenge.

 * wxPython is not cross platform.

Total BS.

 * Yes wxPython has many widgets but most are not useful.

Even more BS.

And you wonder why i call people ignorant? I did give them the benefit
of the doubt before saying these things. Bryan has yet to post any
links so i can corroborate his "Tkinter" guru status. He has also
clearly lied many times in his posts (which i have documented). And
most importantly no one but myself has offered any code.

On Jan 24, 7:24=A0am, Bryan <bryan.oak...@gmail.com> wrote:
> On Jan 24, 12:06=A0am, rusi <rustompm...@gmail.com> wrote:
>
> > On Jan 24, 9:16=A0am, "Littlefield, Tyler" <ty...@tysdomain.com> wrote:
>
> > Of course as Steven pointed out wx is written in C++ which is almost
> > certainly where the crash is occurring.
> > But this is technical nitpicking.
> > The real issue is that when coding in C/C++ segfaults are a daily
> > affair.
> > Whereas for python its the first time I am seeing it in 10 years...
>
> In my experience, segfaults with wxPython aren't daily, but they are
> pretty much weekly. There are weeks that can go by without them, but
> then I'll have several in a week to bump up the average.


I've only run my code on Windows and Linux, but I haven't had this
issue. The only time I've had segfaults was when I was first learning
how to get threading and wx to work properly and when I was creating
binaries with py2exe.

On a completely different note, as a heavy wxPython user for almost 5
years, I have never seen the OP on our mailing list, dev group or IRC
channel. While I like wx more than Tk, I think this thread is a
terrible way to try to show that wx is better. I like the concept of
creating a challenge to see which toolkit can do what, but this is not
the way to go about it.

Bryan, on the other hand, has been a Tkinter luminary who has helped
me in the past when I was learning Tkinter and I won't be too
surprised if he helps me again. I'm sorry he's had so much trouble
with wx though.

-------------------
Mike Driscoll

Blog:   http://blog.pythonlibrary.org

On Jan 24, 8:49=A0am, Mike Driscoll <kyoso...@gmail.com> wrote:
> On Jan 24, 7:24=A0am, Bryan <bryan.oak...@gmail.com> wrote:

> > In my experience, segfaults with wxPython aren't daily, but they are
> > pretty much weekly. There are weeks that can go by without them, but
> > then I'll have several in a week to bump up the average.
>
> I've only run my code on Windows and Linux, but I haven't had this
> issue. The only time I've had segfaults was when I was first learning
> how to get threading and wx to work properly and when I was creating
> binaries with py2exe.

Thanks. I knew these guys were full of it.

> On a completely different note, as a heavy wxPython user for almost 5
> years, I have never seen the OP on our mailing list, dev group or IRC
> channel.

Thats because i have not been there. And yet i can produce code (maybe
not perfectly). However those that have been around wx list for longer
cannot. Interesting.

> I like the concept of
> creating a challenge to see which toolkit can do what, but this is not
> the way to go about it.

Well by all means offer some input. You have offered opinions but no
ideas. I would love to hear any ideas you may have. And yes, Tkinter
has a very likable API. I have mentioned this fact many times and in
many threads. However when weighed on all factors wx will win. Because
even though we may need to mold the wx API a bit, at least with wx we
have a solid feature rich platform to work from.

> Bryan, on the other hand, has been a Tkinter luminary who has helped
> me in the past when I was learning Tkinter and I won't be too
> surprised if he helps me again. I'm sorry he's had so much trouble
> with wx though.

:)

On 2011-01-24, rantingrick <rantingrick@gmail.com> wrote:

> Bryan you are clearly an idiot. I am demanding that from now on, you
> must have at least a 120 or higher IQ before participating in any of
> my threads.

Rantingrick thinks certain threads belong to him.

'nuf said.

-- 
Grant Edwards               grant.b.edwards        Yow! I'm gliding over a
                                  at               NUCLEAR WASTE DUMP near
                              gmail.com            ATLANTA, Georgia!!

On 2011-01-24, Corey Richardson <kb1pkl@aim.com> wrote:

> Python (and supposedly wxPython) are cross-platform. Code that runs on 
> one should run on the other unmodified.

No, that's not what "cross-platform" really means.  Cross-platform
means that it's possible (and reasonably stright-forward) to write
code that will run unmodified on multiple platforms.  It doesn't mean
that it's impossible to write code that will only work on one
platform.

-- 
Grant Edwards               grant.b.edwards        Yow! Someone in DAYTON,
                                  at               Ohio is selling USED
                              gmail.com            CARPETS to a SERBO-CROATIAN

On Jan 24, 10:13=A0am, Grant Edwards <inva...@invalid.invalid> wrote:
> On 2011-01-24, rantingrick <rantingr...@gmail.com> wrote:
>
> > Bryan you are clearly an idiot. I am demanding that from now on, you
> > must have at least a 120 or higher IQ before participating in any of
> > my threads.
>
> Rantingrick thinks certain threads belong to him.

No these are free and open forums and all are welcome to come and
listen to what i say :).

Notice i only specified an IQ level and i made no demands as to how
much Python knowledge was required. You can be a noob or a pro and
participate. However i am not about to entertain trolls and ignorants
because these people do not have the basic tools to contribute
anything helpful. Whereas someone who has meager Python skills (but a
reasonable IQ) CAN participate in lively and coherent debate all the
while contributing in a positive way. These are the people i want to
talk with. Some have dropped in already but failed to offer good
debate. NOW IS YOUR CHANCE!

Many folks here don't understand how to contribute in a positive way.
NEWSFLASH! You can both disagree with me AND contribute to the debate
in a positive way at the same time. Oh yes! One example would be for
the "Linux whiners" to post a fix to my example code. If they are not
going to answer the challenge with Tkinter code, then they should at
least fix ONE measly little bug to prove their worth to this
community. So far you have all failed BOTH challenges.

On Jan 24, 9:02=A0am, rantingrick <rantingr...@gmail.com> wrote:
> On Jan 24, 8:49=A0am, Mike Driscoll <kyoso...@gmail.com> wrote:
>
> > On Jan 24, 7:24=A0am, Bryan <bryan.oak...@gmail.com> wrote:
> > > In my experience, segfaults with wxPython aren't daily, but they are
> > > pretty much weekly. There are weeks that can go by without them, but
> > > then I'll have several in a week to bump up the average.
>
> > I've only run my code on Windows and Linux, but I haven't had this
> > issue. The only time I've had segfaults was when I was first learning
> > how to get threading and wx to work properly and when I was creating
> > binaries with py2exe.
>
> Thanks. I knew these guys were full of it.


Not necessarily. He may been using some of the generic widgets, like
the agw stuff. The agw set is awesome, but they haven't been tested
extensively on anything other than Windows because their author is a
Windows programmer.



> > I like the concept of
> > creating a challenge to see which toolkit can do what, but this is not
> > the way to go about it.
>
> Well by all means offer some input. You have offered opinions but no
> ideas. I would love to hear any ideas you may have. And yes, Tkinter
> has a very likable API. I have mentioned this fact many times and in
> many threads. However when weighed on all factors wx will win. Because
> even though we may need to mold the wx API a bit, at least with wx we
> have a solid feature rich platform to work from.
>


I haven't gotten my ideas fleshed out yet. When I do, I will describe
them.

-------------------
Mike Driscoll

Blog:   http://blog.pythonlibrary.org

From: "Littlefield, Tyler" <tyler@tysdomain.com>
> >Or you have started to use Linux and now you don't care about the=20
> majority of >users that need to use a screen reader?
> I said nothing the like. TkInter does have problemns with Jaws, but =
I'm=20
> not going to sit here and say the same thing over and over as you are=20
> doing. Get off the soapbox already.


If something's wrong, the people need to know that what they like is =
wrong and the wrong things need to be changed with something better. And =
I just shown why Tkinter is a very bad tool.
I'm not in love with wxWIDGETS because they also provide a few widgets =
which have problems. I like MFC, but unfortunately it is not portable.

Octavian

Octavian Rasnita wrote:
> From: "rantingrick" <rantingrick@gmail.com>
>> WxPython versus Tkinter (A code battle to the death!)
>>
>> by Rick Johnson.
[...]

Octavian,

Please do not repost rr's crap in its entirety, or you'll find yourself 
added to many killfiles -- just like he is.

~Ethan~

On Jan 24, 7:32=A0am, Peter Otten <__pete...@web.de> wrote:
> rantingrick wrote:
> > I am demanding that from now on, you
> > must have at least a 120 or higher IQ before participating in any of
> > my threads.
>
> You mean, you are putting yourself in your own killfile ;)

:)

Actually i never use the killfile and never will. The main reason is
because i believe in the old adage: "Keep friends close and enemies
closer". But i don't have any enemies here (as far as i am concerned).

However the real reason i will not use the killfile is because i
believe that people can change. Even very wise people are not immune
to bad decisions. Case in point: My initial disgust with Ruby was
completely unfounded. Ruby has a lot to offer the programming world
and while it is not my preferred language, we as Python programmers
can learn much from Ruby and likewise Ruby can learn from us. I was
being a closed minded idiot at the time. I have since evolved.

In any event the killfile only serves as instant gratification for the
selfish "one dimensional" folks among us. If you are so fearful of
someone's words that you must hide your eyes from them then you lack
basic self control. And in the end, the only thing you kill is your
own humanity. :(

On Jan 24, 10:38=A0am, Mike Driscoll <kyoso...@gmail.com> wrote:

> I haven't gotten my ideas fleshed out yet. When I do, I will describe
> them.

I look forward to any proposals and i would like to be a part of this
challenge both for wxPython and Tkinter since i have used both.

 "Octavian Rasnita" <orasnita@gmail.com> wrote:
> But unfortunately it is not accessible for screen readers and it 
> discriminates many potential users.



Octavian, thank you for very clearly making and repeating your point 
about screen readers.  It is very obvious that at this point in time Tk 
(and hence Tkinter) is not a suitable candidate if screen readers are an 
important concern.

In an ideal world, every GUI would be fully accessible.  The reality is 
that sometimes, competing requirements will lead to accessibility being 
lower in the priority list than other things.  So with different 
requirements and priorities, the "best" solution will be different.

I don't object and in fact commend you for advocating for accessibility.  
I do feel you are not acknowledging and fully respecting that others may 
be in situations where accessibility may not be the primary concern.  

Thanks again
Mark

On Jan 24, 11:39=A0am, Mark Roseman <m...@markroseman.com> wrote:
> =A0"Octavian Rasnita" <orasn...@gmail.com> wrote:
>
> > But unfortunately it is not accessible for screen readers and it
> > discriminates many potential users.
>
> Octavian, thank you for very clearly making and repeating your point
> about screen readers. =A0It is very obvious that at this point in time Tk
> (and hence Tkinter) is not a suitable candidate if screen readers are an
> important concern.
>
> In an ideal world, every GUI would be fully accessible. =A0The reality is
> that sometimes, competing requirements will lead to accessibility being
> lower in the priority list than other things. =A0So with different
> requirements and priorities, the "best" solution will be different.
>
> I don't object and in fact commend you for advocating for accessibility. =
=A0
> I do feel you are not acknowledging and fully respecting that others may
> be in situations where accessibility may not be the primary concern. =A0

Why don't you just tell him to shut the hell up Mark? Anyone can see
that SHUT THE HELL UP is what you are implying here. Obviously you
guys are worried terribly about accessibility hurting your "one
dimensional" position of supporting the legacy TclTk. Otherwise you
would not make veiled threats like this. Your post is an obvious
veiled threat to anyone of average intelligence!

Octavian has already been threatened with the kill file by Ethan for
accidentally quoting me too much. You guys are very disappointing to
this community. Everyone here needs a voice. We must never engage in
behaviors that would limit speech from our community members who have
the intelligence to offer reasonable arguments. Octavian is not a
troll or spammer and should not be treated as such! Stop this
threating of our community members NOW!

On Jan 24, 7:27=A0am, "Octavian Rasnita" <orasn...@gmail.com> wrote:
> From: "Bryan" <bryan.oak...@gmail.com>
>
> > It would be hard (but not impossible, by any
> > stretch) for me to duplicate your code. Certainly, it would take more
> > lines of code but that's about it. OTOH, it would be very difficult
> > indeed to create atkinterprogram that works on windows but segfaults
> > on linux. That's also quite hard intkinter.
>
> I doubt you could do a program that offers the same features usingTkinter=
..
> That program will not be accessible for screen readers and this is a big
> problem, a vital problem for those that use a screen reader, because the
> program won't be accessible at all.
>
> Octavian

I wish I could respond to that, but I have no experience with screen
readers.  Are there any free ones, or ones with free trials, that I
could try out? I'm not yet convinced it's any better or worse than
wxPython since you're only a single datapoint, but of course it's
possible. If you know of any free tools I can use to experiment, I'd
appreciate you posting them in this newsgroup.

Accessibility, like internationalization, is something few programmers
spend much time thinking about. I can only imagine the frustration one
must experience if all interactions had to be through a screen reader.

On Jan 24, 12:00=A0pm, Bryan <bryan.oak...@gmail.com> wrote:

> Accessibility, like internationalization, is something few programmers
> spend much time thinking about.

Thats another uninformed statement by you we can add to the mountains
of useless cruft you have offered so far. Unicode IS
internationalization and Guido thought it was SO important that
Python3000 auto converts all strings to Unicode strings. Obviously he
is moving us toward full Unicode only in the future (AS SHOULD ALL
IMPLEMENTATIONS!). We need one and only one obvious way to do it. And
Unicode is that way.

On Jan 24, 7:32=A0am, rantingrick <rantingr...@gmail.com> wrote:
> On Jan 24, 7:24=A0am, Bryan <bryan.oak...@gmail.com> wrote:
>
> > On Jan 24, 12:06=A0am, rusi <rustompm...@gmail.com> wrote:
>
> > > On Jan 24, 9:16=A0am, "Littlefield, Tyler" <ty...@tysdomain.com> wrot=
e:
>
> > > Of course as Steven pointed out wx is written in C++ which is almost
> > > certainly where the crash is occurring.
> > > But this is technical nitpicking.
> > > The real issue is that when coding in C/C++ segfaults are a daily
> > > affair.
> > > Whereas forpythonits the first time I am seeing it in 10 years...
>
> > In my experience, segfaults withwxPythonaren't daily, but they are
> > pretty much weekly.
>
> hmm
>
> > There are weeks that can go by without them, but
> > then I'll have several in a week to bump up the average.
>
> Yes, and this could not be your problem, it must bewxPython. Right?
> *rolls-eyes*

Correct. A scripting language should *never* segfault. If it does, it
is a bug in the language or library.

It is a provable fact that wxPython segfaults. You yourself proved
that. That is, in and of itself, *not* a reason to pick some other
toolkit. It's merely a datapoint. It's not a datapoint you can just
sweep under the rug, however, like you seem to want to do.

>
> > =A0There are
> > a lot of things you can do that aren't valid in particular contexts,
> > and instead of throwing a catchable error you get a segfault.
>
> And we need to fix that instead just disqualifying a feature rich
> toolkit.

I think if you re-read my post you'll see I don't disqualify it as a
rich toolkit. wxPython is a fine toolkit. Better than tkinter in some
ways, worse in others. segfaults is one aspect in which it is
measurably worse.

Hello,

I have been on another list with Octavian, and he takes his 
accessibility a bit to seriously. If things went his way, he wants laws 
where -everything- has to be accessible, and it is illegal not to do so. 
As a sidenote, I would like to preface everything I'm going to say by 
mentioning the fact that I have been using a screen reader for many 
years, so I understand some of where he is coming from.

I think my goal, (and I differ from Octavian here), is to try to find 
fixes for things, rather than saying "this sucks, it does not work with 
a reader, and thus it shouldn't be used). Having done a lot of 
development work in the past, I can't say "hey you, I want you to make 
this app accessible, and because you used TKInter it's not, so use 
something else, but nothing that isn't accessible." Rather, I believe 
those pushing accessibility should concentrate on the root cause; that 
of fixing TKInter, and not forcing everyone else to use a different library.

I believe that the approach is the main key here, and I have had this 
argument many times. If I wrote an app, and someone said something along 
the lines of "you need to change a core library because it doesn't work 
with this program," my first response would be who the hell are you to 
say what I need to use? We need to take the approach of "This is what is 
wrong, this is why, this is possibly how it could be fixed. Would you be 
willing to do so?"

So, with all of this said, TKInter -is- unaccesssible for us. My 
arguments have not been for or against one or the other in this thread, 
but more to get RR to make a better point. Because eventually, WX would 
benafit those using a screen reader a lot more than say, TKInter will. 
That doesn't mean that I'm saying that we need to make it a part of the 
stdlib as of yesterday, because segfaults from someone with 10+ years of 
experience (multiple people, actually) says a lot, whether or not RR 
wants to acknowledge said facts. I can not with good conchence say that 
the switch should be done just for accessibility purposes. Obviously it 
would be awesome, but I think Octavian is just focusing on himself, and 
not the actual big picture here.

On Jan 24, 12:11=A0pm, Bryan <bryan.oak...@gmail.com> wrote:

> It is a provable fact that wxPython segfaults. You yourself proved
> that. That is, in and of itself, *not* a reason to pick some other
> toolkit. It's merely a datapoint. It's not a datapoint you can just
> sweep under the rug, however, like you seem to want to do.

Ok, now you are talking with facts and we can have a real debate!

Yes wxPython can be made to segfault by the user in some
circumstances. And YES this is very undesirable and it is the direct
product of a poorly written API. However! I do not blame the wxPython
creators or even Robin Dunn himself for this problem. Robin has stated
many times that he wants to keep wxPython as close to wxWidgets as
possible and he also said there is room for a "top level" API. This is
why wxPython proper has no business in the stdlib! We need an
abstraction API written in Python. So my point is, we need to create
this API independent of wxPython. You can think of it as "wx-inter" if
you like.

> I think if you re-read my post you'll see I don't disqualify it as a
> rich toolkit. wxPython is a fine toolkit. Better than tkinter in some
> ways, worse in others. segfaults is one aspect in which it is
> measurably worse.

Again: good argument! And i stand on my last reply. If you would be
interested i would like to work on this abstraction API with you. Are
you interested? How free are you? We need to work together to solve
this problem.

Mark Roseman wrote:
> 
> I don't object and in fact commend you for advocating for accessibility.  
> I do feel you are not acknowledging and fully respecting that others may 
> be in situations where accessibility may not be the primary concern.  

Well said.

~Ethan~

Bryan: Here's a pretty good list for you.
Windows:
Jaws for Windows (http://freedomscientific.com). Not free, but you get a 
40 minute demo before you need to reboot.
Nonvisual Desktop Access: http://www.nvda-project.org/
Free, open source, written in python (with some core stuff in c/c++).
Linux:
Orca live.gnome.org/Orca
Fre, open source. If you don't want to install that bloated mess on a 
box (I sympathise), and you can grab a vmware vinux or a live cd or 
whatever from:
http://vinux.org.uk
OSX:
OSX comes built in with Voiceover, just hold down the command key and 
hit F5. Use the same keystroke to turn it off.
Enjoy!

On Mon, Jan 24, 2011 at 5:57 PM, rantingrick <rantingrick@gmail.com> wrote:

> Why don't you just tell him to shut the hell up Mark?

> accidentally quoting me too much. You guys are very disappointing to
> this community. Everyone here needs a voice. We must never engage in
> behaviors that would limit speech from our community members who have
> the intelligence to offer reasonable arguments. Octavian is not a
> troll or spammer and should not be treated as such! Stop this
> threating of our community members NOW!

Oh, the irony. It's not so much what you're saying, but the way you're
saying it. You're not allowed to treat people like that - no matter
how much you *think* you're right. You've done nothing but accuse
anyone disagreeing with you of being a troll and then proceed to curse
them. I don't know why you're surprised people won't discuss matters
with you. It sounds like you have a lot of growing up you need to do.

On Jan 24, 8:15=A0am, rantingrick <rantingr...@gmail.com> wrote:
> On Jan 24, 6:33=A0am, Bryan <bryan.oak...@gmail.com> wrote:
>
> > I think I'm qualified, though I guess only you can tell me if I
> > measure up to your standards.
>
> Go on...
>
> > I have 15 years or so of tk development,
> > though admittedly mostly with Tcl. Most recently I've spent about the
> > past year and a half withwxPython.
>
> A year and a half and you are still producing buggy code? (you
> yourself admitted this!)

Of course! You'll not find a single programmer who creates bug-free
code.

(I'm beginning to think we're dealing with a software-based troll
programmed to focus in on specific words in order to set up strawman
arguments)

>
> > For what it's worth, I am the only
> > person on stackoverflow.com with the "tkinter" badge, which only means
> > I've answered a bunch of questions ontkinterthat others find
> > helpful, nothing more.
>
> Well could we see a link to a few answered questions or get your nick
> so we can corroborate this statement ourselves?

Sure! I don't feel compelled to answer your demands but this one is
harmless enough.

http://stackoverflow.com/users/7432/bryan-oakley

if you want, you can also do a search on google groups for my other
email address "oakley@bardo.clearlight.com". I have a history in
comp.lang.tcl that goes back to almost the dawn of time. I'm the 8th
most prolific poster (and pretty much all answers, very few
questions), though I'd be higher except I used a different email for a
year or so back in 2002-2004

http://groups.google.com/group/comp.lang.tcl/about

>
> > No offense, but your challenge is worthless, and your own entry in the
> > challenge is remarkably weak.
>
> First rule when given a challenge you cannot answer due to ignorance:
> question the validity of the challenge.

And the first rule for dealing with someone who gives facts that don't
agree with you is to call them names.

>
> > =A0About the only thing you've proven is
> > thatwxPythonhas some built-in widgets thattkinterdoes not have,
>
> Well this is ONLY the first challenge Bryan. More will come. However,
> not until someone has the balls to answer my first challenge.

Honestly, your challenge is childish. The rules are self-serving and
the outcome proves nothing. Your challenge serves nothing but to prove
wxPython has a built-in widget that tkinter does not. Nobody disputes
that. Proving it in code is pointless when it's a well known,
documented fact.

>
> > and thatwxPythonmakes it hard to do cross-platform development.
>
> I don't think that is completely accurate Bryan. Harder thanTkinter,
> yes. Anything else is hyperbole.
>
> > Does
> > that surprise anyone? I'll give you a challenge: create a vector
> > graphics program.
>
> Answer my challenge first, then we talk. And obviously you do not
> understand the power of wx's Open Graphics Library (OGL). You'd better
> go check that out before you stick yourTkinterloving foot into your
> big mouth.

I stand corrected. It was early, that was the first thing that came to
mind. <shrug>

>...
> > What's really amusing is that your program segfaults on linux yet is
> > supposed to showwxPythonsuperiority.
>
> Segfault or not wx is superior.

I don't know if you realize it, but that's a funny statement.

>
> > In my 15-20 years of tk
> > development, you know how many segfaults I've seen? Approximately
> > zero.
>
> BULLSHITE!

No, seriously. Tcl/tk and python/tkinter are both remarkably stable in
this regard. You want a programming challenge? Try creating an app
using either of those combinations to get a segfault. I'm not saying
it can't be done, but it _is_ challenging.

> ...
> LIAR! LIAR! PANTS ON FIRE!

Ok, now I'm pretty certain I'm responding to a bot. Time to move on.

On Jan 24, 12:21=A0pm, "Littlefield, Tyler" <ty...@tysdomain.com> wrote:

[...snip: good discussion...]

>  Rather, I believe
> those pushing accessibility should concentrate on the root cause; that
> of fixing TKInter, and not forcing everyone else to use a different libra=
ry.

Now you go too far!

And this is an ironic position from someone who supports the stdlib
GUI that IS forced on us by default. Sure you can choose a different
library, but in the case of a user (and accessibility is a big USER
concern when that user is handicapped!) the library is already chosen
(Tkinter:which does not support accessibility) by the developer . I
can also argue that Tkinter's inclusion in the stdlib is proliferating
non-compliance with accessibility. I'll bet you would not park in a
handicap spot however you support a GUI library that ignores handicap
people? IRONIC!

> I believe that the approach is the main key here, and I have had this
> argument many times. If I wrote an app, and someone said something along
> the lines of "you need to change a core library because it doesn't work
> with this program," my first response would be who the hell are you to
> say what I need to use?

Well these people you are chastising are disabled people. Who the hell
are YOU to be high and mighty about it? I guess these "disabled"
people get what they deserve huh! Maybe we should just do the world a
favor and exterminate them like the Nazis? That way we don't have to
cater to their selfish needs!

> We need to take the approach of "This is what is
> wrong, this is why, this is possibly how it could be fixed. Would you be
> willing to do so?"

WE ALL NEED TO TAKE THAT APPROACH TYLER, INCLUDING YOURSELF!!!

> So, with all of this said, TKInter -is- unaccesssible for us. My
> arguments have not been for or against one or the other in this thread,
> but more to get RR to make a better point.

Yea, and i just made it.

>  Because eventually, WX would
> benafit those using a screen reader a lot more than say, TKInter will.
> That doesn't mean that I'm saying that we need to make it a part of the
> stdlib as of yesterday, because segfaults from someone with 10+ years of
> experience (multiple people, actually) says a lot, whether or not RR
> wants to acknowledge said facts. I can not with good conchence say that
> the switch should be done just for accessibility purposes.

No one said accessibility was the only argument. However it IS very
important in todays time. We are not living in the dark ages, much
less under Hitlers rule! If a GUI library has refused to recognize
accessibility concerns a decade into the 21st century, just how long
must we wait Tyler? HOW LONG?

> Obviously it
> would be awesome, but I think Octavian is just focusing on himself, and
> not the actual big picture here.

<sarcasum> Yes Octavian is the only disabled person in the world. What
a selfish, selfish person he is. Shame on you Octavian, Shame on You!
</sarcasum>

You just showed your true colors Tyler, very sad. :(

On Jan 24, 8:49=A0am, Mike Driscoll <kyoso...@gmail.com> wrote:
>
> Bryan, on the other hand, has been aTkinterluminary who has helped
> me in the past when I was learningTkinterand I won't be too
> surprised if he helps me again. I'm sorry he's had so much trouble
> with wx though.

Thanks for the kind words, I appreciate it.

I'm puzzled by the problems I have with wxPython, too. It's taken me
longer to get a grasp on some concepts that I would have guessed. The
first time I got a segfault I was stunned but shrugged it off. A
segfault in a scripting language? Blasphemy! Now I'm not so stunned
anymore, but I still shrug them off. Part of the blame certainly rests
on my shoulder. With only a year and a half or so under my belt with
wxPython there's still lots I have to learn and the documentation only
gets me so far. What's the rule of thumb -- it takes 10 years to
become an expert on a subject?

The underlying architecture of tk is so solid, so well designed (IMHO)
that you (well, I) take a lot of stuff for granted. Then you switch to
something like wxPython where the foundation is maybe a little shaky
in exchange for a much richer library of widgets, and the transition
is bound to be bumpy. It's not generally a matter of "better" or
"worse", just "different".

The key to success is to realize both of the toolkits are just that --
toolkits. They aren't religion, they aren't an assault on family
values or a threat to national security. They are tools to get the job
done. Instead of saying "mine is better than yours" it's better to
learn the strengths and weaknesses of both (or all) and pick the right
one for the job. Attempting to prove that any of these toolkits is
"best" is tilting at windmills.

Personally, I think tkinter is the right choice as a built-in toolkit
but I'll admit to bias. The basics are really simple, and for 90% of
the stuff you're going to code in a scripting language it has all the
features you need. If you specifically need something like the
styledtextctrl or grid of wxPython, or maybe you're concerned with
accessibility or some feature that's not built in to tkinter, by all
means switch to a different toolkit. That's the beauty of these GUI
toolkits -- you can keep the language you love (python, in the case of
this newsgroup) yet pick the GUI toolkit that best helps you solve the
problem at hand.

Instead of fighting over the differences, raise a pint in celebration
of their diversity. :-)

"Littlefield, Tyler" <tyler@tysdomain.com> wrote:
> Rather, I believe 
> those pushing accessibility should concentrate on the root cause; that 
> of fixing TKInter, and not forcing everyone else to use a different library.


Here, here.  From my queries to some of the Tcl/Tk folks, it seems that 
while the knowledge and expertise is not present in the core developer 
community, they would be more than happy to help people who do have some 
knowledge in this area so that Tk could be made to be more accessible.

Grand conspiracies aside, I think the development communities behind 
most GUI toolkits would be very receptive to people who could help make 
developing accessible applications with their toolkits feasible.

(And if/when this does get done for Tk, I promise at least to make sure 
that the tutorial at http:///www.tkdocs.com covers this topic).

Mark

On Jan 24, 12:05=A0pm, rantingrick <rantingr...@gmail.com> wrote:
> On Jan 24, 12:00=A0pm, Bryan <bryan.oak...@gmail.com> wrote:
>
> > Accessibility, like internationalization, is something few programmers
> > spend much time thinking about.
>
> Thats another uninformed statement by you we can add to the mountains
> of useless cruft you have offered so far. Unicode IS
> internationalization and Guido thought it was SO important that
> Python3000 auto converts all strings to Unicode strings. Obviously he
> is moving us toward full Unicode only in the future (AS SHOULD ALL
> IMPLEMENTATIONS!). We need one and only one obvious way to do it. And
> Unicode is that way.

Ok, great. You've identified one programmer who thinks about
internationalization. Not much of a compelling argument there.

However, I think you missed my point. My point wasn't that people like
Guido don't think of these topics. It's that the people in the
trenches who use these tools don't think about these topics. How many
of your co-workers actively think about internationalization and
accessibility? I'm guessing none, but maybe you're lucking and work in
a particularly enlightened team. I've perhaps worked closely with a
few hundred programmers in my career, and very few of them thought of
these subjects. In my experience it's just not something the
programmer in the trenches thinks about. That is the point I was
trying to make.

On 24/01/2011 18:05, rantingrick wrote:
> On Jan 24, 12:00 pm, Bryan<bryan.oak...@gmail.com>  wrote:
>
>> Accessibility, like internationalization, is something few programmers
>> spend much time thinking about.
>
> Thats another uninformed statement by you we can add to the mountains
> of useless cruft you have offered so far. Unicode IS
> internationalization and Guido thought it was SO important that
> Python3000 auto converts all strings to Unicode strings. Obviously he
> is moving us toward full Unicode only in the future (AS SHOULD ALL
> IMPLEMENTATIONS!). We need one and only one obvious way to do it. And
> Unicode is that way.
>
There's more to internationalization than just Unicode. There's the
ability to handle messages in various languages which have a different
syntax and grammar.

There's an interesting Perl-oriented article on it here:

http://search.cpan.org/dist/Locale-Maketext/lib/Locale/Maketext/TPJ13.pod#A_Localization_Horror_Story:_It_Could_Happen_To_You

On Jan 24, 12:31=A0pm, "Littlefield, Tyler" <ty...@tysdomain.com> wrote:
> Bryan: Here's a pretty good list for you.
> Windows:
> Jaws for Windows (http://freedomscientific.com). Not free, but you get a
> 40 minute demo before you need to reboot.
> Nonvisual Desktop Access:http://www.nvda-project.org/
> Free, open source, written in python (with some core stuff in c/c++).
> Linux:
> Orca live.gnome.org/Orca
> Fre, open source. If you don't want to install that bloated mess on a
> box (I sympathise), and you can grab a vmware vinux or a live cd or
> whatever from:http://vinux.org.uk
> OSX:
> OSX comes built in with Voiceover, just hold down the command key and
> hit F5. Use the same keystroke to turn it off.
> Enjoy!

Thanks! I appreciate it.

RR,
I do hate to break the news to you, but I am -blind-, which is why I am 
using a screen reader. So I'm not parking anywhere--the DMV refuses to 
give me a license for some odd reason. What was that post about IQ you 
made earlier?...

On 1/24/2011 8:13 AM Grant Edwards said...
> On 2011-01-24, rantingrick<rantingrick@gmail.com>  wrote:
>
>> Bryan you are clearly an idiot. I am demanding that from now on, you
>> must have at least a 120 or higher IQ before participating in any of
>> my threads.
>
> Rantingrick thinks certain threads belong to him.
>
> 'nuf said.
>


Can we reopen the python-gui list?  That'd be the appropriate place to 
hammer together a PEP to replace tkinter in the standard library.

Emile

On 24/01/2011 18:48, rantingrick wrote:
> On Jan 24, 12:21 pm, "Littlefield, Tyler"<ty...@tysdomain.com>  wrote:
>
> [...snip: good discussion...]
>
>>   Rather, I believe
>> those pushing accessibility should concentrate on the root cause; that
>> of fixing TKInter, and not forcing everyone else to use a different library.
>
> Now you go too far!
>
> And this is an ironic position from someone who supports the stdlib
> GUI that IS forced on us by default. Sure you can choose a different
> library, but in the case of a user (and accessibility is a big USER
> concern when that user is handicapped!) the library is already chosen
> (Tkinter:which does not support accessibility) by the developer . I
> can also argue that Tkinter's inclusion in the stdlib is proliferating
> non-compliance with accessibility. I'll bet you would not park in a
> handicap spot however you support a GUI library that ignores handicap
> people? IRONIC!
>
>> I believe that the approach is the main key here, and I have had this
>> argument many times. If I wrote an app, and someone said something along
>> the lines of "you need to change a core library because it doesn't work
>> with this program," my first response would be who the hell are you to
>> say what I need to use?
>
> Well these people you are chastising are disabled people. Who the hell
> are YOU to be high and mighty about it? I guess these "disabled"
> people get what they deserve huh! Maybe we should just do the world a
> favor and exterminate them like the Nazis? That way we don't have to
> cater to their selfish needs!
>
[snip]
I'd like to invoke Godwin's law at this point.

On Jan 23, 4:31=A0pm, "Martin v. Loewis" <mar...@v.loewis.de> wrote:
> > WxPython Challenge 1 code updated...
>
> > =A0* Fixed tab traveral
> > =A0* Removed hand-holding code
> > =A0* Removed some cruft
>
> > =A0https://sites.google.com/site/thefutureofpython/home/code-challenges
>
> > Good luck!
>
> Still crashes the interpreter.

The crash on Linux is due to SetSingleStyle removing the all items and
the columns when the mode of the listctrl is changed, and then the
code continues on with the assumption that the columns still exist and
the crash happens when an item is added to column zero and there is no
column zero.  Apparently the native widget on Windows doesn't have
that limitation.  BTW, if the linux wx packages had the runtime
assertions turned on then you would have seen a Python exception with
some clues that would probably help solve the problem. I don't know
about others but on Ubuntu you can install the *wx*-dbg packages to
get a version with the assertions turned on.  Hopefully that will
change starting with 2.9 as wx now turns on the assertions by default
for builds configured normally, and the wx-dev team recommends that
the assertions are not turned off, except in rare circumstances.

BTW, on behalf of the wxPython community I'd like to apologize for the
havoc caused by the flaming troll escaping from his cage.  In general
wxPython users are much less militant and zealotty and honor
everyone's freedom to choose which ever UI tool kit works the best for
their own needs.

--Robin

From: "Ethan Furman" <ethan@stoneleaf.us>
> Octavian Rasnita wrote:
>> From: "rantingrick" <rantingrick@gmail.com>
>>> WxPython versus Tkinter (A code battle to the death!)
>>>
>>> by Rick Johnson.
> [...]
>=20
> Octavian,
>=20
> Please do not repost rr's crap in its entirety, or you'll find =
yourself=20
> added to many killfiles -- just like he is.



:-)
I am not posting anyone's crap. I just informed why Tkinter is bad.
And I also don't say that WxPython is ideal, but just that it has some =
very important features that Tk doesn't offer.

Octavian

On Jan 24, 1:34=A0pm, MRAB <pyt...@mrabarnett.plus.com> wrote:

> [snip]
> I'd like to invoke Godwin's law at this point.

Actually no. And i'll give good reason.

Tyler's argument, which lacked greatly in compassion for people with
disabilities brought out my accusation. It was not an accusation meant
to merely insult just to invoke a flame war; which is the definition
of Godwins Law.

It is a fact that Tyler displayed despicable intolerance for people
who have disabilities and such a correlation to totalitarian regimes
was not only the correct response but in fact the only response to
such veiled hate speech. We cannot allow such displays to slip by
unchallenged by this community. And hopefully Tyler will see the
unjust position he has taken and beg for forgiveness.

On Jan 24, 1:57=A0pm, Robin Dunn <ro...@alldunn.com> wrote:
> On Jan 23, 4:31=A0pm, "Martin v. Loewis" <mar...@v.loewis.de> wrote:
>
> > > WxPython Challenge 1 code updated...
>
> > > =A0* Fixed tab traveral
> > > =A0* Removed hand-holding code
> > > =A0* Removed some cruft
>
> > > =A0https://sites.google.com/site/thefutureofpython/home/code-challeng=
es
>
> > > Good luck!
>
> > Still crashes the interpreter.
>
> The crash on Linux is due to SetSingleStyle removing the all items and
> the columns when the mode of the listctrl is changed, and then the
> code continues on with the assumption that the columns still exist and
> the crash happens when an item is added to column zero and there is no
> column zero. =A0Apparently the native widget on Windows doesn't have
> that limitation. =A0BTW, if the linux wx packages had the runtime
> assertions turned on then you would have seen a Python exception with
> some clues that would probably help solve the problem.

In your face Linux users! Learn how to debug already!

> BTW, on behalf of the wxPython community I'd like to apologize for the
> havoc caused by the flaming troll escaping from his cage. =A0In general
> wxPython users are much less militant and zealotty and honor
> everyone's freedom to choose which ever UI tool kit works the best for
> their own needs.

Well we forgive Byran, but we will not forget! :)

On Jan 22, 6:07=A0pm, rantingrick <rantingr...@gmail.com> wrote:

> I await any challengers...

CODE UPDATE

 * fixed linux whiners bug

https://sites.google.com/site/thefutureofpython/home/code-challenges

On Jan 24, 12:03=A0pm, rantingrick <rantingr...@gmail.com> wrote:
> On Jan 24, 1:57=A0pm, Robin Dunn <ro...@alldunn.com> wrote:

> > BTW, on behalf of the wxPython community I'd like to apologize for the
> > havoc caused by the flaming troll escaping from his cage. =A0In general
> > wxPython users are much less militant and zealotty and honor
> > everyone's freedom to choose which ever UI tool kit works the best for
> > their own needs.
>
> Well we forgive Byran, but we will not forget! :)

For the record, that is not who I was referring to.

--Robin

On Jan 24, 1:23=A0pm, Bryan <bryan.oak...@gmail.com> wrote:

> Ok, great. You've identified one programmer who thinks about
> internationalization. Not much of a compelling argument there.

Oh Bryan your view so simplistic. There is a whole world out there you
know.

> However, I think you missed my point. My point wasn't that people like
> Guido don't think of these topics. It's that the people in the
> trenches who use these tools don't think about these topics. How many
> of your co-workers actively think about internationalization and
> accessibility?

No, you've missed the point AGAIN!

It doesn't matter what the developers "think" about accessibility. It
matters what they "DO" about it. Most people in YOUR organization
don't consider accessibility because accessibility does not concern
them . Just like people who dump toxic chemicals into your drinking
water don't concern themselves when you get cancer. They don't care
because they are unaffected. SELFISHNESS is the key word here!

These people have 20/20 vision, perfect hearing, and all their
extremities still attached. Sadly however they lack a brain that can
comprehend even the most basic form of compassion for those who don't
have these luxuries! If ANY of these selfish idiots was in a car
accident and lost an arm and both eyes, i'd bet a million dollars that
the next time they sit down to use a computer they will realize just
how important accessibility is. I would bet that accessibility would
become a major buzz word around your office then!

>  I'm guessing none, but maybe you're lucking and work in
> a particularly enlightened team. I've perhaps worked closely with a
> few hundred programmers in my career, and very few of them thought of
> these subjects. In my experience it's just not something the
> programmer in the trenches thinks about. That is the point I was
> trying to make.

Yes and you made your selfishness quite clear! Be careful my friend,
because as Tyler found out, this mindset becomes a slippery slope
*very* quickly!

From: "Littlefield, Tyler" <tyler@tysdomain.com>
> Hello,
>=20
> I have been on another list with Octavian, and he takes his=20
> accessibility a bit to seriously. If things went his way, he wants =
laws=20
> where -everything- has to be accessible, and it is illegal not to do =
so.=20


Is the discrimination legal in your country?
If you create a program only for a part of the population knowing very =
well that you do that, without having technical issues, (because as you =
know, there are very well known technical solutions for it), it means =
that you discriminate a part of the population.

Of course, as I explained, if you want to create a drawing program or a =
video-editing application, there are technical issues that don't allow =
you to offer that program to everyone, so it is not your fault at all in =
that case.


> As a sidenote, I would like to preface everything I'm going to say by=20
> mentioning the fact that I have been using a screen reader for many=20
> years, so I understand some of where he is coming from.
>=20
> I think my goal, (and I differ from Octavian here), is to try to find=20
> fixes for things, rather than saying "this sucks, it does not work =
with=20
> a reader, and thus it shouldn't be used). Having done a lot of=20
> development work in the past, I can't say "hey you, I want you to make =

> this app accessible, and because you used TKInter it's not, so use=20
> something else, but nothing that isn't accessible." Rather, I believe=20
> those pushing accessibility should concentrate on the root cause; that =

> of fixing TKInter, and not forcing everyone else to use a different =
library.

This is like saying that those who need a screen reader should better =
find a solution for their health problems and after they will find it, =
they won't need a screen reader.
>From the accessibility perspective there are already accessible =
interfaces so that's solved and it just need to be used.
Making Tkinter would be great, but it would not be a solution if it =
won't be used after it will be accessible.

If Tk would be made accessible but Python would start including a QT GUI =
or another one that wouldn't be accessible and the programmers would =
start using that GUI, the result is that the apps won't be accessible.

If there is a solution now for this problem, and not in a bad GUI lib =
that doesn't many features, but one which is very fast and full of =
widgets, then that solution should be promoted by Python.
I don't say (as you pretend) that all the programmers should be forced =
to use it or at least to prefer it.
I said that it should be promoted because it is the right tool.

I think that the political corectness term was invented in USA...


> I believe that the approach is the main key here, and I have had this=20
> argument many times. If I wrote an app, and someone said something =
along=20
> the lines of "you need to change a core library because it doesn't =
work=20
> with this program," my first response would be who the hell are you to =

> say what I need to use? We need to take the approach of "This is what =
is=20
> wrong, this is why, this is possibly how it could be fixed. Would you =
be=20
> willing to do so?"


With other words, you are very happy when you can't use a program =
because it is not accessible, thinking that as a programmer you won't be =
forced by someone else or laws to learn to use the right tool.
Or you may be willing to change all the programs in the world which are =
not accessible because they use a bad GUI.


> So, with all of this said, TKInter -is- unaccesssible for us. My=20
> arguments have not been for or against one or the other in this =
thread,=20
> but more to get RR to make a better point. Because eventually, WX =
would=20
> benafit those using a screen reader a lot more than say, TKInter will. =

> That doesn't mean that I'm saying that we need to make it a part of =
the=20
> stdlib as of yesterday, because segfaults from someone with 10+ years =
of=20
> experience (multiple people, actually) says a lot, whether or not RR=20
> wants to acknowledge said facts.=20

Those segfaults would disappear much faster if WxPython would become =
more interesting and if it would become a part of Python distribution =
because there would be much more programmers interested about it and =
willing to solve its problems under some platforms.

WxPython has some problems under some platforms used by a minority of =
users. Tkinter has some problems for another minority of users.
The big picture is the worst thing possible and it is not that I can't =
see it, but I can't agree with it. The big picture is that very many =
people simply don't care and this is not something good.

Octavian

On Jan 24, 2:33=A0pm, rantingrick <rantingr...@gmail.com> wrote:
>
> Yes and you made your selfishness quite clear! Be careful my friend,
> because as Tyler found out, this mindset becomes a slippery slope
> *very* quickly!

I merely made the observation that most programmers don't think about
these topics and it would be good to get some more enlightenment, you
now you're accusing me of selfishness? That's an impressive mental
leap, though I don't think you quite made it to the other side.

Did you perhaps interpret my comment as "programmers SHOULDN'T think
about..."? I'm not saying programmers shouldn't think about these
things. On the contrary, all programmers _should_ think about them.
They don't, at least in my experience. That's a problem, it needs to
be fixed. If you think that's a mindset that's on a slippery slope,
you're the only one.

From: "Mark Roseman" <mark@markroseman.com>
> "Littlefield, Tyler" <tyler@tysdomain.com> wrote:
>> Rather, I believe=20
>> those pushing accessibility should concentrate on the root cause; =
that=20
>> of fixing TKInter, and not forcing everyone else to use a different =
library.
>=20
>=20
> Here, here.  From my queries to some of the Tcl/Tk folks, it seems =
that=20
> while the knowledge and expertise is not present in the core developer =

> community, they would be more than happy to help people who do have =
some=20
> knowledge in this area so that Tk could be made to be more accessible.
>=20
> Grand conspiracies aside, I think the development communities behind=20
> most GUI toolkits would be very receptive to people who could help =
make=20
> developing accessible applications with their toolkits feasible.
>=20
> (And if/when this does get done for Tk, I promise at least to make =
sure=20
> that the tutorial at http:///www.tkdocs.com covers this topic).
>=20
> Mark


It would be great if the Tk/Tkinter developers would be interested in =
making this GUI lib accessible.
There are no many people that know about this thing, but there are =
standards like MSAA that can be followed by them if they really want to =
offer accessibility.
I guess that if Tkinter would support MSAA (Microsoft Active =
Accessibility) in its Windows version, the screen readers would be able =
to offer support for Tk (or it might be offered by default... I don't =
know).

Octavian

From: "Bryan" <bryan.oakley@gmail.com>
I wish I could respond to that, but I have no experience with screen
readers.  Are there any free ones, or ones with free trials, that I
could try out? I'm not yet convinced it's any better or worse than
wxPython since you're only a single datapoint, but of course it's
possible. If you know of any free tools I can use to experiment, I'd
appreciate you posting them in this newsgroup.

Accessibility, like internationalization, is something few programmers
spend much time thinking about. I can only imagine the frustration one
must experience if all interactions had to be through a screen reader.




Hi Bryan,

(And thank you for your interest)

The most used screen reader and the one that have the most features is =
JAWS that can be downloaded from:

http://www.freedomscientific.com/downloads/jaws/jaws-downloads.asp

You can use it for 40 minutes after which you need to restart the =
computer to be able to use it again.

You can test that simple sample WxPython app and compare it with any =
Tk-based app.
Please tell us what you find.

Octavian

From: "MRAB" <python@mrabarnett.plus.com>
> On 24/01/2011 18:05, rantingrick wrote:
>> On Jan 24, 12:00 pm, Bryan<bryan.oak...@gmail.com>  wrote:
>>
>>> Accessibility, like internationalization, is something few =
programmers
>>> spend much time thinking about.
>>
>> Thats another uninformed statement by you we can add to the mountains
>> of useless cruft you have offered so far. Unicode IS
>> internationalization and Guido thought it was SO important that
>> Python3000 auto converts all strings to Unicode strings. Obviously he
>> is moving us toward full Unicode only in the future (AS SHOULD ALL
>> IMPLEMENTATIONS!). We need one and only one obvious way to do it. And
>> Unicode is that way.
>>
> There's more to internationalization than just Unicode. There's the
> ability to handle messages in various languages which have a different
> syntax and grammar.
>=20
> There's an interesting Perl-oriented article on it here:
>=20
> =
http://search.cpan.org/dist/Locale-Maketext/lib/Locale/Maketext/TPJ13.pod=
#A_Localization_Horror_Story:_It_Could_Happen_To_You
> --=20


Perl offers a great support for I18n/L10N including its native support =
for UTF-8, and I am glad that Python 3 will also have improvements for =
it.
Just like the I18N, it would be a good idea if Python will also start to =
promote the accessibility, because just like the internationalization, =
it is targetted to make the programs accessible by as many users as =
possible.

Octavian

On Jan 24, 2:49=A0pm, Bryan <bryan.oak...@gmail.com> wrote:
> On Jan 24, 2:33=A0pm, rantingrick <rantingr...@gmail.com> wrote:
>
> > Yes and you made your selfishness quite clear! Be careful my friend,
> > because as Tyler found out, this mindset becomes a slippery slope
> > *very* quickly!
>
> I merely made the observation that most programmers don't think about
> these topics and it would be good to get some more enlightenment, you
> now you're accusing me of selfishness?

If you are not part of the solution then you are part of the problem.
I think you *do* want to help proliferate accessibility. However, you
have not displayed the attitude that we need to win the fight. You
see, selfishness is a natural human trait. We all harbor selfishness
to some degree. Even myself! We cannot fully ever be free of this
selfishness. However we can fight and suppress selfishness until it's
ill effects have no "noticeable" effect.

This is what i am speaking of when i say that you are part of the
problem. You need to educate your co-workers about accessibility. You
need to make them aware of their own selfish and erroneous ways. Then
and only then shall *you* be part of the solution. But don't expect
that they will just roll over! This will be an uphill battle so we
must be persistent! They need to choose libraries that are supporting
accessibility. Or at least choose a library that is *aware* of
accessibility and is moving forward into full blown support of
accessibility.

A comment was made earlier by Mark Roseman about how he would document
accessibly in Tkinter *if* someone else would bring Tk accessibility
into being. This is just one more example of someone paying lip
service to a problem without actually suppressing his selfishness and
producing some action. Mark needs to sound the battle call at his
site. He needs to send an email to the TclTk-dev team daily and ask
how they are coming along with accessibility. Then he needs to post
the response -- or lack there of-- on his site for all to see. He
needs to change his attitude from passive to aggressive. Then and only
then shall change come.

Change happens only when people demand change. And sadly the power to
change accessibility lies not in the hands of those directly affected
but in the hands of those twice removed from the torments of
accessibility. This is the same problem all GUI developers face with
the multiplicity of GUI libraries. If we could get these selfish and
moronic OS developers to agree on one GUI standard then our lives, and
the lives of our users would be bliss. Then we could have universal
accessibility, universal rich widget sets, universal cross platform-
ability, universal speed, universal look and feel, etc, etc.

On Sun, 23 Jan 2011 12:23:13 -0800, rantingrick wrote:
 > I am not
 > trying to create a working file browser so you can steal my code.

2011/1/24 rantingrick <rantingrick@gmail.com>:
> This thread has been an eye opener for myself [...]
 > we cannot even work together to get some simple code
> debugged.

Aha!  So you want to steal our code to fix yours?  Why am I not surprised?

~Ethan~

Octavian Rasnita:

> There are no many people that know about this thing,
> but there are standards like MSAA that can be followed
> by them if they really want to offer accessibility. I
> guess that if Tkinter would support MSAA (Microsoft
> Active Accessibility) in its Windows version, the screen
> readers would be able to offer support for Tk (or it
> might be offered by default... I don't know).

   MSAA was superseded by Microsoft UI Automation in 2005 which in turn
was superseded by Windows Automation API in Windows 7.
http://msdn.microsoft.com/en-us/library/dd561932(v=vs.85).aspx

   Making Tk as accessible as Windows or GTK+ would be a huge job.

   Neil

RR, you idiot. Did you -not- read that I was blind and using a screen 
reader? And wasn't it -you- yelling at someone about reading and 
comprehention?
On 1/24/2011 12:34 PM, MRAB wrote:
> On 24/01/2011 18:48, rantingrick wrote:
>> On Jan 24, 12:21 pm, "Littlefield, Tyler"<ty...@tysdomain.com>  wrote:
>>
>> [...snip: good discussion...]
>>
>>>   Rather, I believe
>>> those pushing accessibility should concentrate on the root cause; that
>>> of fixing TKInter, and not forcing everyone else to use a different 
>>> library.
>>
>> Now you go too far!
>>
>> And this is an ironic position from someone who supports the stdlib
>> GUI that IS forced on us by default. Sure you can choose a different
>> library, but in the case of a user (and accessibility is a big USER
>> concern when that user is handicapped!) the library is already chosen
>> (Tkinter:which does not support accessibility) by the developer . I
>> can also argue that Tkinter's inclusion in the stdlib is proliferating
>> non-compliance with accessibility. I'll bet you would not park in a
>> handicap spot however you support a GUI library that ignores handicap
>> people? IRONIC!
>>
>>> I believe that the approach is the main key here, and I have had this
>>> argument many times. If I wrote an app, and someone said something 
>>> along
>>> the lines of "you need to change a core library because it doesn't work
>>> with this program," my first response would be who the hell are you to
>>> say what I need to use?
>>
>> Well these people you are chastising are disabled people. Who the hell
>> are YOU to be high and mighty about it? I guess these "disabled"
>> people get what they deserve huh! Maybe we should just do the world a
>> favor and exterminate them like the Nazis? That way we don't have to
>> cater to their selfish needs!
>>
> [snip]
> I'd like to invoke Godwin's law at this point.


-- 

Thanks,
Ty

On Jan 24, 3:47=A0pm, Neil Hodgson <nhodg...@bigpond.net.au> wrote:

> =A0 =A0Making Tk as accessible as Windows or GTK+ would be a huge job.

Not if we used the underlying MS library! Windows has such a rich
library why not use it? Why must we constantly re-invent the wheel?
Windowing GUIs are not recent technology. These things have been
around for decades. When are we going to agree on a damn standard. Is
it not far passed time to drop the selfishness and work together? I
said it before...

"Multiplicity is very important in emerging systems however at some
point we must reign in the madness else entropy will destroy the
entire system."

Selfishness =3D Multiplicity =3D Entropy =3D Shock =3D Stagnation =3D None

On Jan 24, 9:57=A0pm, Robin Dunn wrote:
> On Jan 23, 4:31=A0pm, "Martin v. Loewis" <mar...@v.loewis.de> wrote:
>
> > > WxPython Challenge 1 code updated...
>
> > > =A0* Fixed tab traveral
> > > =A0* Removed hand-holding code
> > > =A0* Removed some cruft
>
> > > =A0https://sites.google.com/site/thefutureofpython/home/code-challeng=
es
>
> > > Good luck!
>
> > Still crashes the interpreter.
>
> The crash on Linux is due to SetSingleStyle removing the all items and
> the columns when the mode of the listctrl is changed, and then the
> code continues on with the assumption that the columns still exist and
> the crash happens when an item is added to column zero and there is no
> column zero. =A0Apparently the native widget on Windows doesn't have
> that limitation. =A0BTW, if the linux wx packages had the runtime
> assertions turned on then you would have seen a Python exception with
> some clues that would probably help solve the problem. I don't know
> about others but on Ubuntu you can install the *wx*-dbg packages to
> get a version with the assertions turned on. =A0Hopefully that will
> change starting with 2.9 as wx now turns on the assertions by default
> for builds configured normally, and the wx-dev team recommends that
> the assertions are not turned off, except in rare circumstances.
>
> BTW, on behalf of the wxPython community I'd like to apologize for the
> havoc caused by the flaming troll escaping from his cage. =A0In general
> wxPython users are much less militant and zealotty and honor
> everyone's freedom to choose which ever UI tool kit works the best for
> their own needs.

I have been involved in the wxPython development for many years
(mostly on implementation of custom widgets, in the AGW library), and
I share Robin's concerns about this kind of "publicity" given to
wxPython.

Python comes with TK as a "battery included" UI toolkit. I'm perfectly
fine with this, as I am not going to use it anyway. Whether in the
future TK will be replaced by PyGTK, PyQT, PySide, etc... in the
standard library, it won't make any difference to those aficionados
developers who use wxPython. We'll still download the wxPython
binaries/sources/whatever and use it to develop our own GUIs. There is
simply no match between wxPython and X (substitute X with whatever GUI
toolkit you like). This is obviously my very biased opinion.

It is very unfortunate that this topic "wxPython vs. Tkinter" has
drifted to another flame war, as there is really no point in this kind
of discussion. As a general rule, a GUI-newbie should try all the GUI
toolkits out there and settle with the one which looks easier/nicer/
more convenient/more feature rich. As usual, it is a matter of
personal taste.

For those experiencing with wxPython for the first time, I highly
suggest you to join our wxPython mailing list: you'll find a friendly
place, with many experienced developers answering questions and a BDFL
who's there (almost) every day offering solutions for the toughest
problems.

Andrea.

 >It would be great if the Tk/Tkinter developers would be interested in 
making >this GUI lib accessible.
They're not going to do it without knowing what makes accessible 
accessible, and why it needs to be so. So, rather than tell the world 
about how -some- blind people want to be like sighted people (we call 
that independence in my world), why not go help out? It's bad, you want 
a switch, and you've already said that they're using a lib that is 
unaccessible. So fix the lib, and you will have fixed tons of programs 
without fixing the program. That is all I ment by finding the root of 
the problem, not "everyone with readers should fix their health 
problems." You take my words, blow them out of perportion and at the end 
of the day, you are still sitting here complaining about the lack of 
accessibility, rather than doing something about it. This is awesome. We 
for sure need more complainers and less people to do what the 
complainers are complaining about!
On 1/24/2011 1:49 PM, Octavian Rasnita wrote:
> From: "Mark Roseman"<mark@markroseman.com>
>> "Littlefield, Tyler"<tyler@tysdomain.com>  wrote:
>>> Rather, I believe
>>> those pushing accessibility should concentrate on the root cause; that
>>> of fixing TKInter, and not forcing everyone else to use a different library.
>>
>> Here, here.  From my queries to some of the Tcl/Tk folks, it seems that
>> while the knowledge and expertise is not present in the core developer
>> community, they would be more than happy to help people who do have some
>> knowledge in this area so that Tk could be made to be more accessible.
>>
>> Grand conspiracies aside, I think the development communities behind
>> most GUI toolkits would be very receptive to people who could help make
>> developing accessible applications with their toolkits feasible.
>>
>> (And if/when this does get done for Tk, I promise at least to make sure
>> that the tutorial at http:///www.tkdocs.com covers this topic).
>>
>> Mark
>
> It would be great if the Tk/Tkinter developers would be interested in making this GUI lib accessible.
> There are no many people that know about this thing, but there are standards like MSAA that can be followed by them if they really want to offer accessibility.
> I guess that if Tkinter would support MSAA (Microsoft Active Accessibility) in its Windows version, the screen readers would be able to offer support for Tk (or it might be offered by default... I don't know).
>
> Octavian
>


-- 

Thanks,
Ty

rantingrick:

> Not if we used the underlying MS library! Windows has such a rich
> library why not use it? Why must we constantly re-invent the wheel?

   It is up to the GUI toolkit or application to implement the
interfaces defined by Windows Automation API on every object it
displays. The standard Windows controls have this implemented. Tk does
not use these controls so would have to do all that work again.

   Neil

On Jan 24, 3:58=A0pm, Infinity77 <andrea.gav...@gmail.com> wrote:

> I have been involved in the wxPython development for many years
> (mostly on implementation of custom widgets, in the AGW library), and
> I share Robin's concerns about this kind of "publicity" given to
> wxPython.

Who cares what you think about wxPython's publicity. A module was
created and put on public display and can be ridiculed or supported by
anyone who so desires.

> Python comes with TK as a "battery included" UI toolkit. I'm perfectly
> fine with this, as I am not going to use it anyway. Whether in the
> future TK will be replaced by PyGTK, PyQT, PySide, etc... in the
> standard library, it won't make any difference to those aficionados
> developers who use wxPython. We'll still download the wxPython
> binaries/sources/whatever and use it to develop our own GUIs.

Good, and again i cannot stress how little we care about your opinion.
Why do we not care. Well because you are looking at this from a
wxPython perspective. You are being selfish. We are considering this
from a global Python perspective. What is good for Python may not be
good for you, in any event, it is for us to decide. You can join our
discussion when your perspective changes from "me" to "us". And the
"us" is the Python langauge NOT wxPython.


> It is very unfortunate that this topic "wxPython vs. Tkinter" has
> drifted to another flame war,

There is no flame war here

> as there is really no point in this kind
> of discussion.

Says you. but who are you to say what is important to us. Go back to
wxPython.

> As a general rule, a GUI-newbie should try all the GUI
> toolkits out there and settle with the one which looks easier/nicer/
> more convenient/more feature rich. As usual, it is a matter of
> personal taste.

And i agree. I think any sane person could agree also. However you
miss the point of this conversation. We are looking at Python from a
global perspective. You are limited in your views, and obviously very
biased. And i know the real reason you and Robin do not want wxPython
in the stdlib. Because you do not want to lose your selfish status
within the wxPython community. When wxPython becomes a stdlib module
then you will answer directly to Guido and Python-dev. You are not
fooling anyone with this grandstanding.

Selfishness =3D Multiplicity =3D Entropy =3D Shock =3D Stagnation =3D None

On Jan 24, 3:53=A0pm, "Littlefield, Tyler" <ty...@tysdomain.com> wrote:
> RR, you idiot. Did you -not- read that I was blind and using a screen
> reader? And wasn't it -you- yelling at someone about reading and
> comprehention?
> On 1/24/2011 12:34 PM, MRAB wrote:

Are you telling me that you are blind? You better not be lying about
this Tyler because the only thing worse than an compassionate person
is who impersonates a blind person for sake of winning an argument.

Now, if you really are blind then why the heck would you be supporting
Tkinter? Tkinter has no support for accessibility -- as Octavian
pointed out. However, you seem to want to keep Tkinter at all costs.
Why? And furthermore why are you so rabidly resistive to wxPython?

On Jan 24, 4:16=A0pm, rantingrick <rantingr...@gmail.com> wrote:
> ...
> Good, and again i cannot stress how little we care about your opinion.

You keep using the word "we". I do not think it means what you think
it means.

On Mon, 24 Jan 2011 12:24:24 -0800, Robin Dunn wrote:

> On Jan 24, 12:03 pm, rantingrick <rantingr...@gmail.com> wrote:
>> On Jan 24, 1:57 pm, Robin Dunn <ro...@alldunn.com> wrote:
> 
>> > BTW, on behalf of the wxPython community I'd like to apologize for
>> > the havoc caused by the flaming troll escaping from his cage.  In
>> > general wxPython users are much less militant and zealotty and honor
>> > everyone's freedom to choose which ever UI tool kit works the best
>> > for their own needs.
>>
>> Well we forgive Byran, but we will not forget! :)
> 
> For the record, that is not who I was referring to.

I don't believe that anyone in their right mind could have imagined even 
for a second that you were referring to Bryan.


-- 
Steven

On Mon, 24 Jan 2011 09:17:01 -0800, rantingrick wrote:

> I was
> being a closed minded idiot at the time. I have since evolved.

"Was"?

It's been fun (for some definition of fun) watching your grandstanding, 
your haranguing the community into doing things your way, your insulting 
the blind for being insufficiently demanding of screen-reader support, 
and generally bullying everyone here. Unfortunately I've wasted far too 
much time reading your theatrics. It's time for another six months in the 
kill-file, I think.



-- 
Steven

On 2011-01-24, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
> On Mon, 24 Jan 2011 09:17:01 -0800, rantingrick wrote:
>
>> I was being a closed minded idiot at the time. I have since evolved.
>
> "Was"?
>
> It's been fun (for some definition of fun) watching your
> grandstanding, your haranguing the community into doing things your
> way, your insulting the blind for being insufficiently demanding of
> screen-reader support, and generally bullying everyone here.
> Unfortunately I've wasted far too much time reading your theatrics.

Unfortunately, some of us have been guilty of poking him with a stick
just to watch him jump and yell.

> It's time for another six months in the kill-file, I think.

That doesn't really help much.  RR has been in my killfile since
before his first posting. But, thanks to people who quote his rantings
in their entirety, I think I've seen pretty much all of them.

-- 
Grant Edwards               grant.b.edwards        Yow! FROZEN ENTREES may
                                  at               be flung by members of
                              gmail.com            opposing SWANSON SECTS ...

On Jan 24, 5:31=A0pm, Grant Edwards <inva...@invalid.invalid> wrote:
> On 2011-01-24, Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> wro=
te:
>
> > On Mon, 24 Jan 2011 09:17:01 -0800, rantingrick wrote:
>
> >> I was being a closed minded idiot at the time. I have since evolved.
>
> > "Was"?
>

[...snip: Steven Trolling...]

> > Unfortunately I've wasted far too much time reading your theatrics.
>
> Unfortunately, some of us have been guilty of poking him with a stick
> just to watch him jump and yell.

Every one of my threads (or threads i replied to) Steven has trolled
them all. He never engages me in direct battle because he lacks the
mental prowess i possess. He fears me and it shows. He fears me
because i have a vision and he has none. He fears me because HE fears
change. Should i post links to all the threads you have trolled up
Steven as evidence of your trollish behavior?  You never had the balls
to engage me and you never will! Sadly you are one of the most
knowledgeable within this group yet you spend 99% of your time
trolling for your own self gratification. Why have you not offered any
opinions on Wx versus Tkinter? Why have you not offered any code?
BECAUSE YOU ARE A TROLL! Plain and simple.

> > It's time for another six months in the kill-file, I think.

Good riddance! Make it a year, ten years, i don't care!

> That doesn't really help much. =A0RR has been in my killfile since
> before his first posting. But, thanks to people who quote his rantings
> in their entirety, I think I've seen pretty much all of them.

Well kill file D'Aprano and just shrink your listener even more. The
funny thing about selfishness and arrogance is that they are both self
defeating. However many in this group wear these attributes with
pride. Yes, go ahead and stick your head in the sand and imagine the
world does not exist -- because when you do you leave your backside
sticking out in a good position for kicking! *kick*

On Jan 24, 2:16=A0pm, rantingrick <rantingr...@gmail.com> wrote:
> And i know the real reason you and Robin do not want wxPython
> in the stdlib. Because you do not want to lose your selfish status
> within the wxPython community. When wxPython becomes a stdlib module
> then you will answer directly to Guido and Python-dev. You are not
> fooling anyone with this grandstanding.

Oh my, the BS certainly is getting deep around here.  It doesn't look
like my hip-waders will be enough... Now where did I put that full-
body bio-hazard environment suit?

--Robin

There are two completely different issues here:

1. Tyler's/Octavian's very valid (but AFAICT now somewhat 
over-expressed) point that Tk/Tkinter isn't accessible.

I accept this, but don't see any point against Tk(inter) in this per 
se. Tk(inter) could be advanced to support screen readers and such.

2. RR's aggressive, insulting, self-praising war against Tk(inter) 
(which, IIRC, he ones praised)

I *really* don't understand why RR gets so much attention. He has 
(massively!) insulted everybody around, has shown his low knowledge 
and understanding, his selfish and arrogant behaviour, etc.

As I see it, please don't fall trap when RR now supports the 
accessible issue. I'm quite sure, that he just misuses that.



Now that Godwin has been called, let me say also this:

Check some earlier posts of RR (especially unicode related, but also 
his whole "command structure", "leader", "one for all", etc stuff) 
and it should be clear who is the izan. (*)


Wake me, if RR is chased out of town and we can start a real 
discussion about the future of Python GUIs and accessibility.



(*)
I'm German and I just *KNOW* what to think about people who accuse 
random opponents as aniz. Our politicians do that quite regularly 
and the *ONLY* aim behind this is plain and simply to discredit the 
opponent when the arguments run out.

On Tue, 25 Jan 2011 01:37:18 +0100, Alexander Kapps wrote:

> I *really* don't understand why RR gets so much attention. He has
> (massively!) insulted everybody around, has shown his low knowledge and
> understanding, his selfish and arrogant behaviour, etc.

http://xkcd.com/386/



-- 
Steven

On Jan 24, 2:11=A0pm, rantingrick <rantingr...@gmail.com> wrote:
> On Jan 22, 6:07=A0pm, rantingrick <rantingr...@gmail.com> wrote:
>
> > I await any challengers...
>
> CODE UPDATE
>
> =A0* fixed linux whiners bug
>
> https://sites.google.com/site/thefutureofpython/home/code-challenges

So what? Now that the code runs without segfault nobody has nothing to
say? I guess you have nothing to complain about now huh? So go ahead
and admit wxPython won this round so we can move on to round two, our
post some Tkinter ListCtrl code.

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigB1F9482059BFF9495A49B547
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 1/24/11 2:16 PM, rantingrick wrote:
> On Jan 24, 3:58 pm, Infinity77 <andrea.gav...@gmail.com> wrote:
>=20
>> I have been involved in the wxPython development for many years
>> (mostly on implementation of custom widgets, in the AGW library), and
>> I share Robin's concerns about this kind of "publicity" given to
>> wxPython.
>=20
> Who cares what you think about wxPython's publicity. A module was
> created and put on public display and can be ridiculed or supported by
> anyone who so desires.
>=20
>> Python comes with TK as a "battery included" UI toolkit. I'm perfectly=

>> fine with this, as I am not going to use it anyway. Whether in the
>> future TK will be replaced by PyGTK, PyQT, PySide, etc... in the
>> standard library, it won't make any difference to those aficionados
>> developers who use wxPython. We'll still download the wxPython
>> binaries/sources/whatever and use it to develop our own GUIs.
>=20
> Good, and again i cannot stress how little we care about your opinion.
> Why do we not care. Well because you are looking at this from a
> wxPython perspective. You are being selfish. We are considering this
> from a global Python perspective. What is good for Python may not be
> good for you, in any event, it is for us to decide. You can join our
> discussion when your perspective changes from "me" to "us". And the
> "us" is the Python langauge NOT wxPython.
>=20
>=20
>> It is very unfortunate that this topic "wxPython vs. Tkinter" has
>> drifted to another flame war,
>=20
> There is no flame war here
>=20
>> as there is really no point in this kind
>> of discussion.
>=20
> Says you. but who are you to say what is important to us. Go back to
> wxPython.
>=20
>> As a general rule, a GUI-newbie should try all the GUI
>> toolkits out there and settle with the one which looks easier/nicer/
>> more convenient/more feature rich. As usual, it is a matter of
>> personal taste.
>=20
> And i agree. I think any sane person could agree also. However you
> miss the point of this conversation. We are looking at Python from a
> global perspective. You are limited in your views, and obviously very
> biased. And i know the real reason you and Robin do not want wxPython
> in the stdlib. Because you do not want to lose your selfish status
> within the wxPython community. When wxPython becomes a stdlib module
> then you will answer directly to Guido and Python-dev. You are not
> fooling anyone with this grandstanding.

I can't believe I'm actually getting into this, but--

wxPython is open source, and technically anyone has the legal right to
include it in whatever they want -- but no module goes into stdlib,
period, without it being donated by its authors for that purpose.
Period. Python-dev is not so discourteous as to absorb someone elses
code without their go-ahead (and more then that: they don't generally
absorb anyone elses code without that person making a _commitment_ to
supporting it, in the stdlib, for multiple years).

So: no author answers to Guido unless they decide they want to.

Not that I'm suggesting Robin wouldn't go for it if someone with actual
standing asked: but I'm not suggesting he would, either. I have no idea
if the stdlib development cycle fits the wxPython one, since wxPython
tracks wxWidgets releases. (Totally notwithstanding the elephant in the
room that nothing new is going to go into 2.x at all, and wxPython
doesn't presently support 3.x.)

Robin actually has an unappealable veto over the whole idea, if he so
chose to exercise it.

Just thought I'd interject some reality into your delusion that there is
some Python Kingdom and that King Guido can "decide" all manner of
things and it'll cause them to happen.

But we've had this conversation before, you and I.

Also, rick !=3D the_community. You don't get to speak for "we".

But we've had that conversation too, you and I.


--=20

   Stephen Hansen
   ... Also: Ixokai
   ... Mail: me+list/python (AT) ixokai (DOT) io
   ... Blog: http://meh.ixokai.io/


--------------enigB1F9482059BFF9495A49B547
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (Darwin)

iQEcBAEBAgAGBQJNPklfAAoJEKcbwptVWx/l3xcH/jLE2a9UuxiPzTtK/RBbZyTC
WmBFZ06ES5kYVVAJ0B4c6uuPuFWvl5sbMR2Y5OZ1zUg5vysyL4aqep3eQG/4kBsv
1V6a4sd9yuxzjTrKOZHr0kpTE/KR4RKnuL/Hi/bmY8nLIlHuTDwGoVcWu2DafW9G
nGckjyoTbVuXWFYFwCIKpsYg5mj863hF1Ua3x+Bgjv7fvrbzAMQixRdWsnl06oya
tcELXzf9HW5tzbpaNjMB+niWC+uQqZB1uA5SemA3Eisdam45Ij9kJFdN+RC3Q84S
5dvnobBMfF6R5Di2g1bM2lOtKNRphwn9eL26AFDxDLxUu8CT9dB6IMVGYGP9QA0=
=N2yr
-----END PGP SIGNATURE-----

--------------enigB1F9482059BFF9495A49B547--

On Jan 24, 9:54=A0pm, Stephen Hansen <me+list/pyt...@ixokai.io> wrote:
> On 1/24/11 2:16 PM, rantingrick wrote:

> wxPython is open source, and technically anyone has the legal right to
> include it in whatever they want -- but no module goes into stdlib,
> period, without it being donated by its authors for that purpose.

Ok. So you are saying that wxPython *could* possibly go into the
stdlib and equally wxPython could possibly *not* go into th stdlib?
Ok, go on...

> Period. Python-dev is not so discourteous as to absorb someone elses
> code without their go-ahead (and more then that: they don't generally
> absorb anyone elses code without that person making a _commitment_ to
> supporting it, in the stdlib, for multiple years).
>
> So: no author answers to Guido unless they decide they want to.

Ok? So you are saying that wxPython *could* possibly go into the
stdlib and equally wxPython could possibly *not* go into th stdlib?
Ok, go on...

> Not that I'm suggesting Robin wouldn't go for it if someone with actual
> standing asked: but I'm not suggesting he would, either.

Ok! So you are saying that wxPython *could* possibly go into the
stdlib and equally wxPython could possibly *not* go into th stdlib?
Ok, go on...

>  I have no idea
> if the stdlib development cycle fits the wxPython one, since wxPython
> tracks wxWidgets releases. (Totally notwithstanding the elephant in the
> room that nothing new is going to go into 2.x at all, and wxPython
> doesn't presently support 3.x.)

OK,OK,OK!! So you are saying that wxPython *could* possibly go into
the stdlib and equally wxPython could possibly *not* go into th
stdlib? HOWEVER no matter what it FOR SURE can't go into Python2.x!
Ok, go on...

> Robin actually has an unappealable veto over the whole idea, if he so
> chose to exercise it.

GEESH!! So you are saying that wxPython *could* possibly go into the
stdlib and equally wxPython could possibly *not* go into th stdlib?
Ok, go on...

> Just thought I'd interject some reality into your delusion that there is
> some Python Kingdom and that King Guido can "decide" all manner of
> things and it'll cause them to happen.

Stephen can i sum up your post as..."it could go either way"?

PS: And you guys wonder why i rant so much! :-)

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig2052D6050BA2884A7492FCA3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 1/24/11 8:32 PM, rantingrick wrote:
> On Jan 24, 9:54 pm, Stephen Hansen <me+list/pyt...@ixokai.io> wrote:
>> On 1/24/11 2:16 PM, rantingrick wrote:
>
>> wxPython is open source, and technically anyone has the legal right to=

>> include it in whatever they want -- but no module goes into stdlib,
>> period, without it being donated by its authors for that purpose.
>
> Ok. So you are saying that wxPython *could* possibly go into the
> stdlib and equally wxPython could possibly *not* go into th stdlib?
> Ok, go on...

No. I am saying as a matter of legal permissibility, it may be included
in the stdlib.

But, as a matter of both policy and ethical behavior, it will not
without it being donated by the author.

The words are not big.

You can understand them, if you try, really hard. Honest.

--=20

   Stephen Hansen
   ... Also: Ixokai
   ... Mail: me+list/python (AT) ixokai (DOT) io
   ... Blog: http://meh.ixokai.io/


--------------enig2052D6050BA2884A7492FCA3
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (Darwin)

iQEcBAEBAgAGBQJNPlbHAAoJEKcbwptVWx/lGbYH/1a/rtyt4ttOD5yInQv03t78
WEKaWlDYR/9hXCvXIxRV2KNcNMybruoWbNaUqIBDZAMqVjARtUzm5mSre+TeL641
G58MhuzH656omsVP344qbBnyCgOcpihaUkPXWJDy0xTUOppZg7k+WEBQOJptCu3P
hHlu8Uf7IckWMSufiZJDwF8znbsjQMgI1LQ40QJF68mwsWm/XTkRnePIVSloQv7P
E3G6NMXpmZDURseFioT6wEVHTQwORRKCYGYO6/Yqy9IRmK/f0PFMjfJLaI/eUoGM
YbTIlJQ5qyYv5lljir3Bjz1G6pFS63riEmTGgsnE7t2BpNYGLqZ1mRkY2bDMTAk=
=3je6
-----END PGP SIGNATURE-----

--------------enig2052D6050BA2884A7492FCA3--

At 10:39 PM 1/24/2011, Jason Swails wrote:
[snip]
>Two valuable things I have taken away from this extended 
>argument:  1) This being my first super-high volume mailing list 
>with the occasional neurotically opinionated poster, MRAB introduced 
>me to Godwin's law for the first time.  Considering its context, 
>much to my amusement (thank you).  2) Steven's XKCD comic that I had 
>not seen before.  Also, considering its context, much to my amusement.

More wisdom therein  ...
http://xkcd.com/438/



-- 
I'm a pessimist about probabilities; I'm an optimist about possibilities.
     Lewis Mumford  (1895-1990)

On Jan 24, 10:51=A0pm, Stephen Hansen <me+list/pyt...@ixokai.io> wrote:

> No. I am saying as a matter of legal permissibility, it may be included
> in the stdlib.
>
> But, as a matter of both policy and ethical behavior, it will not
> without it being donated by the author.

I don't think you have any idea of what you are saying because you
keep parroting off the same thing in slightly different ways. I'm
having flashbacks to Forrest Gump...

Bubba: Anyway, like I was sayin', shrimp is the fruit of the sea. You
can barbecue it, boil it, broil it, bake it, saute it. Dey's uh,
shrimp-kabobs, shrimp creole, shrimp gumbo. Pan fried, deep fried,
stir-fried. There's pineapple shrimp, lemon shrimp, coconut shrimp,
pepper shrimp, shrimp soup, shrimp stew, shrimp salad, shrimp and
potatoes, shrimp burger, shrimp sandwich. That- that's about it.

So after presenting us with well known knowledge (and repeating it
many times) i feel compelled to bring us back to the subject matter at
hand. Do you have any actual argument to present that adds some
compelling ideas about Tkinters worth, or non worth?

From: "Infinity77" <andrea.gavana@gmail.com>
> As a general rule, a GUI-newbie should try all the GUI
> toolkits out there and settle with the one which looks easier/nicer/


Yes it would be nice, but... does it happen that way usually? :-)

Octavian

From: "Littlefield, Tyler" <tyler@tysdomain.com>
> >It would be great if the Tk/Tkinter developers would be interested in
> making >this GUI lib accessible.
> They're not going to do it without knowing what makes accessible 
> accessible, and why it needs to be so. So, rather than tell the world 
> about how -some- blind people want to be like sighted people (we call that 
> independence in my world), why not go help out? It's bad, you want a 
> switch, and you've already said that they're using a lib that is 
> unaccessible. So fix the lib, and you will have fixed tons of programs 
> without fixing the program. That is all I ment by finding the root of the 
> problem, not "everyone with readers should fix their health problems." You 
> take my words, blow them out of perportion and at the end of the day, you 
> are still sitting here complaining about the lack of accessibility, rather 
> than doing something about it. This is awesome. We for sure need more 
> complainers and less people to do what the complainers are complaining 
> about!


The solution for accessibility doesn't need to be found because it is 
already found.
Making Tkinter accessible won't matter if it won't be used in Python 
anymore.

Or is there a God law that tells that only Tk-based GUIs can be included in 
Python?

Octavian

in 650595 20110124 192332 Bryan <bryan.oakley@gmail.com> wrote:
>On Jan 24, 12:05=A0pm, rantingrick <rantingr...@gmail.com> wrote:
>> On Jan 24, 12:00=A0pm, Bryan <bryan.oak...@gmail.com> wrote:
>>
>> > Accessibility, like internationalization, is something few programmers
>> > spend much time thinking about.
>>
>> Thats another uninformed statement by you we can add to the mountains
>> of useless cruft you have offered so far. Unicode IS
>> internationalization and Guido thought it was SO important that
>> Python3000 auto converts all strings to Unicode strings. Obviously he
>> is moving us toward full Unicode only in the future (AS SHOULD ALL
>> IMPLEMENTATIONS!). We need one and only one obvious way to do it. And
>> Unicode is that way.
>
>Ok, great. You've identified one programmer who thinks about
>internationalization. Not much of a compelling argument there.
>
>However, I think you missed my point. My point wasn't that people like
>Guido don't think of these topics. It's that the people in the
>trenches who use these tools don't think about these topics. How many
>of your co-workers actively think about internationalization and
>accessibility? I'm guessing none, but maybe you're lucking and work in
>a particularly enlightened team. I've perhaps worked closely with a
>few hundred programmers in my career, and very few of them thought of
>these subjects. In my experience it's just not something the
>programmer in the trenches thinks about. That is the point I was
>trying to make.

Sorry, but I have to disagree with you here.  I spent my working life as a programmer
with a very large multi-national IT company and all software had to be fully
"internationalized" (otherwise known as NLS) or it didn't get used.  
Do you think the whole world speaks US English? 

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigECC27F0DD9A0AD9BE1551EB4
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 1/24/11 10:44 PM, Octavian Rasnita wrote:
> Or is there a God law that tells that only Tk-based GUIs can be include=
d
> in Python?

There is no other viable option at this time for inclusion in the
standard library; that's simple fact.

There are options for people to write GUI's in python that are
accessible. Those options do include the requirement of installing a
third-party library. That's not onerous.

Removing TK from the standard library at this point can't happen (at
least until a theoretical Python 4K): at least not without a 100%
compatible replacement which is functionally impossible (since it would
have to be compatible with TK addons, too).

Adding a secondary GUI framework would have to have an incredibly
compelling argument behind it: and developers pledging years of
maintenance in the python stdlib tree and with the python stdlib
development practices, because python-dev is overworked as it is. It
would need to be based on python 3.[2|3], need extensive tests and
documentation in a format compatible with python.org's documentation,
and solid cross-platform capability AND it be free of segfaultness, AND
the more code it is the harder it is to support its inclusion, as the
maintenance burden just becomes untenable-- and it would need to be
PEP-8 compliant-- and--

All of that doesn't hold for wxPython.

I use wxPython in my day job. I like wxPython a lot.

It belongs outside of the standard library.

If someone wants to devote man-years of development time to solve all of
the above to make it fit the stdlib, all power to you.

So far, it seems there maybe is two people who think it may be worth
their time.

I'm fine with installing wxPython as a third-party library.

--=20

   Stephen Hansen
   ... Also: Ixokai
   ... Mail: me+list/python (AT) ixokai (DOT) io
   ... Blog: http://meh.ixokai.io/


--------------enigECC27F0DD9A0AD9BE1551EB4
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (Darwin)

iQEcBAEBAgAGBQJNPonQAAoJEKcbwptVWx/lJ1cH/1irJkF9pOsQxeYFsmjP8j78
Zn2OIlKCcb/LT8oFZsvDvq5rkBnIy4nhDkN7XfA1oQOb7Cb482At4BKa8ee47fUr
WP2rIzT46faRgfybovGh9SL0Io/zjQ4Nezwe9u83aFCjscy4gdbF++h3daoBqMtg
w9QJTYjHrWHEqUjPBN8EtTiuy8lRmesi4Y9yRfqsO2HOB96ReVsuvqOAohMBwfLN
hvSI8xBkbZP+zbxjNq7z/NCSHi3tD5lFiCAbl4hjwUUk+i7nLWg0OOxzhkTSqi6s
uz820+FoPW/mfiogS39e7SNTxkgc2GOXPQofiFoGiZoBFdcwvPbYeaor4LheShs=
=uNs/
-----END PGP SIGNATURE-----

--------------enigECC27F0DD9A0AD9BE1551EB4--

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigF7F9E8A9A560379159DD9838
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 1/24/11 11:58 AM, Octavian Rasnita wrote:
>> From: "Ethan Furman" <ethan@stoneleaf.us>
>> Please do not repost rr's crap in its entirety, or you'll find yoursel=
f=20
>> added to many killfiles -- just like he is.
> I am not posting anyone's crap. I just informed why Tkinter is bad.
> And I also don't say that WxPython is ideal, but just that it has some =
very important features that Tk doesn't offer.

Belatedly: The complaint was not that you had something to say in reply,
but that as you replied, you quoted the entire original post.

Netiquette holds that you should edit out your replies to include only
those things / statements you're actually responding to.

By just blanket replying and including the whole rant, you are posting
that whole rant. Needlessly, as its already been said.  If you cut it
down and only include the points that you're responding to, you include
the specific context needed to understand your statements, while
minimizing the need for people to parse through noise.

--=20

   Stephen Hansen
   ... Also: Ixokai
   ... Mail: me+list/python (AT) ixokai (DOT) io
   ... Blog: http://meh.ixokai.io/


--------------enigF7F9E8A9A560379159DD9838
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (Darwin)

iQEcBAEBAgAGBQJNPo7mAAoJEKcbwptVWx/lMI8H/iDtfl2Mjh/XpmKjHIUeQhy2
u08boon9dZJZqg4MHiVQ96Hg96AWkhyAfuMX4aOazItBt5Jv1caY0tfJPIQniMOc
qyDkxJcXK9pDwjckKZuHwM22K0Hkt6H4D0ZbdEmBrN6721Mb3/KG6rgcdytRVbZr
I6ncbliX2PRvB01qqWf3Gw9N2TvT53S4WuUtY9iRYSRpiLbSUk6SaHvSbiE2SMbn
sAvTfyZQ0bRb3NvPFco2GOH/t6EcQhnpPokMgivpT7QG30Y3aXSn6kzZtEfofnqC
OqqsKn2+sHyxcoZO5hiIBj2dgjoOoA9s9rocvrsfPdOoaL7UqcpPdHwAlJIKVPw=
=SNV8
-----END PGP SIGNATURE-----

--------------enigF7F9E8A9A560379159DD9838--

On Jan 25, 2:02=A0am, Bob Martin <bob.mar...@excite.com> wrote:
> in 650595 20110124 192332 Bryan <bryan.oak...@gmail.com> wrote:
>
>
>
>
>
> >On Jan 24, 12:05=3DA0pm, rantingrick <rantingr...@gmail.com> wrote:
> >> On Jan 24, 12:00=3DA0pm, Bryan <bryan.oak...@gmail.com> wrote:
>
> >> > Accessibility, like internationalization, is something few programme=
rs
> >> > spend much time thinking about.
>
> >> Thats another uninformed statement by you we can add to the mountains
> >> of useless cruft you have offered so far. Unicode IS
> >> internationalization and Guido thought it was SO important that
> >> Python3000 auto converts all strings to Unicode strings. Obviously he
> >> is moving us toward full Unicode only in the future (AS SHOULD ALL
> >> IMPLEMENTATIONS!). We need one and only one obvious way to do it. And
> >> Unicode is that way.
>
> >Ok, great. You've identified one programmer who thinks about
> >internationalization. Not much of a compelling argument there.
>
> >However, I think you missed my point. My point wasn't that people like
> >Guido don't think of these topics. It's that the people in the
> >trenches who use these tools don't think about these topics. How many
> >of your co-workers actively think about internationalization and
> >accessibility? I'm guessing none, but maybe you're lucking and work in
> >a particularly enlightened team. I've perhaps worked closely with a
> >few hundred programmers in my career, and very few of them thought of
> >these subjects. In my experience it's just not something the
> >programmer in the trenches thinks about. That is the point I was
> >trying to make.
>
> Sorry, but I have to disagree with you here. =A0I spent my working life a=
s a programmer
> with a very large multi-national IT company and all software had to be fu=
lly
> "internationalized" (otherwise known as NLS) or it didn't get used. =A0
> Do you think the whole world speaks US English?

No, absolutely not. I don't see how you go from "I don't think all
developers think about i18n" to "I think everyone speaks english".

Most very large companies think about this a lot. Most hugely
successful software is probably internationalized. Together those two
groups make up a tiny fraction of all software. Think about all the
free software you use -- how much of it is internationalized and
optimized for accessibility? I bet not much. I wish I could say more
than half of all software is internationalized but I just don't
believe that to be true based on my own personal observation.

I definitely agree that many companies, both large and small, do the
right thing here. From my experience though, many !=3D most. I hope I'm
wrong though, because that means the we're all headed in the right
direction.

in 650672 20110125 115033 Bryan <bryan.oakley@gmail.com> wrote:
>On Jan 25, 2:02=A0am, Bob Martin <bob.mar...@excite.com> wrote:
>> in 650595 20110124 192332 Bryan <bryan.oak...@gmail.com> wrote:
>>
>>
>>
>>
>>
>> >On Jan 24, 12:05=3DA0pm, rantingrick <rantingr...@gmail.com> wrote:
>> >> On Jan 24, 12:00=3DA0pm, Bryan <bryan.oak...@gmail.com> wrote:
>>
>> >> > Accessibility, like internationalization, is something few programme=
>rs
>> >> > spend much time thinking about.
>>
>> >> Thats another uninformed statement by you we can add to the mountains
>> >> of useless cruft you have offered so far. Unicode IS
>> >> internationalization and Guido thought it was SO important that
>> >> Python3000 auto converts all strings to Unicode strings. Obviously he
>> >> is moving us toward full Unicode only in the future (AS SHOULD ALL
>> >> IMPLEMENTATIONS!). We need one and only one obvious way to do it. And
>> >> Unicode is that way.
>>
>> >Ok, great. You've identified one programmer who thinks about
>> >internationalization. Not much of a compelling argument there.
>>
>> >However, I think you missed my point. My point wasn't that people like
>> >Guido don't think of these topics. It's that the people in the
>> >trenches who use these tools don't think about these topics. How many
>> >of your co-workers actively think about internationalization and
>> >accessibility? I'm guessing none, but maybe you're lucking and work in
>> >a particularly enlightened team. I've perhaps worked closely with a
>> >few hundred programmers in my career, and very few of them thought of
>> >these subjects. In my experience it's just not something the
>> >programmer in the trenches thinks about. That is the point I was
>> >trying to make.
>>
>> Sorry, but I have to disagree with you here. =A0I spent my working life a=
>s a programmer
>> with a very large multi-national IT company and all software had to be fu=
>lly
>> "internationalized" (otherwise known as NLS) or it didn't get used. =A0
>> Do you think the whole world speaks US English?
>
>No, absolutely not. I don't see how you go from "I don't think all
>developers think about i18n" to "I think everyone speaks english".

I said "US English", not just English, and you didn't say 
"I don't think all developers think about i18n", you said "I'm guessing none".
Big difference.  I think your attitude to this is US-only.

>
>Most very large companies think about this a lot. Most hugely
>successful software is probably internationalized. Together those two
>groups make up a tiny fraction of all software. Think about all the
>free software you use -- how much of it is internationalized and
>optimized for accessibility? I bet not much. I wish I could say more
>than half of all software is internationalized but I just don't
>believe that to be true based on my own personal observation.

"I bet not much" - there you go again ;-)
You'll find that nearly all software used in Europe (and most other parts)
is internationalized or it wouldn't stand a chance.
 
>
>I definitely agree that many companies, both large and small, do the
>right thing here. From my experience though, many !=3D most. I hope I'm
>wrong though, because that means the we're all headed in the right
>direction.

Mark,

> From my queries to some of the Tcl/Tk folks, it seems that while the knowledge and expertise is not present in the core developer 
community, they would be more than happy to help people who do have some
knowledge in this area so that Tk could be made to be more accessible.

Some ideas here:

Linux: Linux users can use the free and small Tka11y library from the
site below. To use this library, one replaces "import Tkinter" with
"import Tka11y" - couldn't be easier!
http://tkinter.unpythonic.net/wiki/Tka11y

Mac OS X: Quoting Arndt Roger Schneider from this list: "I think Tk-aqua
(also 8.6) should work out-of-the-box with brail-lines, text-to-speech
and such; the older carbon built however won't." I'm not sure what is
involved in using an independent version of Tkinter that's newer than
the build of Tkinter that ships with the standard library?

Windows: While there appears(?) to be no built-in accessability for
Windows versions of Tkinter I've seen Windows Tkinter applications that
have used Windows native TTS functionality to provide a limited form of
accessability for users with poor vision.

> And if/when this does get done for Tk, I promise at least to make sure that the tutorial at http:///www.tkdocs.com covers this topic

I really enjoyed your tkdocs.com site!! Based on the new ttk
functionality you covered on your site, my company actually began moving
GUI projects from wxPython back to Tkinter. How's that for an odd
trend?! :)

Malcolm

On Jan 25, 6:03=A0am, Bob Martin <bob.mar...@excite.com> wrote:
> in 650672 20110125 115033 Bryan <bryan.oak...@gmail.com> wrote:
> >> Do you think the whole world speaks US English?
>
> >No, absolutely not. I don't see how you go from "I don't think all
> >developers think about i18n" to "I think everyone speaks english".
>
> I said "US English", not just English, and you didn't say
> "I don't think all developers think about i18n", you said "I'm guessing n=
one".
> Big difference. =A0I think your attitude to this is US-only.

Ah! Now I understand your comment. Yes, without realizing it I was
referring only to software developers in the US not having an
internationalization mindset. I should have been more clear, and
obviously I was making a poor generalization.

Do non-US-based developers focus a lot on accessibility too, since
that's what really started this whole sub-thread?

Just trying to sift the BS from the real issues

Heres a list of the issues relating to GUI toolkits


Look
Nativity-1 (as in apps look like other apps on the OS)
Nativity-2 (as in uses 'bare-metal' and not a separate interpreter)
Themeing (ttk)
Efficiency (extra interpreter)
Cross Platform
Stability (crashes on some OSes)
Programmability
Accessibility
i18n
Availability of gui builder
Licence

in 650680 20110125 151901 Bryan <bryan.oakley@gmail.com> wrote:
>On Jan 25, 6:03=A0am, Bob Martin <bob.mar...@excite.com> wrote:
>> in 650672 20110125 115033 Bryan <bryan.oak...@gmail.com> wrote:
>> >> Do you think the whole world speaks US English?
>>
>> >No, absolutely not. I don't see how you go from "I don't think all
>> >developers think about i18n" to "I think everyone speaks english".
>>
>> I said "US English", not just English, and you didn't say
>> "I don't think all developers think about i18n", you said "I'm guessing n=
>one".
>> Big difference. =A0I think your attitude to this is US-only.
>
>Ah! Now I understand your comment. Yes, without realizing it I was
>referring only to software developers in the US not having an
>internationalization mindset. I should have been more clear, and
>obviously I was making a poor generalization.
>
>Do non-US-based developers focus a lot on accessibility too, since
>that's what really started this whole sub-thread?

I don't think so; it was never a requirement for the software I wrote,
though I know I had some blind users.  But NLS was a must and it has
to be designed in from the start - very difficult to add it later.

On Jan 25, 9:29=A0am, rusi <rustompm...@gmail.com> wrote:
> Just trying to sift the BS from the real issues
>
> Heres a list of the issues relating to GUI toolkits


Finally someone who knows what the argument is really about! Thanks
rusi!

> Look

There is no doubt wxPython has better look and feel. (+1 wx)

> Nativity-1 (as in apps look like other apps on the OS)

Again (+1 wx)

> Nativity-2 (as in uses 'bare-metal' and not a separate interpreter)

Well Tk uses a separate interpretor so (+1 wx)

> Themeing (ttk)

Yes Tk has themes now. Not sure about how useful they are and what wx
offers so (+0 both)

> Efficiency (extra interpreter)

Well wx is by far more efficient (+1 wx)

> Cross Platform

Wx is cross platform but has some warts. We need to create an
abstraction API to insulate the new users from segfaults and make wx a
safe cross platform GUI so (+1 Tkinter)

> Stability (crashes on some OSes)

Wx is stable but does has some warts as is. (+1 Tkinter)

> Programmability

Wx needs a better API whereas Tkinter is ok (+1 Tkinter)

> Accessibility

Well we know Tkinter in not accessable (+1 wx)

> i18n

(+1 wx)

> Availability of gui builder

+0 both

> Licence

Tkinter is completely open source and wx is LGPL. Some find this to be
a problem however i don't (+0 both)


Tkinter: 3
wxPython: 6

On Jan 25, 9:37=A0am, Bob Martin <bob.mar...@excite.com> wrote:

> I don't think so; it was never a requirement for the software I wrote,
> though I know I had some blind users. =A0But NLS was a must and it has
> to be designed in from the start - very difficult to add it later.

Thats the point i keep trying to make about accessibility. Those who
are affected directly by accessibility (the users) are not in control
of accessibilities inclusion. However those that are in control are
twice removed from the torments of needing accessibility.

What is wrong with this picture?

Well specifically, if the developers refuse (or are oblivious) to
include accessibility support then the users are just screwed! Plain
and simple. GUI library developers have a responsibility to include
support for accessibility because if they don't no one else can!

On 1/25/2011 7:03 AM, Bob Martin wrote:

> "I bet not much" - there you go again ;-)
> You'll find that nearly all software used in Europe (and most other parts)
> is internationalized or it wouldn't stand a chance.

I suspected that is true of today's Europe, but do you have any evidence 
that software written in Japan, for instance, is any more 
internationalized than US software? I would expect the opposite since 
they tend to use, and still use their Japanese-only encodings with their 
unique writing system.

-- 
Terry Jan Reedy

On 1/25/2011 10:29 AM, rusi wrote:
> Just trying to sift the BS from the real issues
>
> Heres a list of the issues relating to GUI toolkits
>
>
> Look
> Nativity-1 (as in apps look like other apps on the OS)
> Nativity-2 (as in uses 'bare-metal' and not a separate interpreter)
> Themeing (ttk)
> Efficiency (extra interpreter)
> Cross Platform
> Stability (crashes on some OSes)
> Programmability
> Accessibility
> i18n
> Availability of gui builder
> Licence

Good as far as it goes, but this list leaves out several requirements 
(already posted by me, Steve Hansen, and others) for a Python 3 new 
stdlib module. It does not matter for the stdlib if wxpython is 3 times 
as good as tkinter, by some measure, as long as it is ineligible.

-- 
Terry Jan Reedy

On Jan 25, 12:15=A0pm, Terry Reedy <tjre...@udel.edu> wrote:
> On 1/25/2011 10:29 AM, rusi wrote:
>
>
>
>
>
>
>
>
>
> > Just trying to sift the BS from the real issues
>
> > Heres a list of the issues relating to GUI toolkits
>
> > Look
> > Nativity-1 (as in apps look like other apps on the OS)
> > Nativity-2 (as in uses 'bare-metal' and not a separate interpreter)
> > Themeing (ttk)
> > Efficiency (extra interpreter)
> > Cross Platform
> > Stability (crashes on some OSes)
> > Programmability
> > Accessibility
> > i18n
> > Availability of gui builder
> > Licence
>
> It does not matter for the stdlib if wxpython is 3 times
> as good as tkinter, by some measure, as long as it is ineligible.

Terry, i think rusi was just posting a general list of some likable
attributes of a 21st century GUI library. No were did he mention the
words "wx" or "python".

------------------
 The Sad Reality
------------------
Sadly the fact is that the "elite" have already made a decision. And
they don't care how bad "Tkinter" is for Python's stdlib or how good
"GUI library X" is for Python's stdlib. They do not want to make a
change. They are in bed with TclTk. They have lost all vision. This is
the reality.

---------------------------
 What can we do about it?
---------------------------
However, like all totalitarian regimes, when the peasants start
demanding equality and then storm the castle... then and only then
will the closed minded and selfish elite listen! So we need to make
noise, a lot of noise. And we need to be persistent. We need to demand
equality through accessibility. We need to demand feature rich
libraries that do not cripple us like Tkinter. We need to demand that
Pythons community re-establish a vision for the future. A vision that
is representative of ALL the people -- and not a few fat cats at the
top.

--------------------------------
 From Dictatorship to Democracy
--------------------------------
I have time and time again given examples of how python-dev can get a
real idea of what the wider community is thinking. One of these ideas
would be to send out a "Tkinter Removal Warning" that would be
displayed when the Python installer was run and every time Tkinter is
imported. The warning would show a website were people could vote to
keep Tkinter in the stdlib. This is the only way we can truly
understand what our community members are thinking about Tkinter.
Anything else is purely speculation.

-----------------------------------------------
 The silence of the peasants, and an awakening
-----------------------------------------------
Many folks out there share our views that Tkinter is a weight around
Python's neck, however they are too fearful to speak out for fear of
excommunication (the kill file!). However i must tell all of you that
just as other nations have risen against their own brutal governments
and survived, so to shall you IF you combine your voices as one. There
is power in numbers that no "elite theocracy" can deny. United we can
re-establish the original dream that build Python. Guido forged the
path and we must not let his work be in vain. But now the community
has been so overrun with trolls, naysayers, and negative mind sets
that infect any semblance of civility and remove good judgment from
our coffers. We are doomed unless we re-awake the dream.

From: "Bryan" <bryan.oakley@gmail.com>
Do non-US-based developers focus a lot on accessibility too, since
that's what really started this whole sub-thread?

Almost nobody focuses on accessibility, and nobody should focus on =
accessibility.

If you target a program for your national population and your national =
population speak a single language, then no, you won't need to use I18N.

If you create a graphic design application so you evidently target it to =
the sighted people, it is obviously that you won't need to make an =
accessible application.

But if you make a program that could be used by the whole world then you =
should use I18N and that program should also be accessible to everyone, =
not only sighted, or only English-speakers, because otherwise that =
application creates discrimination.
Usually I18N is offered using gettext so the users that want that =
application translated in their language can do the translation =
themselves, but if the application uses Tkinter, those who need a screen =
reader cannot do absolutely anything to make it accessible.

And Tyler's idea that if he finds an inaccessible application he can try =
to makes its own is not a valid idea, because not all the millions of =
users are programmers.

Octavian

From: "rantingrick" <rantingrick@gmail.com>
> Availability of gui builder

+0 both



I thought that there are a few GUI builders for Wx. Isn't this true?

Octavian

From: "Terry Reedy" <tjreedy@udel.edu>
> Good as far as it goes, but this list leaves out several requirements=20
> (already posted by me, Steve Hansen, and others) for a Python 3 new=20
> stdlib module. It does not matter for the stdlib if wxpython is 3 =
times=20
> as good as tkinter, by some measure, as long as it is ineligible.



Why is WxPython ineligible?
I ask because I want to be sure I understand. I remember just that =
reason that there are no enough maintainers in order to be a good =
default GUI for Python, which is a real problem if it is true.

Octavian

From: "Bob Martin" <bob.martin@excite.com>
....
>>Do non-US-based developers focus a lot on accessibility too, since
>>that's what really started this whole sub-thread?
>=20
> I don't think so; it was never a requirement for the software I wrote,
> though I know I had some blind users.  But NLS was a must and it has
> to be designed in from the start - very difficult to add it later.




:-)
Remembering about MSAA (MS Active Accessibility), what you said makes me =
think to "Active Discrimination".

It seems that for comercial reasons those who need to use a screen =
reader are discriminated because it is not profitable to make the effort =
to make an accessible program.
This is a valid problem and the companies can't and shouldn't be forced =
to offer accessibility if this causes them financial damages.
That's why the prefered solutions for creating a GUI should be one which =
is relatively accessible out of the box, because in that case the =
programmers don't even need to think to accessibility, but it is =
offered.

Octavian

From: "Terry Reedy" <tjreedy@udel.edu>
To: <python-list@python.org>
Sent: Tuesday, January 25, 2011 8:07 PM
Subject: Re: WxPython versus Tkinter.


> On 1/25/2011 7:03 AM, Bob Martin wrote:
>=20
>> "I bet not much" - there you go again ;-)
>> You'll find that nearly all software used in Europe (and most other =
parts)
>> is internationalized or it wouldn't stand a chance.
>=20
> I suspected that is true of today's Europe, but do you have any =
evidence=20
> that software written in Japan, for instance, is any more=20
> internationalized than US software? I would expect the opposite since=20
> they tend to use, and still use their Japanese-only encodings with =
their=20
> unique writing system.



Yes Terry, you are right. In the cases where the software is targetted =
only to japanese speakers (but I can't imagine an example) making only =
japanese applications is OK.
But as probably most of the software could be used by those who can't =
read hiragana/katakana/kanji if it would offer I18N, then it is not OK.

Nobody should be blamed for making a bad software. Not the americans, =
not the japanese and not the europeans (because in Europe there are also =
a lot of uni-lingual applications).=20
The bad software which is not accessible for some people, (because the =
language is not accessible or because the interface is not accessible) =
is usually made because of commercial constraints, or because of time =
constraints, or simply because of lack of knowledge about these issues.

The people should be very well informed, and constantly, and not only on =
a single thread ona single mailing list and after many years or even =
generations, the things will change hopefully.

The ones that should be blamed are those who know about these =
inaccessibility problems but simply don't care.

Octavian

On Jan 25, 1:35=A0pm, "Octavian Rasnita" <orasn...@gmail.com> wrote:
> From: "rantingrick" <rantingr...@gmail.com>
>
> > Availability of gui builder
>
> +0 both
>
> I thought that there are a few GUI builders for Wx. Isn't this true?

Oops! Yes it seems there are. I was unaware of them since i never use
GUI builders. So another +1 for wxPython!

Here are a few i found...

  http://wxglade.sourceforge.net/index.php#description
  http://boa-constructor.sourceforge.net/

Thanks for correcting me Octavian.

On 1/25/2011 11:25 AM rantingrick said...

<snip same old same old>

Classic insanity.

Emile

On 1/25/2011 11:38 AM Octavian Rasnita said...
> From: "Terry Reedy"<tjreedy@udel.edu>
>> Good as far as it goes, but this list leaves out several requirements
>> (already posted by me, Steve Hansen, and others) for a Python 3 new
>> stdlib module. It does not matter for the stdlib if wxpython is 3 times
>> as good as tkinter, by some measure, as long as it is ineligible.
>
>
>
> Why is WxPython ineligible?

I think Terry's point was compatibility with python3 -- which wx 
apparently isn't yet.

Emile

> You'll find that nearly all software used in Europe (and most other parts)
> is internationalized or it wouldn't stand a chance.

You mean, in lines of code? I very much doubt that. A lot of software
gets written, in particular for web servers, that is only German, around
here. Nobody thinks this is wrong, since the audience is expected to
speak German, anyway.

I think all the shell scripts that people write every day account for
more lines of code than operating systems, office software, server
applications, web frameworks combined. And these one-time use pieces
of software are certainly not internationalized - not even in companies
that have a policy that all software must support i18n.

If you want examples, here are some:

http://www.heise.de/ct/foren/ (web forum)
http://arztsuche.spiegel.de/ (medical directory)
http://portal.mytum.de/termine/index_html (university calendar - the
software itself is bilingual; the content is not at all)
etc.

Regards,
Martin

On 01/23/2011 02:11 PM, Littlefield, Tyler wrote:
> I hardly think that your tone, attitude and arguments are going to help 
> you in your battle to prove that WXPython is superior to anything at 
> all, if you can't manage to provide cross-platform bug-free code. 

Sadly you're wasting your breath.  He just doesn't understand what you
are saying.  Further he honestly does not think he has an attitude or
fallacious arguments.  I find his posts fascinating, really.  In the
meantime I suppose we can reply for sport (not a fair fight really), or
just leave him be.

On Sun, 23 Jan 2011 09:21:57 -0800, rantingrick wrote:
> Wait a minute, i am confused? What language is Python written in? Oh
> thats right Lisp! I am so dumb. How did i even get this job? :-)

What job is this?  Inquiring minds wish to know.

On Jan 25, 7:19=A0pm, Michael Torrie <torr...@gmail.com> wrote:
> On Sun, 23 Jan 2011 09:21:57 -0800, rantingrick wrote:
> > Wait a minute, i am confused? What language is Python written in? Oh
> > thats right Lisp! I am so dumb. How did i even get this job? :-)
>
> What job is this? =A0Inquiring minds wish to know.

On Jan 25, 7:19pm, Michael Torrie <torr...@gmail.com> wrote:

> What job is this? Inquiring minds wish to know.


Well my job is that of any humble community member. To be an intrical
part of a large heterogeneous group of folks all working toward a
common goal, who may *not* always and completely agree, however, all
of whom respect one another on a basic and fundamental level. Each
member has a responsibility to listen contently to his fellow members
ideas and offer objective responses devoid of emotional baggage. Each
member should gracefully and selflessly help those who are new to the
group to feel more welcome. And most importantly we should all
collectively keep our minds focused for the future of Python. We must
not let Python grow stagnate. No, we must constantly push for further
evolution. These changes will at times seem too painful to bear, that
can be expected. However the changes are vital for our future
evolution. For without change we would squander all the hard work of
the many who have come before us. But together, united in community,
and in vision, we shall keep the Python dream alive for many years to
come!

On Jan 25, 11:15=A0pm, Terry Reedy <tjre...@udel.edu> wrote:
> On 1/25/2011 10:29 AM, rusi wrote:
>
>
>
> > Just trying to sift the BS from the real issues
>
> > Heres a list of the issues relating to GUI toolkits
>
> > Look
> > Nativity-1 (as in apps look like other apps on the OS)
> > Nativity-2 (as in uses 'bare-metal' and not a separate interpreter)
> > Themeing (ttk)
> > Efficiency (extra interpreter)
> > Cross Platform
> > Stability (crashes on some OSes)
> > Programmability
> > Accessibility
> > i18n
> > Availability of gui builder
> > Licence
>
> Good as far as it goes, but this list leaves out several requirements
> (already posted by me, Steve Hansen, and others) for a Python 3 new
> stdlib module. It does not matter for the stdlib if wxpython is 3 times
> as good as tkinter, by some measure, as long as it is ineligible.
>
> --
> Terry Jan Reedy

Thanks Terry -- so I add that to the list

Works with Python 3
Look
Nativity-1 (as in apps look like other apps on the OS)
Nativity-2 (as in uses 'bare-metal' and not a separate interpreter)
Themeing (ttk)
Efficiency (extra interpreter)
Cross Platform
Stability (crashes on some OSes)
Programmability
Accessibility
i18n
Availability of gui builder
Licence

I should have mentioned earlier (doing it now) -- it maybe better to
deal with this list breadth-first -- ie to expand it to include all
the issues rather than going depth-first into each one.
There are surely others like:
Fun to use (very important when teaching/learning but hard to
quantify)

RR: You gave equal weights to each point. This does not work in
general. eg I am chary about using a toolkit that crashes (If crashes
are ok why not use C/C++ ?)

And there is another dimension to the "breadth" which needs inclusion
-- Qt and Gtk are equally contenders with Tkinter and Wx. (Any others
Ive missed?)

From: "Emile van Sebille" <emile@fenx.com>
>> Why is WxPython ineligible?
>
> I think Terry's point was compatibility with python3 -- which wx 
> apparently isn't yet.
>
> Emile


Well, I didn't know this, and it is a valid reason.
This means that it is true that there is no enough maintainance force to 
keep WxPython updated.
Did I understand correctly?

Octavian

On 1/25/2011 10:08 PM Octavian Rasnita said...
> From: "Emile van Sebille" <emile@fenx.com>
>>> Why is WxPython ineligible?
>>
>> I think Terry's point was compatibility with python3 -- which wx
>> apparently isn't yet.
>>
>> Emile
>
>
> Well, I didn't know this, and it is a valid reason.
> This means that it is true that there is no enough maintainance force to
> keep WxPython updated.
> Did I understand correctly?

Not at all -- wxPython is an active funded ongoing project. Review the 
roadmap at http://wiki.wxpython.org/TentativeRoadmap and particularly 
the final paragraph on Python3.x support.

Emile

On 1/26/11 10:00 AM, Emile van Sebille wrote:
> On 1/25/2011 10:08 PM Octavian Rasnita said...
>> From: "Emile van Sebille" <emile@fenx.com>
>>>> Why is WxPython ineligible?
>>>
>>> I think Terry's point was compatibility with python3 -- which wx
>>> apparently isn't yet.
>>>
>>> Emile
>>
>>
>> Well, I didn't know this, and it is a valid reason.
>> This means that it is true that there is no enough maintainance force to
>> keep WxPython updated.
>> Did I understand correctly?
>
> Not at all -- wxPython is an active funded ongoing project. Review the roadmap
> at http://wiki.wxpython.org/TentativeRoadmap and particularly the final
> paragraph on Python3.x support.

That's not Terry's point. The reasons he's referring to (and stated previously) 
are as follows:

1. The license of wxWidgets and wxPython is not as permissive as Python's. The 
Python developers, as a matter of policy, do not want to include code into the 
standard library that is less permissive than the current license.

2. The Python developers require someone to commit to maintaining contributed 
code for a number of years. No one has done so. See reason #3.

3. The wxPython developers do not want wxPython in the standard library, not 
least because they want to develop and release wxPython at a different pace and 
release cycle than the standard library.

4. The Python developers have committed to maintaining backwards compatibility 
in the standard library for a very long time. Even if they included wxPython 
into the standard library, they would have to provide a Tkinter module that 
works like the current one. I do not believe it is feasible to write a Tkinter 
workalike that uses wxPython, so we would still be relying on Tcl/Tk.

There is certainly enough maintenance force to keep wxPython updated and ported 
to Python 3, but only *outside* of the standard library.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco

On Jan 22, 6:07=A0pm, rantingrick <rantingr...@gmail.com> wrote:

> ---------------------------------------
> =A0Challenge 1: (Simple Directory Viewer)
> ---------------------------------------
>
> Create a simple Directory Viewer GUI. You CANNOT use a treectrl! =A0The
> point of this challenge is to show that Tkinter has no support for a
> true ListCtrl widget. However the Wx::ListCtrl is fully featured! For
> wxPython the code is simply wielding a few built in classes. For
> Tkinter no such ListCtrl functionality exists. You CAN create the
> functionality yourself (and i know this because i HAVE created it!)
> however it involves tons of work and still can't hold a candle to the
> wx::ListCtrl
>
> ---------------
> =A0Requirements:
> ---------------
>
> How the user navigates to a folder is not important but you must
> display the list of files/folders in two view modes with icons;
>
> =A01. Display files in both ReportView and ListView.
>
> =A0 * Reportview:
> =A0 =A0 ...scrollable vertical list with three columns.
>
> =A0 * Listview:
> =A0 =A0 ...scrollable horizontal-ly wrapping list.
>
> Note: If you do not understand the view modes just run my code for an
> example. But the user must be able to switch between these two modes
> easily. How the switching is done is unimportant -- I simply used two
> buttons.
>
> =A02. Columns
> =A0 * Minimum of three cols; Name, Size, and Type (reportview).
> =A0 * the "Name" column must include an icon AND label (both views).
> =A0 * columns must be sortable by the user (reportview).
> =A0 * columns must be sizable by the user (reportview).
>
> =A03. Items
> =A0 * All must be editable in place (no popup editing allowed!).
> =A0 * All items must be selectable/deselectable by user.
> =A0 * All items must be delete-able by the user.
>
> That is the challenge. Step forth and battle if you can!
>
> -----------------
> =A0WxPython code:
> -----------------
>
> https://sites.google.com/site/thefutureofpython/home/code-challenges
>
> I await any challengers...


So we have come this far and still not one challenger. Neither can one
person admit that the wxPython ListCtrl is far superior than widget
TclTk contains. But that really does not matter now. The point is that
TclTk have grown stagnate and have been that way for many years.
Whilst Tkinter does sport a beautiful API we have no way to scale the
module because TclTk is limited. New Python programmers will start out
(like i did) with Tkinter and love its simplicity, however eventually
they will come to understand that all their spend energy writing
Tkinter has been for nothing. They will realize that Tkinter is 1990's
technology migrated into the 21st century. That is point i am making.
Some people can handle the truth. Denial is to be expected.

If you are out there and your not one of the redundant trolls who keep
parroting off and assassination my character please drop by and insert
your opinion on the value of Tkinter. Just make sure to use facts and
not emotion driven drivel. If you choose to be a troll i cannot stop
you, and i would not. However i will not respond to trollish posts
anymore. It is quite clear that a hand full of the same old folks want
to stop me at all costs -- even at the expense of their own soul.
Psst: If you notice they are not yelling about the code anymore
because it is bug free. They are only interested in spreading
discontent and not solving problems. That is a blindingly apparent
fact.

Anyway i still await a solid challenge. Either in code or in words
based on facts. Until then i will consider myself victorious by
default.

From: "Emile van Sebille" <emile@fenx.com>
....
>> Well, I didn't know this, and it is a valid reason.
>> This means that it is true that there is no enough maintainance force =
to
>> keep WxPython updated.
>> Did I understand correctly?
>=20
> Not at all -- wxPython is an active funded ongoing project. Review the =

> roadmap at http://wiki.wxpython.org/TentativeRoadmap and particularly=20
> the final paragraph on Python3.x support.
>=20
> Emile



But somebody said that the core Python developers, or Guido said that =
WxPython won't be included in the core distribution because it doesn't =
have a strong team of maintainers... with other words but this was the =
idea.

So I still don't understand why WxPython can't be a good solution.

If WxPython is well maintained, let's pretend that the maintainers =
solved that bug that make the apps give a segfault, and let's pretend =
that it works under Python 3.

Can it be a good choice for replacing Tkinter?

I don't know why, but I have a feeling that even in these cases WxPython =
is still not wanted and I don't understand why.

I can see that the people try to find some false arguments like the one =
that WxPython is bigger than Tkinter, but really, who cares today about =
a few aditional megabytes?
What do you think it is more important, to offer accessibility for most =
of the users, or to create small applications?
(Note that I didn't say that Tkinter should be forbidden, so if somebody =
in some edge cases need to make a very small program, he/she could do it =
very well.)

So I still don't understand why WxPython wouldn't be prefered even all =
its problems would be solved.

Octavian

From: "Robert Kern" <robert.kern@gmail.com>
> That's not Terry's point. The reasons he's referring to (and stated =
previously)=20
> are as follows:
>=20
> 1. The license of wxWidgets and wxPython is not as permissive as =
Python's. The=20
> Python developers, as a matter of policy, do not want to include code =
into the=20
> standard library that is less permissive than the current license.

This is the worst and... sorry for the word, but real stupid thing.
I mean, I don't consider a correct thinking to care more about the =
permissiveness of a licence which is anyway open source, more than about =
the accessibility.
Try to think that for some people Tkinter displays just a black filled =
rectangle. In that case would you still think that it is "correct" to =
keep that kind of GUI because of some differences between open source =
licences?


> 2. The Python developers require someone to commit to maintaining =
contributed=20
> code for a number of years. No one has done so. See reason #3.

In that case I understand that there are enough WxPython developers, =
well funded, but there is no commitment from them.
>From Python's perspective, there are not enough maintainers that can =
offer that commitment and yes, this is a real reason why the core Python =
developers can't include WxPython.

> 3. The wxPython developers do not want wxPython in the standard =
library, not=20
> least because they want to develop and release wxPython at a different =
pace and=20
> release cycle than the standard library.


>From the message of a list member which (but maybe I am wrong) appear to =
be a WxPython developer, I suspected that the WxPython developers might =
not want their work to be included in the Python distribution.
I am not really sure about this because I haven't seen any message from =
a WxPython developer telling that yes, I am a WxPython developer and we =
don't want to allow including WxPython in the Python distro, and I =
almost don't believe that, but if it is true, I don't know why they =
didn't said that, because WxPython is their work and of course that if =
they don't accept to maintain a WxPython as apart of Python =
distribution, then this discussion doesn't have any meaning.

I have only heard that WxPython will never be included, but without =
beeing more clear.

Who knows, maybe some of those who said that are WxPython developers but =
for me they are just some names because I don't know them...

The next (or previous) points are not important anymore if the WxPython =
developers don't want their work to be included in the Python =
distribution.

So, is it true? That was the cause for which WxPython can't be promoted =
by Python? Because the WxPython developers don't want this?

If the answer is yes, then too bad, because as I said, it's their work =
and they can do whatever they like with it.

Octavian

On Jan 26, 10:35=A0am, Robert Kern <robert.k...@gmail.com> wrote:
> On 1/26/11 10:00 AM, Emile van Sebille wrote:

> That's not Terry's point. The reasons he's referring to (and stated previ=
ously)
> are as follows:
>
> 1. The license of wxWidgets and wxPython is not as permissive as Python's=
.. The
> Python developers, as a matter of policy, do not want to include code int=
o the
> standard library that is less permissive than the current license.

This is actually a weak argument and i'll explain why. GUI libraries
are very complicated and time consuming projects. Just think of all
the work involved just to get a library working on one platform...
much less THREE or more platforms! And while i am a huge believer in
100% open source software you've got to understand why most libraries
are restrictive for commercial usage or worse. Yes TclTk IS fully
opensource and i applaud them for it! However like the old adage say:
"You get what you pay for".

> 2. The Python developers require someone to commit to maintaining contrib=
uted
> code for a number of years. No one has done so. See reason #3.
>
> 3. The wxPython developers do not want wxPython in the standard library, =
not
> least because they want to develop and release wxPython at a different pa=
ce and
> release cycle than the standard library.

I have already shown why this does not matter. The current wxPython
API is NOT good for Python. We DO NOT want segfaults and "C++ looking"
code written by the users of a Python stdlib module. Robin has stated
that there exists room for an abstraction layer on top of wxPython and
he is correct. He has also stated that he wants to keep "his wxPython"
as close to WxWidgets as possible. So be it! We will never want to
include wxPython "proper" in the stdlib anyway because it is SO
unpythonic!! No. All we have to do is create an abstraction API that
calls wxPython until we can create OUR OWN wxPython from WxWidgets.
Call it Wxpy if you like.

> 4. The Python developers have committed to maintaining backwards compatib=
ility
> in the standard library for a very long time. Even if they included wxPyt=
hon
> into the standard library, they would have to provide a Tkinter module th=
at
> works like the current one. I do not believe it is feasible to write a Tk=
inter
> workalike that uses wxPython, so we would still be relying on Tcl/Tk.

Fine support Tkinter until Python4000 i don't care. But we must move
forward. We must accept that Tkinter is already legacy and there is no
moving forward now. We will support Tkinter for backwards
compadibility however we will start to integrate a truly Pythonic
WxPython abstraction API and include just the API module in the
stdlib. Then we don't have to maintain a huge library, just a small
module with a wxPython 3rd party dependency. Then at some point in the
future when the stdlib is ripe, we can THEN include some form of
wxWidgets, and dump Tkinter forever. At least then we would be moving
towards something. Currently we are stagnate.

>
> There is certainly enough maintenance force to keep wxPython updated and =
ported
> to Python 3, but only *outside* of the standard library.

So let wxPython due what wxPython does best. We will use them as long
as we need until we can create a stdlib compliant wxPython ourselves.
They would be fools not to work with us! Because eventually when no
3rd party download is needed, all their work would go into the bit
bucket. I doubt Robin is that foolish. He seems like a smart fellow to
me -- even though he refuses to comply with PEP8 :)



SUMMARY: We create an abstraction API atop "Robin's WxPython". We
include only the API in the stdlib at this time and we keep Tkinter in
maintenance. Then over the next few years we start a fresh wxPython
project that will be acceptable for the stdlib. Something that we can
plug our API into.  We steal as much from Robin as we can (or get him
to cooperate). Then when the time is right, we dump Tkinter and
integrate the new Wxpy module into the stdlib. Then we will be back on
track.

On 1/26/11 11:46 AM, Octavian Rasnita wrote:
> From: "Robert Kern"<robert.kern@gmail.com>
>> That's not Terry's point. The reasons he's referring to (and stated previously)
>> are as follows:
>>
>> 1. The license of wxWidgets and wxPython is not as permissive as Python's. The
>> Python developers, as a matter of policy, do not want to include code into the
>> standard library that is less permissive than the current license.
>
> This is the worst and... sorry for the word, but real stupid thing.
> I mean, I don't consider a correct thinking to care more about the permissiveness of a licence which is anyway open source, more than about the accessibility.

Being able to say that all of a project is available under the substantively the 
same license is really important. It's very hard to get people to use your 
software if some parts are under one license and other parts are under a 
substantively different one. You are free to decide what licenses you want to 
distribute software under; the PSF has that freedom as well.

> Try to think that for some people Tkinter displays just a black filled rectangle. In that case would you still think that it is "correct" to keep that kind of GUI because of some differences between open source licences?

This is a reason for application developers to use wxPython, not for the Python 
developers to include wxPython in the standard library. The standard library 
neither claims nor aims to do everything. There are many things that Tkinter 
cannot do that wxPython can. None of those things are reasons to replace Tkinter 
with wxPython in the standard library. Not everything useful has to be in the 
standard library. Python has a vibrant ecosystem of third party packages.

wxPython is probably the most widely used GUI toolkit in Python. It has not been 
harmed (and I would argue that it has been very much helped) by not being in the 
standard library. Nor has it been harmed by the presence of Tkinter in the 
standard library. If wxPython had been included in the Python standard library, 
it would not have been able to easily follow the advancements of the underlying 
wxWidgets toolkit, and it would be a much less strong GUI toolkit.

>> 2. The Python developers require someone to commit to maintaining contributed
>> code for a number of years. No one has done so. See reason #3.
>
> In that case I understand that there are enough WxPython developers, well funded, but there is no commitment from them.

Correct, they have not committed to maintaining wxPython as part of the standard 
library (although they are committed to maintaining wxPython outside of it). 
They have not even suggested that wxPython should be part of the standard library.

>> From Python's perspective, there are not enough maintainers that can offer that commitment and yes, this is a real reason why the core Python developers can't include WxPython.
>
>> 3. The wxPython developers do not want wxPython in the standard library, not
>> least because they want to develop and release wxPython at a different pace and
>> release cycle than the standard library.
>
>
>> From the message of a list member which (but maybe I am wrong) appear to be a WxPython developer, I suspected that the WxPython developers might not want their work to be included in the Python distribution.
> I am not really sure about this because I haven't seen any message from a WxPython developer telling that yes, I am a WxPython developer and we don't want to allow including WxPython in the Python distro, and I almost don't believe that, but if it is true, I don't know why they didn't said that, because WxPython is their work and of course that if they don't accept to maintain a WxPython as apart of Python distribution, then this discussion doesn't have any meaning.

Robin, if you're still paying attention to this thread, would you mind chiming 
in? Robin Dunn is the wxPython project lead.

> I have only heard that WxPython will never be included, but without beeing more clear.
> Who knows, maybe some of those who said that are WxPython developers but for me they are just some names because I don't know them...
>
> The next (or previous) points are not important anymore if the WxPython developers don't want their work to be included in the Python distribution.
>
> So, is it true? That was the cause for which WxPython can't be promoted by Python?

There is a large difference between the being "promoted by Python" and being 
"included in Python's standard library. The latter is the issue at hand, not the 
former. wxPython is already "promoted" by Python's documentation:

   http://docs.python.org/library/othergui.html

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco

On 26/01/2011 18:19, rantingrick wrote:
> SUMMARY: We create an abstraction API atop "Robin's WxPython". We
> include only the API in the stdlib at this time and we keep Tkinter in
> maintenance. Then over the next few years we start a fresh wxPython
> project that will be acceptable for the stdlib. Something that we can
> plug our API into.  We steal as much from Robin as we can (or get him
> to cooperate). Then when the time is right, we dump Tkinter and
> integrate the new Wxpy module into the stdlib. Then we will be back on
> track.

I look forward to reading your PEP and initial design documents, though 
I suspect you would need the latter and to get some a decent portion of 
work done before it would even be considered as an inclusion into the 
standard library.

I strongly suspect that your response to this suggestion would be the 
ironic "more talk and no action from X". Many capable developers have 
their own occupations and might not have the spare time or desire to 
spend on a project where all evidence suggests would be a 
(non-benevolent) dictatorship where they would be endlessly browbeaten.

You have continuously tried to outright present yourself as a 
'visionary' and speaker for the python community and then asked why 
people don't take you seriously. People would take you a lot more 
seriously if you showed that you had the vision and capability to drive 
development of such a serious undertaking, and manage such a team of 
developers, whom you have first managed to attract to the project.

If you actually seriously believe this should happen and that you are 
the best person to drive it, the way to go about it is probably:
  - Write some design documents, or even code, laying out what you think 
the interface should be.
  - Put it out to the community, listen to advice, make changes (it will 
NOT be perfect) and gather support.
  - Provide an initial implementation

Somebody in the old thread said something which made sense, which I 
paraphrase as:
   "Only idiots think they can command communities of equals."

This is something to keep closely in mind in your continuing, what can 
only be described as 'crusades'. This, along with the fact that people 
remember first impressions, and are usually cautious about reversing 
opinions developed through many examples of uncivility.

Heck, I am probably wasting my time with this post; but you come across 
as genuine in your held central beliefs, and so either serious or the 
most dedicated and adept troll I have ever encountered. In the case of 
the former, I hold an optimistic view that most people are capable of 
self-asessment. In the case of the latter, consider me successfully trolled.

Nick

On 1/26/11 11:19 AM, Octavian Rasnita wrote:
> From: "Emile van Sebille"<emile@fenx.com>
> ...
>>> Well, I didn't know this, and it is a valid reason.
>>> This means that it is true that there is no enough maintainance force to
>>> keep WxPython updated.
>>> Did I understand correctly?
>>
>> Not at all -- wxPython is an active funded ongoing project. Review the
>> roadmap at http://wiki.wxpython.org/TentativeRoadmap and particularly
>> the final paragraph on Python3.x support.
>>
>> Emile
>
> But somebody said that the core Python developers, or Guido said that WxPython won't be included in the core distribution because it doesn't have a strong team of maintainers... with other words but this was the idea.

No, you are misrepresenting what was said. What is required is that someone make 
an active commitment to maintain wxPython as part of the standard library 
*specifically*. That means that the package has to follow Python's release 
cycle. The wxPython developers do not wish to do that. They can develop wxPython 
much better outside of the standard library.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco

On Jan 27, 12:02=A0am, Nicholas Devenish <misno...@gmail.com> wrote:
>
> Heck, I am probably wasting my time with this post; but you come across
> as genuine in your held central beliefs, and so either serious or the
> most dedicated and adept troll I have ever encountered. In the case of
> the former, I hold an optimistic view that most people are capable of
> self-asessment. In the case of the latter, consider me successfully troll=
ed.

RR: I'd just like to add -- Do consider whom your verbal violence
hurts most.
You may also want to google for Erik Naggum

On Jan 26, 1:02=A0pm, Nicholas Devenish <misno...@gmail.com> wrote:

> I look forward to reading your PEP and initial design documents, though
> I suspect you would need the latter and to get some a decent portion of
> work done before it would even be considered as an inclusion into the
> standard library.

Yes i want to create an API similar to Tkinter but we cannot mirror
exactly Tkinter because wx takes a completely different approach to
GUI building. We need to steal all the good attributes of Tkinter (and
there are quite a few!), learn from them, and evolve the next
generation of API. Tkinter will not be a waste because we will stand
on the shoulders of Tkinter and reach even higher! Some of the
worthwhile "must haves" are:

 * Geometry managers (pack, place, grid)

The geometry managers of Tkinter are just too beautiful to let die. Wx
forces you to use Sizers which are a terrible obstacle to the new GUI
programmer. And if you want focus traversal then you must also use
Panels. This multiplicity is just too ugly for a high level API like i
am suggesting. We will need some auto generation of panels and easier
to use Sizers wrapped up in a nice Tkinter Geometry Manager like API.
This will take some work. However it can be done.

 * Tagging systems for a TextCtrl and Canvas.

Although i challenged Guido on his argument about tagging, i do much
agree that tagging is a *very* powerful feature of the TK::Text and
TK::Canvas widgets and we should no doubt incorporate this into the
API. And this would be one of the easier aspects of the design.

 * Event binding

Here is another area for improvement. While wx has been moving towards
a more "Tkinter like" binding of widget events there is still much to
be desired. However the binding is not all bad so we should not spend
too much time here if only for very small payoffs.

 * Segfaults

We must protect Python users from segfaults. This is really a
wxPython's problem however we could insulate the programmer through
many techniques on our end. Like for instance: Recreating the columns
of a list control after configuration of a single style. However
configuration needs a look at also!

 * Styles

One of the things that always bothered me about Tkinter was lack of
styles. I know this has been addressed however in the past one would
create many widgets that should share a similar style but Tkinter
forced you to feed redundant style options to all of them. We need a
way to create style objects and then use them everywhere. I think wx
supports this already.

This is just a very meager list. Much more needs consideration.
However this would be a good launch point toward some stated and
attainable goals. There is already a quite mature (citaion needed)
start with a project called wax. Check it out here...

   http://wiki.wxpython.org/Wax


> Many capable developers have
> their own occupations and might not have the spare time or desire to
> spend on a project where all evidence suggests would be a
> (non-benevolent) dictatorship where they would be endlessly browbeaten.

Well i don't want to be a dictator. I believe that in any healthy
community, every member should be a king, however no ONE member ever
wears the crown. What i mean is, everyone has a special skill that
makes them stand out from the crowd. Something that you do better than
the other members. So when the needs of my skill-set are present, i
will step forth and lead, and when the needs of your skill-set are
present, i will sit back and listen and follow YOUR lead. This is how
the strongest groups tackle the largest problems with ease.

> You have continuously tried to outright present yourself as a
> 'visionary' and speaker for the python community and then asked why
> people don't take you seriously. People would take you a lot more
> seriously if you showed that you had the vision and capability to drive
> development of such a serious undertaking, and manage such a team of
> developers, whom you have first managed to attract to the project.

Agreed, and i hope to demonstrate these skills soon. However like i
mentioned in my last statement, i am not a god, much less a dictator.
No single man or woman can accomplish these huge problems alone. It
takes a team of united folks all simultaneousness willing to lead AND
follow when the time is right for the greater good of a common goal.

>
> =A0 - Write some design documents, or even code, laying out what you thin=
k
> the interface should be.
> =A0 - Put it out to the community, listen to advice, make changes (it wil=
l
> NOT be perfect) and gather support.
>

I believe we are in this stage now. However much more discussion is
needed.

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig1F099B83A2E7133A75D8E3D4
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 1/26/11 9:19 AM, Octavian Rasnita wrote:
> From: "Emile van Sebille" <emile@fenx.com>
> ...
>>> Well, I didn't know this, and it is a valid reason.
>>> This means that it is true that there is no enough maintainance force=
 to
>>> keep WxPython updated.
>>> Did I understand correctly?
>>
>> Not at all -- wxPython is an active funded ongoing project. Review the=
=20
>> roadmap at http://wiki.wxpython.org/TentativeRoadmap and particularly =

>> the final paragraph on Python3.x support.
>=20
> But somebody said that the core Python developers, or Guido said that W=
xPython won't be included in the core distribution because it doesn't hav=
e a strong team of maintainers... with other words but this was the idea.=


That isn't, at all, what people said.

What they said was that for a new library to be included in the stdlib,
it must have maintainers willing to *commit* for years to *maintain* it
IN the stdlib.

Maintaining something in the stdlib is very different then maintaining
something out of the stdlib.

The stdlib has quite a few rules: and it evolves at a certain set speed.

wxPython is a wrapper around a third-party library which evolves at a
totally different rate: if wxPython were included in the stdlib, these
two completely separate development cycles could result in significant
hardship for the maintainers and more importantly, for the USERS.

Does Python now hold up a release waiting for the wxWidgets team to put
out a new version with great new features?

Or, does Python release as normal, and just by happenstance does
wxWidgets release a great new release a month later-- and now Python
users can't get it for a year or two when the next feature release of
Python is available?

Either way, the maintainers job is more difficult, and users are harmed.

There's a reason that libs that go into the stdlib tend to be very
static and extremely slow paced in their evolution.

Now, Robin could decide to maintain wxPython in two places: as a
third-party library, and every release cycle sync in the latest to the
core stdlib. That's been done: but its actually extremely problematic
itself, and is asking for a lot of extra work.

wxPython as a third-party library is maintained: certainly. But that
doesn't mean wxPython in the stdlib would be maintained.

Then again, it may be that they would be fine with moving into the
stdlib-- but since its not a viable option for numerous other reasons,
they never bothered to give it any real consideration.

> So I still don't understand why WxPython can't be a good solution.
> If WxPython is well maintained, let's pretend that the maintainers solv=
ed that bug that make the apps give a segfault, and let's pretend that it=
 works under Python 3.
> Can it be a good choice for replacing Tkinter?

That's hand-waving a LOT of stuff with "let's pretend", but okay. Let's
pretend that the lib is modified and fixed up so that segfaults don't
happen (and, IIUC, the next version may be); and let's pretend it works
under Python 3 (does that leave me in the dust, as someone who would
love to get some wxPython updates but who is only using Python 2.5?).

There's a bunch of hurdles that would need solving before its a
candidate for inclusion: (off the top of my head)

1. Tkinter can not be removed without a 100% compatible replacement for
the forseeable future. 100%. No exception on that 100%. This includes
people downloading TK extensions and using them in their Python apps:
because if thats not possible, real applications will fail.

  Please understand before you move on. This is one of the hurdles of
the stdlib that make maintaining something in it harder then maintaining
something out of it: there are strict compatibility requirements and
rules. It might be a great thing for humanity to have Python include an
accessible GUI toolkit in the standard library: but that doesn't mean
the rules can be broken in doing it.
  Since its basically impossible to be compatible as such, what you'd
have to do is add wx while leaving tk, not replacing it. So:

2. New additions must be PEP-8 compliant; wx is not.
3. New additions must include unit tests; I actually don't know if wx
does. I've always found it a pain in the butt to test GUI stuff-- but TK
is tested (to some degree, I'm not sure how good the coverage is: I just
remember tweaking my buildslave to make it run the tests :)).
4. The documentation would have to all be totally rewritten to fit the
stdlib documentation format
5. The license thing needs solving from a legal standpoint (new code is
traditionally donated to the PSF under the Apache license, which then in
turn re-licenses the code under the Python license). You may think its
stupid to let something like that get in the way, but sorry: we live in
a lawyer's world.
6. Someone would have to commit to maintaining it _in_ the stdlib.
7. Someone would have to work on integrating the wx build requirements
with the stdlib's build requirements for all the platforms -- and this
can be quite a bit. If this makes the release maintainers jobs a lot
harder ... well, they may need some more hands on deck.

=2E.. and more.

There's a lot of work there. A lot. A lot a lot. And that's just
hand-waving away some really significant obstacles with Let's Pretend.

Besides: did you know a not insignificant number of people would like to
do away with the stdlib in its entirety? And, more then a few actually
are pushing for the stdlib to be forked off of CPython, and instead end
up shared by all the major Python implementations (CPython, Jython,
PyPy, IronPython, what else?) as a common resource?

Not saying either group would win (though the latter sounds like a very
cool thing to me), but what does either say about the implication of
including wxPython?

> I can see that the people try to find some false arguments like the one=
 that WxPython is bigger than Tkinter, but really, who cares today about =
a few aditional megabytes?

I'm sorry, but you're confusing what you care about with what other
people care about. You do it a lot. But you seem actually honest in your
efforts, so I give you the benefit of the doubt.

Size does matter to some people, and legitimately so. Still others care
deeply about what is bundled with Python because they're in environments
where installing third-party libraries isn't allowed: these two
interests can stand in opposition to one-another, but that does not make
either /false/, and it does not mean that either is /right/.

There are many interests involved in a language like Python which has
broad usage in extremely varied fields and endeavors: most of which
never come near this list.

And some people have absolutely no need-- no need at all-- for any sort
of GUI programming at all. This group is actually really, really big.

The argument is not false: for YOU it is not compelling, and hell, for
me I don't find it compelling either. But it is a valid issue which has
to be weighed and taken into consideration. Maybe after that is done, on
balance, its deemed to be not that big of a deal. But maybe when added
up with other concerns, it is.

> What do you think it is more important, to offer accessibility for most=
 of the users, or to create small applications?

I think its important to do both.

And wxPython living on in a third-party library fits that perfectly well.=


--=20

   Stephen Hansen
   ... Also: Ixokai
   ... Mail: me+list/python (AT) ixokai (DOT) io
   ... Blog: http://meh.ixokai.io/


--------------enig1F099B83A2E7133A75D8E3D4
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (Darwin)

iQEcBAEBAgAGBQJNQH8LAAoJEKcbwptVWx/l4OoH/j7mpOGM7eFpASixgrx+Jsbd
Ar6Jt0rFrET9DaqLnXx079rAdaxuroQKapnbVnhgDjbgDK382lGpbAnI78LSZRZw
snfKgL2JW4q0tq6EhJzUMGUgeah9+6saGEwdVqLsnIIOoycKR4ol+MPyprfpciNX
QOAfyj77zX4X/5iF2QoH9M/dGa4XULrzZbPuKuaDDBU0Epc83Rp1n+qLqCF2EsMn
nhgAgVYxt3qjIyWDpW2hrCMrUcZ39I9V26zjTUf8mmNJNGN32gu7jKxjmi0B/8kD
ouBFH90OXX2NRIlKd5jQdZcAJ4sP73UIE/wMngi2q5yIadjJANHhZgUSsvjkDqI=
=UayU
-----END PGP SIGNATURE-----

--------------enig1F099B83A2E7133A75D8E3D4--

On Jan 26, 2:07=A0pm, Stephen Hansen <me+list/pyt...@ixokai.io> wrote:

> And some people have absolutely no need-- no need at all-- for any sort
> of GUI programming at all. This group is actually really, really big.

Stephen "Strawman" Hansen: If he only had a brain! :-)

That is the most obvious straw-man to date in this thread. What about
the large portion of folks who don't use all the datatypes (queue,
weakref, etc) or how about numeric and math modules (fractions,
decimal, etc) or how about data persistence, or Cryptograhic, or
curses! or, multimedia services, or, or.

You see NOT everyone uses everything in the stdlib and most use much
less than half. However we would be fools to claim "batteries
included" and NOT support GUI!

On Jan 26, 2:37=A0pm, rantingrick <rantingr...@gmail.com> wrote:
> On Jan 26, 2:07=A0pm, Stephen Hansen <me+list/pyt...@ixokai.io> wrote:
>
> > And some people have absolutely no need-- no need at all-- for any sort
> > of GUI programming at all. This group is actually really, really big.
>
> Stephen "Strawman" Hansen: If he only had a brain! :-)
>
> That is the most obvious straw-man to date in this thread. What about
> the large portion of folks who don't use all the datatypes (queue,
> weakref, etc) or how about numeric and math modules (fractions,
> decimal, etc) or how about data persistence, or Cryptograhic, or
> curses! or, multimedia services, or, or.
>
> You see NOT everyone uses everything in the stdlib and most use much
> less than half. However we would be fools to claim "batteries
> included" and NOT support GUI!

You show a remarkable, awe-inspiring ability to completely miss every
salient point of a well articulated argument.

On 1/26/2011 11:35 AM, Robert Kern wrote:
> On 1/26/11 10:00 AM, Emile van Sebille wrote:
>> On 1/25/2011 10:08 PM Octavian Rasnita said...
>>> From: "Emile van Sebille" <emile@fenx.com>
>>>>> Why is WxPython ineligible?
>>>>
>>>> I think Terry's point was compatibility with python3 -- which wx
>>>> apparently isn't yet.
>>>>
>>>> Emile
>>>
>>>
>>> Well, I didn't know this, and it is a valid reason.
>>> This means that it is true that there is no enough maintainance force to
>>> keep WxPython updated.
>>> Did I understand correctly?
>>
>> Not at all -- wxPython is an active funded ongoing project. Review the
>> roadmap
>> at http://wiki.wxpython.org/TentativeRoadmap and particularly the final
>> paragraph on Python3.x support.
>
> That's not Terry's point. The reasons he's referring to (and stated
> previously) are as follows:
>
> 1. The license of wxWidgets and wxPython is not as permissive as
> Python's. The Python developers, as a matter of policy, do not want to
> include code into the standard library that is less permissive than the
> current license.
>
> 2. The Python developers require someone to commit to maintaining
> contributed code for a number of years. No one has done so. See reason #3.
>
> 3. The wxPython developers do not want wxPython in the standard library,
> not least because they want to develop and release wxPython at a
> different pace and release cycle than the standard library.
>
> 4. The Python developers have committed to maintaining backwards
> compatibility in the standard library for a very long time. Even if they
> included wxPython into the standard library, they would have to provide
> a Tkinter module that works like the current one. I do not believe it is
> feasible to write a Tkinter workalike that uses wxPython, so we would
> still be relying on Tcl/Tk.

Yes, very well put.

Another point is non-gui baggage. In my opinion, and I suspect others, 
this should be minimal to absent.

Tk itself is purely a gui package -- abstract widgits, geometry placers 
to make them visible, and an event system to make them active. But it 
does have the baggage of needing tcl included. About a decade ago, some 
people had the idea of removing the tcl dependency, but nothing seems to 
have come of that. For some people, the tcl baggage is reason enough to 
be rid of tk.

Qt, in contrast to tk, is not a gui package, but an application 
framework and library that includes QtGui as one of about 10 modules. 
There is also, for instance QtSockets and QtScript (now included in 
QtCore). Qt as a whole could not go into the stdlib.

 From what I remember when I looked at the WxWidgets feature list some 
years ago, WxWidgets does not come with a scripting language, but also 
has more that strictly gui stuff. So I think it would also need to be 
subsetted.

PyGui seems to be purely a gui package, but it appear to be aimed only 
at 2.x with no interest in 3.x.

> There is certainly enough maintenance force to keep wxPython updated and
> ported to Python 3, but only *outside* of the standard library.

I got the opposite impression from the link above. As of last May, 3.x 
support is deferred until a new C++ code generator is written, and that 
is deferred until new features are added and released. So it seems the 
project needs another person to either code the new code generator or 
learn how to port Capi code (or both). Since there is no 2to3 for Capi 
(as opposed to Python code), I do not even know is a single code base is 
possible. I am sure that whoever works on a wxPython port could learn 
from whoever did the numpy port.

-- 
Terry Jan Reedy

 >Stephen "Strawman" Hansen: If he only had a brain!
And you want -us- to take -you- seriously? Tell me, what did you 
accomplish with that insult? Beyond elevating your own ego and trolling 
some more, anyway.
On 1/26/2011 1:37 PM, rantingrick wrote:
> On Jan 26, 2:07 pm, Stephen Hansen<me+list/pyt...@ixokai.io>  wrote:
>
>> And some people have absolutely no need-- no need at all-- for any sort
>> of GUI programming at all. This group is actually really, really big.
> Stephen "Strawman" Hansen: If he only had a brain! :-)
>
> That is the most obvious straw-man to date in this thread. What about
> the large portion of folks who don't use all the datatypes (queue,
> weakref, etc) or how about numeric and math modules (fractions,
> decimal, etc) or how about data persistence, or Cryptograhic, or
> curses! or, multimedia services, or, or.
>
> You see NOT everyone uses everything in the stdlib and most use much
> less than half. However we would be fools to claim "batteries
> included" and NOT support GUI!


-- 

Thanks,
Ty

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig3494827F480C56341E2F7404
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 1/26/11 12:37 PM, rantingrick wrote:
> On Jan 26, 2:07 pm, Stephen Hansen <me+list/pyt...@ixokai.io> wrote:
>=20
>> And some people have absolutely no need-- no need at all-- for any sor=
t
>> of GUI programming at all. This group is actually really, really big.
>=20
> Stephen "Strawman" Hansen: If he only had a brain! :-)
>=20
> That is the most obvious straw-man to date in this thread. What about
> the large portion of folks who don't use all the datatypes (queue,
> weakref, etc) or how about numeric and math modules (fractions,
> decimal, etc) or how about data persistence, or Cryptograhic, or
> curses! or, multimedia services, or, or.
>=20
> You see NOT everyone uses everything in the stdlib and most use much
> less than half. However we would be fools to claim "batteries
> included" and NOT support GUI!

As usual, you selectively quote and completely miss the point.

Hint: the quoted portion was not an argument for or against inclusion of
anything.

The funny thing is, by selectively quoting the phrase and using it to
imply that I was making a straw-man argument against inclusion with that
statement -- which, point of fact, I was not -- you are yourself, making
a straw-man argument.

http://en.wikipedia.org/wiki/Straw_man
"To "attack a straw man" is to create the illusion of having refuted a
proposition by substituting it with a superficially similar yet
unequivalent proposition (the "straw man"), and refuting it, without
ever having actually refuted the original position."

I can't decide if you're just ignorant or if you're an artful troll with
a sense of irony and did it on purpose.

--=20

   Stephen Hansen
   ... Also: Ixokai
   ... Mail: me+list/python (AT) ixokai (DOT) io
   ... Blog: http://meh.ixokai.io/


--------------enig3494827F480C56341E2F7404
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (Darwin)

iQEcBAEBAgAGBQJNQK3MAAoJEKcbwptVWx/l2eYIAKy+8eegExLAwICWuJRs4LZJ
ZSj4KestcA9g50l6PJtPzopH8oZYwcCUQTAqIjNZoxVnjrBche8ghyYYEt0GloZO
NpnpE1u+Y0mTgG4+qq0qCx0vlFqB0lf8ehJEXhaWoqx8iiXYBWu7cML2MDiCM5B+
Fo20iS6lFwPFQ2e817z/KIs2ysZuO0mVRCgictmfnjE1HgPqRUJ/ow+XN9JzLHkr
VarHl6dkXPRgcarve3R8Ch0vWntJH78Rc3VlXmw6tWZEyiJvhx8grXX5wyIWQR9k
QlbGmrpUBwadIq9wXxlkIXhzdRh5qE0IQ46EgYjmMiInIO8vJurexjb+lWQ+CCg=
=LsH7
-----END PGP SIGNATURE-----

--------------enig3494827F480C56341E2F7404--

On Jan 26, 4:57=A0pm, Terry Reedy <tjre...@udel.edu> wrote:

> PyGui seems to be purely a gui package, but it appear to be aimed only
> at 2.x with no interest in 3.x.

I really like pyGUI. We would have to do a ton of work to get it even
to the scale of Tkinter. In hindsight the project seems like something
Python should have considered from the beginning. Had we have started
with something like pyGUI 20 years ago, i'd bet we would be better off
today since we could control the development internally.

PROS:

 * small
 * cross platform??
 * pythonic
 * under our control
 * unlimited possibilities

CONS:

 * not feature rich
 * huge amount of work needed

Although pyGUI would probably never measure up to wxPython. I still
have a special place in my heart for such an ambitious and visionary
undertaking. You can read the goals at Greg's site. Every time i do i
get a tear in my eye thinking of the possibilities.

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

On 1/26/11 4:57 PM, Terry Reedy wrote:

>  From what I remember when I looked at the WxWidgets feature list some years
> ago, WxWidgets does not come with a scripting language, but also has more that
> strictly gui stuff. So I think it would also need to be subsetted.

For what it's worth, wxPython tries not to wrap parts of wxWidgets that can be 
replicated by the standard library. I do believe they wrap some non-GUI parts of 
wxWidgets that are needed to work with certain GUI widgets, but don't quote me 
on that.

> On 1/26/2011 11:35 AM, Robert Kern wrote:
>> There is certainly enough maintenance force to keep wxPython updated and
>> ported to Python 3, but only *outside* of the standard library.
>
> I got the opposite impression from the link above. As of last May, 3.x support
> is deferred until a new C++ code generator is written, and that is deferred
> until new features are added and released. So it seems the project needs another
> person to either code the new code generator or learn how to port Capi code (or
> both). Since there is no 2to3 for Capi (as opposed to Python code), I do not
> even know is a single code base is possible. I am sure that whoever works on a
> wxPython port could learn from whoever did the numpy port.

In loose terms, what we learned from the experience was that it actually isn't 
so bad once you knuckle down to it. But yes, it does look like some more 
volunteer effort would be needed to get Python 3 support soon. I note that I did 
not specify any particular deadline. :-) I just wanted to disabuse Octavian of 
the idea that we are claiming that the wxPython team is inadequate in general.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco

On 1/26/2011 3:07 PM, Stephen Hansen wrote:

> And, more then a few actually
> are pushing for the stdlib to be forked off of CPython, and instead end
> up shared by all the major Python implementations (CPython, Jython,
> PyPy, IronPython, what else?) as a common resource?

This would be a 'split', not a 'fork' (important difference).

There are really two ideas here.

1. As many modules as possible would have a pure Python reference 
implementation. Any implementation could use that until it choose to 
replace or supplement with a native-language implementation.

For instance, itertools in coded in C for speed, but the docs give 
Python (near) equivalents for clarity. A common Python stdlib would have 
a Python-coded itertools. CPython would actually run the C-coded 
equivalent renamed _itertools.

Maintaining both versions in parallel would be more work, so this could 
only happen if other implementors chipped in to help.

Stephen, you are the first I know of to ask whether such a project would 
affect addition of new modules. Hard to say.


2. Separate tests that test compliance with the Python specs (for both 
language and stdlib) from tests that test implementation-specific 
behaviors. The current CPython test suite mixes both together. If 
separated, other implementations could (and would) use the Python tests, 
and their people would be more willing to help improve the Python tests. 
Many stdlib modules are not at 100% coverage and need expansion.

For instance, "1+1 == 2" tests Python behavior, while "a,b=1,1; 
id(a)==id(b)" tests a CPython implementation detail. Last I knew, both 
types of tests are in the same test file.

Reference count tests, for example, are also CPython-specific.


Both of these ideas will be looked at after the hg migration.

-- 
Terry Jan Reedy

On Jan 26, 5:25=A0am, rantingrick <rantingr...@gmail.com> wrote:
> A vision that
> is representative of ALL the people -- and not a few fat cats at the
> top.

[...]

> This is the only way we can truly
> understand what our community members are thinking about Tkinter.
> Anything else is purely speculation.

[...]

> Many folks out there share our views that Tkinter is a weight around
> Python's neck, however they are too fearful to speak out for fear of
> excommunication (the kill file!).

So even though the majority of opinions are counter to yours, those
people are the arrogant 'fat cats' who aren't listening to 'the
people'? You criticise others for making generalised statements about
the desires of other coders, but you believe that you speak for a
silent majority, whose presence is somehow known and sensed by you
through some magical force?

Can we all just accept that rr/rantingrick is a troll and let these
thread die? This is, what, the 3rd? 4th? year of his endless tirade
against TKinter. Most people with an actual problem WOULD HAVE
RELEASED CODE BY NOW.

rantingrick <rantingr...@gmail.com> wrote:
> Not if we used the underlying MS library! Windows has such a rich
> library why not use it? Why must we constantly re-invent the wheel?

Isn't restricting a GUI toolkit to just one of the major OSes the
absolute opposite of 'accessible'?

Infinity77 <andrea.gav...@gmail.com> wrote:
> It is very unfortunate that this topic "wxPython vs. Tkinter" has
> drifted to another flame war, as there is really no point in this kind
> of discussion.

I don't think it's wxPython that's causing the flames in this
thread :)

On Jan 26, 8:59=A0pm, alex23 <wuwe...@gmail.com> wrote:

> This is, what, the 3rd? 4th? year of his endless tirade
> against TKinter.

Alex, i have not been against Tkinter for 4 years. I just recently
realized (about a year ago) the limitations of Tkinter and started
thinking of alternatives.

Tip of the day: Before misrepresenting someone's position and
overshooting an estimate by three years, first make sure you've
actually read most of what they have written.

HTH

On Jan 26, 9:11=A0pm, alex23 <wuwe...@gmail.com> wrote:
> rantingrick <rantingr...@gmail.com> wrote:
> > Not if we used the underlying MS library! Windows has such a rich
> > library why not use it? Why must we constantly re-invent the wheel?
>
> Isn't restricting a GUI toolkit to just one of the major OSes the
> absolute opposite of 'accessible'?

You'll need to read that snippet in context to understand what i was
talking about. Again, see my "tip of the day" in my last post to you.

From: "Robert Kern" <robert.kern@gmail.com>
> in? Robin Dunn is the wxPython project lead.


Ok, in this case I understand why WxPython can't be included in stdlib.
I think there was a communication problem because the oldest list members 
start with the idea that all the list members know who is who and they may 
be thinking that I don't want to accept the reality or that I have bad 
feelings about some list members or something like that.

> There is a large difference between the being "promoted by Python" and 
> being "included in Python's standard library. The latter is the issue at 
> hand, not the former. wxPython is already "promoted" by Python's 
> documentation:

If there is a bigger chance that a beginner start using Tkinter without 
knowing its issues, this means that Python promotes the wrong tool.
As I said, the main issue is not that Python doesn't promote WxPython. I 
have even suggested that Python might not include any GUI if this would be 
prefered, but what's wrong is that Python promotes a GUI which is not 
accessible by including it as a default GUI.

As we all know, Python doesn't care too much about maintaining a backward 
compatibility and there are much many other things which are not compatible 
between different Python versions, but some Python programmers consider this 
a virtue because they say that what was wrong was eliminated. If they are 
right, then why wouldn't be a good idea to also remove a wrong GUI lib? Just 
because the majority prefers it?


Octavian

On 1/26/2011 11:02 PM Octavian Rasnita said...

> As we all know, Python doesn't care too much about maintaining a
> backward compatibility

Where'd you get this idea?  Between v2 and v3 yes, that was the intent. 
  But otherwise, I think there's another miscommunication behind this...

See http://www.python.org/dev/peps/pep-0291/

Emile

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigA6B8AD0471E8571F6EF08928
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 1/26/11 11:02 PM, Octavian Rasnita wrote:
> As we all know, Python doesn't care too much about maintaining a
> backward compatibility

What? Nonsense.

There are strict compatibility requirements.

There was a one-time break with these; 2.x->3.x -- but that's it. It may
never happen again. If another happens, its years down the road. If ever.=



--=20

   Stephen Hansen
   ... Also: Ixokai
   ... Mail: me+list/python (AT) ixokai (DOT) io
   ... Blog: http://meh.ixokai.io/


--------------enigA6B8AD0471E8571F6EF08928
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (Darwin)

iQEcBAEBAgAGBQJNQaRzAAoJEKcbwptVWx/lSTAIAKoIG77aeUSKkP5sYOkZB+8t
mmkiqW5ssZOik61ZQBnaBid2mRbGuWsLR4U6xa4uPxdZ3CJG1nKyPfYKb3Odgqm9
EHp3drieZYH+/9zgqT7TMfLe21Z2RKKSBacpSPviYkr7yRQQU1fwwohqLRHutzi+
ylrfnMiW72X0ouxZZi79RpgmKIVHmHkplhOAQPhCXJpocgXPTKc8778bdCJYanoD
d8ccwP+Omosdb2aLMKNiNLIZ+2XYu31x2Mm1WimxEllYvKj6uAxsrUUeF5auH6It
EkoHuM8abHRQe/qxwoPJAd3Qy/iGW8jjm1DajIU15hCENjYLa+YC45pzflrARSE=
=d+Yf
-----END PGP SIGNATURE-----

--------------enigA6B8AD0471E8571F6EF08928--

 Terry Reedy <tjreedy@udel.edu> wrote:
> Tk itself is purely a gui package -- abstract widgits, geometry placers 
> to make them visible, and an event system to make them active. But it 
> does have the baggage of needing tcl included. About a decade ago, some 
> people had the idea of removing the tcl dependency, but nothing seems to 
> have come of that. For some people, the tcl baggage is reason enough to 
> be rid of tk.


Thanks for raising this point.  While I don't want to exhaustively 
respond to this, I would like to raise a few important points.

1. The performance issues of having Tk use Tcl are negligible; the bulk 
of Tk (code-wise and time-wise) are spent in C.  Tcl itself is also very 
fast nowadays, using all the usual techniques that modern dynamic 
languages use.

2. Some people do have moral/purity objections to including Tcl, and 
while I understand where the sentiment comes from, I think there are few 
solid engineering reasons for this.

3. Removing Tcl from Tk makes keeping up with changes in Tk very 
difficult.  The Perl people found this out; Perl/Tk extracted Tcl, and 
as a result remained using a 10 year old version of Tk because upgrading 
would have been too painful.  The newer Perl binding (Tkx) is in fact a 
ridiculously thin binding over the Tcl API, and makes keeping up to date 
with the newest Tk changes trivial, often requiring no code changes in 
the Perl binding. 

If anyone does have questions, comments or concerns about Python 
including a Tcl interpreter to use Tk, I'd be happy to try to explain or 
address them.

Mark

From: "Emile van Sebille" <emile@fenx.com>
> On 1/26/2011 11:02 PM Octavian Rasnita said...
>=20
>> As we all know, Python doesn't care too much about maintaining a
>> backward compatibility
>=20
> Where'd you get this idea?  Between v2 and v3 yes, that was the =
intent.=20

To be sincere I was thinking to the differences between Python 2 and 3.

>  But otherwise, I think there's another miscommunication behind =
this...

It might be true, however I have seen some modules that say that are =
ment for Python 2.5, for 2.6 or for 2.7, so there seem to be differences =
between these versions also.

py2exe offers the following installation kits, depending on the Python =
version. If you know, please tell me why there are different packages =
for different versions of Python?

py2exe-0.6.9.win32-py2.5.exe=20
py2exe-0.6.9.win32-py2.4.exe=20
py2exe-0.6.9.win32-py2.3.exe=20
py2exe-0.6.9.win32-py2.6.exe=20
py2exe-0.6.9.win32-py2.7.exe=20

Thanks.

Octavian

On 1/27/2011 10:09 AM Octavian Rasnita said...
> From: "Emile van Sebille"<emile@fenx.com>
>> On 1/26/2011 11:02 PM Octavian Rasnita said...
>>
>>> As we all know, Python doesn't care too much about maintaining a
>>> backward compatibility
>>
>> Where'd you get this idea?  Between v2 and v3 yes, that was the intent.
>
> To be sincere I was thinking to the differences between Python 2 and 3.
>
>>   But otherwise, I think there's another miscommunication behind this...
>
> It might be true, however I have seen some modules that say that are ment for Python 2.5, for 2.6 or for 2.7, so there seem to be differences between these versions also.

Yes - but don't confuse forward compatibility (which means programs you 
write today in the current version will work on the prior versions) with 
backward compatibility (which means programs written for earlier 
versions will run under newer versions)

I suspect that a lot of python 1.x code will work just fine under 2.x 
just as most 2.n will work under 2.m (where m>n).  There are few 
exceptions, and those mostly in the standard library.  I recall only 
getting stung once (something to do with passing in a tuple instead of 
two parameters in one or another imported module).

Emile

> It might be true, however I have seen some modules that say that are ment=
 for Python 2.5, for 2.6 or for 2.7, so there seem to be differences betwee=
n these versions also.

Python cares *a lot* about maintaining backward compatibiilty between
all major versions.
This is so true that I managed to use a unique code base for pyftpdlib
which supports python from 2.3 to 2.7.
Same for psutil which covers versions from 2.4 to 3.2 by using a
unique code base!

> It might be true, however I have seen some modules that say that are ment=
 for Python 2.5, for 2.6 or for 2.7, so there seem to be differences betwee=
n these versions also.

Usually the differences between one version and another rely on *new
features* only.
One might decide to target a module only for a certain version of the
2.x serie because that certain version introduced a new functionnality
which was not available before (silly example
http://docs.python.org/library/os.html#os.initgroups ).
All the other functionnalities are likely to remain the same and fully
backward compatible.

> py2exe offers the following installation kits, depending on the Python ve=
rsion. If you know, please tell me why there are different packages for dif=
ferent versions of Python?
>
> py2exe-0.6.9.win32-py2.5.exe
> py2exe-0.6.9.win32-py2.4.exe
> py2exe-0.6.9.win32-py2.3.exe
> py2exe-0.6.9.win32-py2.6.exe
> py2exe-0.6.9.win32-py2.7.exe

That's a different story: those are pre-compiled binaries which are
generated from a *unique* source code which support all those
versions.
If you have a compiler you can install pywin32 extension by using any
Python version.


--- Giampaolo
http://code.google.com/p/pyftpdlib/
http://code.google.com/p/psutil/



2011/1/27 Octavian Rasnita <orasnita@gmail.com>:
> From: "Emile van Sebille" <emile@fenx.com>
>> On 1/26/2011 11:02 PM Octavian Rasnita said...
>>
>>> As we all know, Python doesn't care too much about maintaining a
>>> backward compatibility
>>
>> Where'd you get this idea? =A0Between v2 and v3 yes, that was the intent=
..
>
> To be sincere I was thinking to the differences between Python 2 and 3.
>
>> =A0But otherwise, I think there's another miscommunication behind this..=
..
>
> It might be true, however I have seen some modules that say that are ment=
 for Python 2.5, for 2.6 or for 2.7, so there seem to be differences betwee=
n these versions also.
>
> py2exe offers the following installation kits, depending on the Python ve=
rsion. If you know, please tell me why there are different packages for dif=
ferent versions of Python?
>
> py2exe-0.6.9.win32-py2.5.exe
> py2exe-0.6.9.win32-py2.4.exe
> py2exe-0.6.9.win32-py2.3.exe
> py2exe-0.6.9.win32-py2.6.exe
> py2exe-0.6.9.win32-py2.7.exe
>
> Thanks.
>
> Octavian
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>

On 1/27/2011 12:31 PM, Mark Roseman wrote:
>   Terry Reedy<tjreedy@udel.edu>  wrote:
>> Tk itself is purely a gui package -- abstract widgits, geometry placers
>> to make them visible, and an event system to make them active. But it
>> does have the baggage of needing tcl included. About a decade ago, some
>> people had the idea of removing the tcl dependency, but nothing seems to
>> have come of that. For some people, the tcl baggage is reason enough to
>> be rid of tk.
>
>
> Thanks for raising this point.  While I don't want to exhaustively
> respond to this, I would like to raise a few important points.
>
> 1. The performance issues of having Tk use Tcl are negligible; the bulk
> of Tk (code-wise and time-wise) are spent in C.  Tcl itself is also very
> fast nowadays, using all the usual techniques that modern dynamic
> languages use.

I have the impression that tcl is mostly used in initial setup and 
configuration, as opposed to repetitive drawing to the screen. But I do 
not really know.
>
> 2. Some people do have moral/purity objections to including Tcl, and
> while I understand where the sentiment comes from, I think there are few
> solid engineering reasons for this.

There are two types of objections which have much less force now than a 
decade ago. One is the size issue. A tcl-less tk would presumably be 
smaller and thus add less to the Window distribution. The other is that 
tcl and Python were once seen as competing scripting languages, so why 
promote the competitor? Well, if there really was a contest, Python won.

> 3. Removing Tcl from Tk makes keeping up with changes in Tk very
> difficult.  The Perl people found this out; Perl/Tk extracted Tcl, and
> as a result remained using a 10 year old version of Tk because upgrading
> would have been too painful.  The newer Perl binding (Tkx) is in fact a
> ridiculously thin binding over the Tcl API, and makes keeping up to date
> with the newest Tk changes trivial, often requiring no code changes in
> the Perl binding.

Good point. Python should (continue to) just use the latest tk from its 
maintainers. If *they* were to decouple it from tcl (unlikely, it 
seems), fine. If not, so be it ;-).

> If anyone does have questions, comments or concerns about Python
> including a Tcl interpreter to use Tk, I'd be happy to try to explain or
> address them.

Thanks for the additional info. We need more of that.

---
Terry Jan Reedy

 Terry Reedy <tjreedy@udel.edu> wrote:
> > 1. The performance issues of having Tk use Tcl are negligible; the bulk
> > of Tk (code-wise and time-wise) are spent in C.  Tcl itself is also very
> > fast nowadays, using all the usual techniques that modern dynamic
> > languages use.
> 
> I have the impression that tcl is mostly used in initial setup and 
> configuration, as opposed to repetitive drawing to the screen. But I do 
> not really know.


Tcl as a scripting language is used during some initialization things, 
used to invoke callbacks, and a few other non-performance critical areas.

It sometimes helps to think of Tcl as a very powerful C library that 
happens to have a scripting language on top. :-)  For example, there are 
C functions in the Tcl library that do things like string management, 
cross platform I/O, very efficient hash tables, dynamic lists, etc. that 
are used everywhere inside Tk.  But none of those calls mean a trip 
through the Tcl interpreter per se.

Every dynamic language would have similar internals of course, though 
with slight differences and different API's. 

Mark

rantingrick <rantingr...@gmail.com> wrote:
> You'll need to read that snippet in context to understand what i was
> talking about. Again, see my "tip of the day" in my last post to you.

Pass. I'd have to see value in what you say inside of the endless
masturbatory self-aggrandizement that you pass off as "visionary"
posts. Instead it's all blah blah blah RUBY ASSHOLES blah blah
INCOHERENT IDEA blah LAZY BASTARDS WHO DON'T APPRECIATE ME etc etc

On 01/27/2011 09:53 PM, alex23 wrote:
> rantingrick <rantingr...@gmail.com> wrote:
>> You'll need to read that snippet in context to understand what i was
>> talking about. Again, see my "tip of the day" in my last post to you.
> 
> Pass. I'd have to see value in what you say inside of the endless
> masturbatory self-aggrandizement that you pass off as "visionary"
> posts. Instead it's all blah blah blah RUBY ASSHOLES blah blah
> INCOHERENT IDEA blah LAZY BASTARDS WHO DON'T APPRECIATE ME etc etc

Because insults and flaming totally get anyone anywhere.
If you don't have anything civil to say, don't say it at all (Because
sometimes un-nice things need to be said).

"Octavian Rasnita" <orasn...@gmail.com> wrote:
> Ok, in this case I understand why WxPython can't be included in stdlib.
> I think there was a communication problem because the oldest list members
> start with the idea that all the list members know who is who and they may
> be thinking that I don't want to accept the reality or that I have bad
> feelings about some list members or something like that.

The only expectation I as a list member have of you is that you maybe
hit the web and do a bit of search & research before starting on an
endless tirade. Implying that it was the responsibility of everyone
here to explain every little aspect of an issue you're supposedly
passionate about makes you seem either lazy or ignorant.

From: "Giampaolo Rodol�" <g.rodola@gmail.com>
....
> py2exe offers the following installation kits, depending on the Python
> version. If you know, please tell me why there are different packages for
> different versions of Python?
>
> py2exe-0.6.9.win32-py2.5.exe
> py2exe-0.6.9.win32-py2.4.exe
> py2exe-0.6.9.win32-py2.3.exe
> py2exe-0.6.9.win32-py2.6.exe
> py2exe-0.6.9.win32-py2.7.exe

That's a different story: those are pre-compiled binaries which are
generated from a *unique* source code which support all those
versions.
If you have a compiler you can install pywin32 extension by using any
Python version.


Thank you Giampaolo. Now I understand and it is a good thing.

Octavian

From: "alex23" <wuwei23@gmail.com>
> "Octavian Rasnita" <orasn...@gmail.com> wrote:
>> Ok, in this case I understand why WxPython can't be included in stdlib.
>> I think there was a communication problem because the oldest list members
>> start with the idea that all the list members know who is who and they
>> may
>> be thinking that I don't want to accept the reality or that I have bad
>> feelings about some list members or something like that.
>
> The only expectation I as a list member have of you is that you maybe
> hit the web and do a bit of search & research before starting on an
> endless tirade. Implying that it was the responsibility of everyone
> here to explain every little aspect of an issue you're supposedly
> passionate about makes you seem either lazy or ignorant.


Hi Alex,

You are right, I was lazy and didn't searched on the net to find who are all
the list members that answered to my posts for understanding better their
position, so it's my fault.

Octavian

On 1/25/11 12:04 AM, Steven D'Aprano wrote:
> On Mon, 24 Jan 2011 12:24:24 -0800, Robin Dunn wrote:
>
>> On Jan 24, 12:03 pm, rantingrick<rantingr...@gmail.com>  wrote:
>>> On Jan 24, 1:57 pm, Robin Dunn<ro...@alldunn.com>  wrote:
>>>> BTW, on behalf of the wxPython community I'd like to apologize for
>>>> the havoc caused by the flaming troll escaping from his cage.  In
>>>> general wxPython users are much less militant and zealotty and honor
>>>> everyone's freedom to choose which ever UI tool kit works the best
>>>> for their own needs.
>>> Well we forgive Byran, but we will not forget! :)
>> For the record, that is not who I was referring to.
> I don't believe that anyone in their right mind could have imagined even
> for a second that you were referring to Bryan.
As we all experienced milleniums before:
Self-criticism is the weakest, maybe totally missing
virtue of a bozo.
Which is great, because he won't recognize the irony ;-)

-- 
Christian Tismer             :^)<mailto:tismer@stackless.com>
tismerysoft GmbH             :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key ->  http://wwwkeys.pgp.net/
work +49 30 802 86 56  mobile +49 173 24 18 776  fax +49 30 80 90 57 05
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
       whom do you want to sponsor today?   http://www.stackless.com/

On 23 Jan, 01:07, rantingrick <rantingr...@gmail.com> wrote:

> It is time to prove once and for all how dated and worthless Tkinter
> is compared to wxPython. Yes, WxPython is not as advanced as i would
> like it to be for a 21st century GUI library.

So use PyQt instead.

> However compared to
> Tkinter, Wx is light years ahead! Wx is our best hope to move Python
> into the 21st century.

I vaguely someone saying that about Borland VCL and C++. Now people
harly remember there was a RAD product called Borland C++ Builder,
with a sane GUI API compared to Microsoft's MFC.

I for one do not like to handcode GUIs. That is why I use
wxFormBuilder, and the availability of a good GUI builder dictates my
choise of API (currently wxPython due to the previously mentioned
product).

Sturla

rantingrick wrote:
> All we have to do is create an abstraction API that
> calls wxPython until we can create OUR OWN wxPython from WxWidgets.

There seems to be at least one other project around
like that:

http://dabodev.com/

-- 
Greg

Terry Reedy wrote:

> PyGui seems to be purely a gui package, but it appear to be aimed only 
> at 2.x with no interest in 3.x.

I'm working on 3.x conversion right now and should have
something ready soon.

-- 
Greg