On Aug 27, 11:22 pm, r <rt8...@gmail.com> wrote: > --------------------------------------------- > Python offical docs and Tkinter > --------------------------------------------- > *The Python docs barely cover anything related to actual Tkinter > coding. At the minimum the Tkinter doc page should have a subpage for > all the widgets available --which is very small(approx 15) and each > subpage should list the available methods on that wiget.
I think the general idea behind the 'lack' of documentation is that it would only double tcl/tk's own documentation. I've always used Tkinter using the tcl/tk docs here: http://www.tcl.tk/man/tcl8.5/TkCmd/contents.htm and once you get used to how you transform tcl syntax to Python syntax, it works pretty well. Maintaining a documentation for Tkinter in the official Python docs would force people to run after tcl. I understand why they don't want to do that, even if I'd love to see a better Tkinter documentation too. > --------------------------------------------- > from Tkinter import * > --------------------------------------------- > *Too many noobs start out with the "from Tkinter import *" idiom, > unknowing that they are horribly polluting their namespace. I feel > that all (tkinter) code should follow the "import Tkinter as tk" > policy and never use "from Tkinter import *". To push this agenda i > propose all docs be modified so that no one should see such global > import blasphemy again. We should at least keep all example code in > the latter non-polluting form and frown heavily upon global imports in > Tkinter code or any code for that matter. Well, I just don't agree with you on this one. AFAIK, Tkinter has been made to make the 'from Tkinter import *' idiom work without too much namespace pollution. I've always used it, still use it today, and never seen any problem with it. I do agree that this might lead newbies to think it's ok for all modules, and end up doing 'from os import *' and wonder why opening a file with 'open' no more works. But this is the only problem I can see. > --------------------------------------------- > Tkinter Constants > --------------------------------------------- > *The Tkconstants module needs to be removed *yesterday* because i > think it reinforces sloppy coding styles. The main problem is with > subtle bugs that are created when someone rebinds one or more of the > constants, for example "W=20". At first i thought the constants were > great but I quickly found out the shortfalls of such a Utopian > approach . Since Tkinter allows strings to be passed-into widget > constructors, we should remove the TkConstants immediately and force > everyone to use strings instead... > > #-- instead of this --# > w.pack(side=LEFT,fill=BOTH,anchor=W) > > #-- do this --# > w.pack(side='left',fill='both',anchor='w') > > The few extra keystrokes are well worth the effort! Well, again, I don't agree. I prefer having well defined constants than having to type strings. If the values for the fill option could be anything, well, OK. But they can't: they have to be either 'x' or 'y' or 'both'. So I prefer to have them defined in constants. [snip comments on IDLE, which I don't use] > --------------------------------------------- > Tkinter Canvas > --------------------------------------------- > *The Tkinter Canvas widget should return (X,Y) pairs when calling > canvas.coords(obj). The current implementation returns a flat array > that is pretty much useless outside of canvas calls. Of course one > could zip the coords into pairs, but it seems clumsy to call zip() on > 2 LC's when Tkinter could, and should, do it for you. We agree on this one, but it's a minor flaw. > *Canvas needs a canvas.rotate() method for polygons, lines -- (easy). All Canvas methods are actually forwarded to the underlying tcl interpreter. So you might want to suggest that to the tcl guys. > --------------------------------------------- > Tkinter ComboBox -- where's Waldo? > --------------------------------------------- > *As much as i hate to support anything related to M$, Tkinter needs an > M$ stlye combobox. Yes, I know Tix has combobox (*puke*), however > using it is like pulling teeth. I have coded up an far more elegant/ > simple solution -- and yes, i know about the OptionMenu widget which > serves a useful purpose but is NOT a good replacement for a REAL M$ > style combobox ;). You don't seem to be aware of the new widgets in tk, which do include a combo-box (and a lot of others BTW). See the ttk:: commands in the tcl/tk documentation (link above). These widgets already have a Python wrapper (see http://pypi.python.org/pypi/pyttk/0.3). > *For instance, ComboBoxes need values that the user can select from, > this is as universal as humans and oxygen. But sometimes you want to > give the user a detailed set of values in the dropdown listbox and > then insert an abbrieation of the value once selected, such as the > case with state names... > > New Mexico -> MN > California -> CA > Florida -> FL > > ...instead of the laborious and wasteful convention of overriding a > method to insert this value from a mapping each time why not just pass > a pointer to the mapping into the constructor and create a combobox > that actually knows how to walk and chew gum! Again, you might want to forward that to the tcl guys. And I do agree it would be nice. [snip code] [snip Tix comments...] Tix is more or less dead, since nearly all the widgets it provided have now way better alternatives which have been included in the tcl/ tk core in the ttk package, including comboboxes and notebooks. You might want to have a look at these. -- http://mail.python.org/mailman/listinfo/python-list
