Re: [Code Challenge] WxPython versus Tkinter.
Terry Reedy
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
Octavian Rasnita
>
> 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 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
Stefan Behnel
> 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
> 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
rusi
> WxPython versus Tkinter (A code battle to the death!)
>
> by Rick Johnson.
>
> --and has been for a decade-- the wrong choice for Python's stdlib
> 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!
>
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 :-) ]
Steven D'Aprano
>> 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
Adam Skutt
> 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.
Arndt Roger Schneider
[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
Steven D'Aprano
> So far only trolls (besides Terry, Octavian, D'Aprano) have replied.
So apart from the non-trolls, only trolls have replied?
--
Steven
Corey Richardson
>
> 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 :)
Steven D'Aprano
> 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
Adam Skutt
> 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.
Adam Skutt
> 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).
> 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".
> 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. 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.
Littlefield, Tyler
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
Adam Skutt
> 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
Nicholas Devenish
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
David Boddie
> 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
Corey Richardson
> On Jan 23, 3:11 pm, "Littlefield, Tyler"<ty...@tysdomain.com> wrote:
>
>> if you can't manage to provide cross-platform bug-free code.
>
> 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
Steven D'Aprano
> 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
Kevin Walzer
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
Martin v. Loewis
>>
>> [Actually this is the first time in my 10 years of python that Ive
>> seen a pure python module segfault :-) ]
>
> 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
Martin v. Loewis
> 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
Martin v. Loewis
>
> * 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
Corey Richardson
> 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
Kevin Walzer
> 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
Steven D'Aprano
Brilliant! Pity that it is so ugly under Linux :(
--
Steven
Corey Richardson
> 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
Corey Richardson
> 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
>
> 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.
Corey Richardson
> 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.
Kevin Walzer
> 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.
Corey Richardson
> On Jan 23, 8:07 pm, Corey Richardson<kb1...@aim.com> wrote:
>
>> because imageIdx is just a dictionary,
>
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'?
Steven D'Aprano
> 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
Corey Richardson
> On Jan 22, 6:07 pm, rantingrick<rantingr...@gmail.com> wrote:
>
>> I await any challengers...
>
>
> * 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
Littlefield, Tyler
>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.
> 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
rusi
> >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.
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...
Octavian Rasnita
>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
Octavian Rasnita
> >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
Octavian Rasnita
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
Noah Hall
> 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".
Octavian Rasnita
> 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
Littlefield, Tyler
It's clear that the mighty text editor he's wielding in his arena of
champions while taking on the world all by himself does not come with a
debugger, or even the ability to run the code. Might I suggest throwing
your current weapon of mass destruction away and finding another? It's
clearly lacking in some key features.
--
Thanks,
Ty
Martin v. Loewis
> 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
Bryan
> On Jan 22, 6:07 pm, rantingrick <rantingr...@gmail.com> wrote:
>
> > I await any challengers...
>
> 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.
>
> 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.
Bryan
+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 # whichever
> path = gui_toolkit.select_file()
>
You mean like:
>>> import tkFileDialog
>>> path=tkFileDialog.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.
Bryan
> On Jan 23, 5:23 pm, 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), it presents a
> > decent, simple file browser:
>
>
> 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?
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.
Bryan
> On Jan 23, 7:16 pm, 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...
>
> > > ---------------------------------------
> > > Challenge 1: (Simple Directory Viewer)
> > > ---------------------------------------
> > > Create a simple Directory Viewer GUI. You CANNOT use a treectrl!
>
> > > Any questions?
>
>
> > 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
>
> > 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.
"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 :-)
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, 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).
Octavian Rasnita
> 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
Peter Otten
> 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 ;)
Giampaolo Rodolà
> On Jan 24, 2:56 am, "Martin v. Loewis" <mar...@v.loewis.de> wrote:
>
>> Well Rick, this doesn't make look wxPython any better.
>
> 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. =)
--- Giampaolo Rodolà
http://code.google.com/p/pyftpdlib/
http://code.google.com/p/psutil/
Kevin Walzer
>
> 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
Kevin Walzer
>
> 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
Littlefield, Tyler
majority of >users that need to use a screen reader?
not going to sit here and say the same thing over and over as you are
doing. Get off the soapbox already.
--
Thanks,
Ty
Mike Driscoll
> On Jan 24, 12:06 am, rusi <rustompm...@gmail.com> wrote:
>
> > On Jan 24, 9:16 am, "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
Grant Edwards
> 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!!
Grant Edwards
> 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
Mike Driscoll
> On Jan 24, 8:49 am, Mike Driscoll <kyoso...@gmail.com> wrote:
>
> > On Jan 24, 7:24 am, 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.
>
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.
Ethan Furman
> From: "rantingrick" <ranti...@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~
Octavian Rasnita
> >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.
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
Mark Roseman
> 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
Bryan
> 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
> > 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.
Bryan
> On Jan 24, 7:24 am, Bryan <bryan.oak...@gmail.com> wrote:
>
>
> > > On Jan 24, 9:16 am, "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.
>
> > 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.
>
> *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.
>
> > 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.
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.
Littlefield, Tyler
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.
Ethan Furman
>
> 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~