An assessment of Tkinter and IDLE

Discussion in 'Python' started by r, Aug 27, 2009.

  1. r

    r Guest

    ---------------------------------------------
    Tkinter and IDLE Shortfalls
    ---------------------------------------------
    *The following is an assessment of Tkinter as i have experienced it.
    Even with all the problems i list below i strongly believe Tkinter is
    a great starter GUI toolkit and we (the Python Community), must keep
    and maintain this module for the foreseeable future.

    *However, as my assessment will reveal, much needs to be done to
    "freshen" up Tkinter and IDLE, and I am not just asking for someone to
    fix these problems. I have already coded solutions for most of them
    however, some of course still need work, and i would like to hear from
    others on this subject too. So buckle your seat belts folks, cause
    here we go...

    ---------------------------------------------
    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. Here are two
    great resources that really like from Fredrik Lundh and John
    Shipman...

    http://www.pythonware.com/library/tkinter/introduction/index.htm
    http://infohost.nmt.edu/tcc/help/pubs/tkinter/

    ....I must say that I prefer the latter written by John Shipman because
    of the way he lists each widgets options in a nice table structure,
    and then lists the methods below. And intersestingly enough, his
    manual only weighs in at about 800kb completely uncommpressed and
    unedited. I'll bet you a wooden nickel i can reduce it to around 500kb
    for the official Python docs *wink*

    *Sadly however neither of these great works is mentioned or linked in
    the official docs Why?.

    *I think a short-and-to-the-point reference, like the afore mentioned
    along with a few links to full featured tuts would be a great addition
    to the Tkinter section of the official docs and i would be happy to
    help make this happen.

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

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

    ---------------------------------------------
    IDLE Shell
    ---------------------------------------------
    *IDLE and Pyshell are great but have major flaws in design. One of my
    biggest complaints is the shell's eight space indention which
    completely bloats your screen! Another annoying fact is that the prompt
    (>>>) is actually inside the text widget. This design is all wrong!
    The prompt should be in another widget to the left of the text so it
    never gets copied or pasted. Or at-least have the copy/paste action
    remove the initial four spaces and the prompt, but i think a full
    separation of "prompt" and "text" are the best solution. The following
    ASCII art won't win me any awards, but it may covey my idea. "W1"
    holds the prompt and "W2" is the actual text editor.

    <W1> <-------- W2 ----------->
    >>> | for x in range(10): |

    ... | print x |
    ... | for y in range(x): |
    ... | print y |
    |1
    |2

    And don't tell me about Geany or Pythonwin or emacs or vim or whatever
    editor happens to float your boat. I know there are tons of great
    editors out there but IDLE is most likely the first one a Pynoob will
    use so it must be usable! IDLE and Tkinter are what make Python a
    stater language -- after the beautiful syntax of course :)

    ---------------------------------------------
    IDLE Editor
    ---------------------------------------------
    *On M$ windows pressing the MMB without a motion causes the selected
    text to be pasted at the insertion cursor, and holding it repeats the
    action very quickly! Since IDLE has no horizontal scroll bar you must
    use MMB to scroll left-right. I am quite happy that there is no
    horizontal scrollbar since using MMB is much quicker, but the text
    pasting action always ruins my day :(. This pasting action is a real
    PITA and a waste of good processor time. I know how to override it
    with a hack in IDLE, but many newcomers won't and will probably get
    frustrated by it so this must be either fixed by hard coding IDLE or
    allowing a user to turn is off in the config options dialog.

    *Something that always gets a Python IDLE noob is "open-bracket-syntax-
    errors" in IDLE. When Python throws this type of error normally the
    only clue you will get from IDLE is to see the last line highlighted.
    However, the missing or misplaced bracket is usually no where near the
    end of the script. IDLE can be easily fixed to show a much closer or
    even exact location of the last open bracket.

    *The Find dialog forgets the regexp string after finding a match, this
    can be a real time waster especially if you typed in a long expression
    and need to tweak it just a bit for a second search! if the "regexp"
    check box is selected the dialog should not replace the contents of
    the Dialog.entry with the texts' selection. (easy fix)

    *The replace dialog seems buggy when doing a "replace+find". Sometimes
    it will highlight the next match but sometimes the highlight will
    immediately disappear so you can't be for sure what you may be
    replacing with the next push of the button? (could be a conflict with
    the colorizer) Real aggravating! This seems to always happen when a
    string is selected.

    *One of my all time pet peeves with all text editors. Everybody repeat
    after me...

    """NO TEXT EDITOR SHOULD EVER COPY AN EMPTY STRING TO THE
    CLIPBOARD!!"""

    ....I can't tell you how many times I've had to re-copy some text
    because i accidentally pressed <Control-C> instead of <Control-V>,
    arggh! This bug needs to be fixed yesterday! Pressing <Control-C> with
    no active selection should sound the error bell, not copy "".

    *Using the goto-line command should highlight the requested line.
    Currently all that IDLE does is place the insertion cursor at the
    start of the requested line which is completely useless. One more line
    of code in the goto method would make this action more useful

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

    *Canvas needs a canvas.rotate() method for polygons, lines -- (easy).

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

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

    [Warning: puesdo code ahead!]

    class ComboBox(master, values, etc..)
    def __init__(blahblahblah)
    self.values = values
    if type(values) == dict:
    self.values = values.keys())
    listbox.load(self.values)

    def onUserPick(self, arg):
    if type(self.values) == dict:
    self.entry.set(self.values[arg])
    return
    self.entry.set(arg)

    ---------------------------------------------
    Tix In General
    ---------------------------------------------
    *I am not a big fan of the Tix Module. The idea behind the widgets is
    great, but using most of them is a nightmare on elm street with Jason
    Voorhees in hot pursuit. I have hacked my own far more elegant
    versions of the more useful Tix Widgets and i feel mine are less buggy
    and more user friendly. So i say lose Tix and go with my fix, or get
    stuck with the Tix!

    *Python is missing good docs for Tix. The only thing i can find is the
    Tcl docs which are riddled with horribly cryptic tcl code.

    ---------------------------------------------
    Tix NoteBook
    ---------------------------------------------
    *The Tix.NoteBook widget has a bug. If you subclass Frame for your
    toplevel window you can't create a notebook widget as a descendant of
    the frame because it just blows chunks. The only way i have
    successfully used the widget is by the noobish style...

    >>> import Tix
    >>> root = Tix.Tk()
    >>> notebook = Tix.NoteBook...blah
    >>> root.mainloop()


    *Overall however i feel the IDLE "TabbedWidget" out-performs the
    Tix.NoteBook by miles and is easier to use, although it does have a
    few design problems that i have fixed. One of the most predominate
    being the inability to see the tabs clearly. The selected tab should
    "stand-out" from the others so a user can spot it quickly. Also there
    is no reason to export TabSet class and this can clean up the code a
    bit.

    ---------------------------------------------
    Tix ComboBox
    ---------------------------------------------
    *What is with that big ugly arrow? This widget is an exercise in
    cruelty to humans, and thats all i will say about it!


    ---------------------------------------------
    Final Thoughts
    ---------------------------------------------
    Well, that is all i can remember for now. If you've made it this far
    without losing your temper or your lunch well i am very surprised ;).
    Anyway, give me some feedback on these ideas so maybe i can get
    motivated to submit some patches/enhancements.

    psst... help is welcome too ya'know :)
     
    r, Aug 27, 2009
    #1
    1. Advertising

  2. r

    eb303 Guest

    On Aug 27, 11:22 pm, r <> 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.
     
    eb303, Aug 28, 2009
    #2
    1. Advertising

  3. r

    r Guest

    Thanks eb303 for the wonderful post

    I have looked over the new ttk widgets and everything looks nice. I am
    very glad to see the death of Tix as i never much liked it anyhow and
    always believed these widgets should have been in the main Tkinter
    module to start with. The tree widget has been needed for some time.

    However, i am not sure about the new "style" separation. Previously a
    simple command like root.option_add('*Label.Font'...) accomplished the
    same thing with less typing, but there may be a future method to this
    current madness that i am unaware of...???
     
    r, Aug 28, 2009
    #3
  4. r

    Mark Roseman Guest

    With regard to Tkinter documentation, and in particular the newer, more
    modern aspects thereof (e.g. ttk, styles, etc.) please have a look at
    the tutorial at http://www.tkdocs.com

    Would it be useful to link to this from the main Python Tkinter
    documentation?

    Mark
     
    Mark Roseman, Aug 28, 2009
    #4
  5. r

    r Guest

    On Aug 28, 11:12 am, Mark Roseman <> wrote:
    > Would it be useful to link to this from the main Python Tkinter
    > documentation?
    >
    > Mark


    Thanks Mark, but i would hate to see more links to TCL code in the
    python docs. Whats the use of Tkinter if the docs are in TCL. Just
    learn TCL and skip the Python middleman. But i don;t want to code in
    TCL (*puke*) i much prefer Python even if i am calling wrapped TCL.
    Not to mention this link is not a complete coverage of all the widgets
    anyway.

    We desperately need a complete reference for tkinter written with only
    Python code that covers all widgets, all widget options, and all
    widget methods. And this would be a minimal effort if someone would
    just do it. Most of the information is already out there in various
    locations around the net. We just need to compile, compress, and edit
    it into one short and to the point reference material.

    I will happily volunteer to create on my own or contribute to the docs
    if i can get a guarantee from the tkinter maintainer that my work
    would not be in vain.
     
    r, Aug 28, 2009
    #5
  6. r wrote:
    > On Aug 28, 11:12 am, Mark Roseman <> wrote:
    >> Would it be useful to link to this from the main Python Tkinter
    >> documentation?
    >>
    >> Mark

    >
    > Thanks Mark, but i would hate to see more links to TCL code in the
    > python docs. Whats the use of Tkinter if the docs are in TCL. Just
    > learn TCL and skip the Python middleman. But i don;t want to code in
    > TCL (*puke*) i much prefer Python even if i am calling wrapped TCL.
    > Not to mention this link is not a complete coverage of all the widgets
    > anyway.
    >
    > We desperately need a complete reference for tkinter written with only
    > Python code that covers all widgets, all widget options, and all
    > widget methods. And this would be a minimal effort if someone would
    > just do it. Most of the information is already out there in various
    > locations around the net. We just need to compile, compress, and edit
    > it into one short and to the point reference material.
    >
    > I will happily volunteer to create on my own or contribute to the docs
    > if i can get a guarantee from the tkinter maintainer that my work
    > would not be in vain.

    Please go ahead and try it. Having read the "Summary of Python tracker
    Issues" on the python-dev mailing list, and followed from there to the
    bug tracker, it seems that all input is greatly appreciated. For the
    small issues the reply is often "Thanks, done". Some things get
    rejected, and usually rightly so from what I can see. Others the issue
    is closed with the half way house committed/rejected. Work that out for
    yourself if you can.:)

    --
    Kindest regards.

    Mark Lawrence.
     
    Mark Lawrence, Aug 28, 2009
    #6
  7. r wrote:

    > Whats the use of Tkinter if the docs are in TCL. Just
    > learn TCL and skip the Python middleman.


    But Mark's tutorial at http://www.tkdocs.com/tutorial/index.html allows
    you to select 'Python' as one of the languages you want to see the
    example code in.

    Too bad that the 'ttk' widgets are not mainstream yet.

    Greetings,

    --
    "The ability of the OSS process to collect and harness
    the collective IQ of thousands of individuals across
    the Internet is simply amazing." - Vinod Valloppillil
    http://www.catb.org/~esr/halloween/halloween4.html
     
    Michiel Overtoom, Aug 28, 2009
    #7
  8. r

    Mark Roseman Guest

    r <> wrote:
    > On Aug 28, 11:12 am, Mark Roseman <> wrote:
    > > Would it be useful to link to this from the main Python Tkinter
    > > documentation?

    >
    > Thanks Mark, but i would hate to see more links to TCL code in the
    > python docs. Whats the use of Tkinter if the docs are in TCL.


    The www.tkdocs.com site is 'language neutral' - currently the tutorial
    covers Tcl, Perl, Ruby and yes Python, and allows you to switch between
    any of those languages (or show all of them).
     
    Mark Roseman, Aug 28, 2009
    #8
  9. r

    r Guest

    On Aug 28, 5:48 pm, Mark Roseman <> wrote:
    (snip)
    > Thewww.tkdocs.comsite is 'language neutral' - currently the tutorial
    > covers Tcl, Perl, Ruby and yes Python, and allows you to switch between
    > any of those languages (or show all of them).


    True, however the coverage is incomplete. I would back this site if we
    can get a complete coverage of all widgets in the Python language.

    +0.1
     
    r, Aug 29, 2009
    #9
  10. r

    eb303 Guest

    On Aug 28, 4:41 pm, r <> wrote:
    > Thanks eb303 for the wonderful post
    >
    > I have looked over the new ttk widgets and everything looks nice. I am
    > very glad to see the death of Tix as i never much liked it anyhow and
    > always believed these widgets should have been in the main Tkinter
    > module to start with. The tree widget has been needed for some time.
    >
    > However, i am not sure about the new "style" separation. Previously a
    > simple command like root.option_add('*Label.Font'...) accomplished the
    > same thing with less typing, but there may be a future method to this
    > current madness that i am unaware of...???


    The new widgets have been made mainly to make tk look better by making
    it possible to use native widgets. The drawback is that it limits a
    lot the possibilities of configuration you can have: on many
    platforms, the looks of the widgets are decided by the user via a
    system preference, not by the application programmer. This is why ttk
    widgets are not configurable directly, because 'native' styles usually
    don't allow it at application level anyway.

    Keep in mind that the new ttk widgets are not replacements for former
    widgets, but an addition to them. 'Old' widgets are still here, and
    there is no plan I know of to remove them. If you want to do an
    application with a very specific look, you can still use these.
     
    eb303, Aug 31, 2009
    #10
  11. r

    Kevin Walzer Guest

    On 8/28/09 8:11 PM, r wrote:
    > On Aug 28, 5:48 pm, Mark Roseman<> wrote:
    > (snip)
    >> Thewww.tkdocs.comsite is 'language neutral' - currently the tutorial
    >> covers Tcl, Perl, Ruby and yes Python, and allows you to switch between
    >> any of those languages (or show all of them).

    >
    > True, however the coverage is incomplete. I would back this site if we
    > can get a complete coverage of all widgets in the Python language.
    >
    > +0.1


    Are you certain the site is incomplete? Its coverage of the basic Tk and
    Ttk widgets is spectacular. . Its coverage of layout techinques and
    best practices for organizing complex interfaces with Tk is also
    extremely valuable. I wish this site had been around when I was learning
    Tk five years ago. I've looked at just about every Tk and Tkinter
    tutorial site out there, and this one surpasses them all. Mark
    Roseman--a professional, independent software developer whose commercial
    products almost all incorporate Tk into their GUI's--has spent a couple
    of years putting together this site with input from various users and
    developers (myself included). It's now an absolutely indispensible
    resource for beginners and more experienced developers.

    The reason the site does not cover 'all widgets in the Python language'
    is threefold:

    1. It's a site about Tk, a tookit that has Python bindings and bindings
    to other languages also (Ruby, Perl, Tcl, etc.).
    2. It omits additional Python-specific, Tkinter-based widget sets such
    as PMW, Tix, etc. because once you understand the basics of Tk, then
    grokking these other megawidget sets (which all build on top of Tk)
    should be pretty straightforward.
    3. Finally, 'all widgets in the Python language' gets into other tookits
    as well, which is obviously unfeasible for a website.

    If the site by itself isn't enough for you, or is a bit too basic in its
    coverage of Python techniques, then there are other options. Couple the
    TkDocs site with effbot's more advanced walk through the various Tkinter
    classes, and perhaps one or two of the other Tkinter-specific tutorials,
    and you'll have learned a lot. But I think the TkDocs site is essential,
    especially in its more advanced discussion of how to put together an
    attractive, polished user interface with Tk. Tk has a long-standing
    reputation of being the toolkit of choice for quick, simple, ugly
    interfaces, and the other resources I've mentioned do nothing to to
    change this. The practices that Mark Roseman discusses will allow one to
    eventually put together a UI that matches anything that the other big
    toolkits (wxPython, PyQt, PyObjC, PyGtk, etc.) can do.

    Hope this helps,
    Kevin

    --
    Kevin Walzer
    Code by Kevin
    http://www.codebykevin.com
     
    Kevin Walzer, Aug 31, 2009
    #11
  12. r

    Terry Reedy Guest

    Kevin Walzer wrote:
    www.tkdocs.com

    [snip]

    > and you'll have learned a lot. But I think the TkDocs site is essential,
    > especially in its more advanced discussion of how to put together an
    > attractive, polished user interface with Tk. Tk has a long-standing
    > reputation of being the toolkit of choice for quick, simple, ugly
    > interfaces, and the other resources I've mentioned do nothing to to
    > change this. The practices that Mark Roseman discusses will allow one to
    > eventually put together a UI that matches anything that the other big
    > toolkits (wxPython, PyQt, PyObjC, PyGtk, etc.) can do.
    >
    > Hope this helps,


    It persuaded me to go and start reading. A couple of things of interest.

    "It would be a great help if you could have a look around, provide any
    comments, corrections or suggestions, or even help fill in some of the
    missing pieces. "

    so no pretense of completeness yet.

    "In the near future, the plan is to continue refining the tutorial,
    mainly finishing up the rest of the Perl and Python examples."

    And from the linked blog

    "July 09, 2009
    Python material in progress.

    While not yet complete, I've managed to add a very hefty chunk of Python
    material to the tutorial. I should be able to complete the rest over the
    next week or so. Would definitely appreciate feedback from any
    Pythonistas on the existing material.

    While I hadn't used it before, I think Tkinter may very well be the
    nicest interface to Tk next to Tcl's (for which Tk was originally
    designed of course, so you'd expect a bit of an advantage). For people
    unfamiliar with either language, I think Python's more conventional use
    of parentheses for functions, the "option=value" syntax, plus other
    language features it takes advantage of are very attractive and win out
    over Tcl. The two main parts that I think Tcl does in a nicer way are
    event bindings and the fact you can create and geometry manage a widget
    in one statement, while still keeping a handle to a widget around.

    UPDATE July 17/2009: Most of the rest of the Python examples and code
    snippets have been added.
    "

    tjr
     
    Terry Reedy, Aug 31, 2009
    #12
  13. r

    r Guest

    Kevin and Terry,


    Kevin.
    I respectfully disagree that the site is ready for prime time
    *However* i do not wish to undermine the great work that Mark Roseman
    has done here and i thank him for his contribution. He has put much
    work into covering all the major languages and i think this site
    *could* turn out to be the best one-stop-shop for Tk coding no matter
    what language you come use. And Actually of all the sites that i know
    of, his is by far the most professional/modern looking of all!

    My only beef with Mark's site is lack of detailed information OR a
    reference manual of sorts in the Python language. We have too many
    places around the net one must go to get this information when
    starting the road to Tkinter.

    The Effbot site is great with much detail but is not a good reference.
    John's NMT site is a great reference but lacks the extensive tutorial
    style details of effbot. Mark's site is the shiny new corvette,
    however the engine is on back order?

    We need to compile this info into one beautiful orgy of Tkinter
    learning material. Here are the three sites that i mentioned above,
    they would compress well into one...

    http://effbot.org/tkinterbook/
    http://infohost.nmt.edu/tcc/help/pubs/tkinter/
    http://www.tkdocs.com/


    [TERRY SAID..]
    While I hadn't used it before, I think Tkinter may very well be the
    nicest interface to Tk next to Tcl's (for which Tk was originally
    designed of course, so you'd expect a bit of an advantage). For people
    unfamiliar with either language, I think Python's more conventional
    use of parentheses for functions, the "option=value" syntax, plus
    other
    language features it takes advantage of are very attractive and win
    out over Tcl.
    [/TERRY]

    Well put Terry! I could not agree more with this assessment! Pythons
    wrapping of Tk is so beautiful next to the other languages i can bet a
    lot of Ruby, Tcl, and Perl guys are going to feel like ugly ducklings
    at a Ms america pageant! (but i may be partial to Python code... just
    a little) ;-)

    When it comes to using Tkinter I think a lot of people let ego get in
    the way. Yes the name may sound synonymous with "Tinker Toys" however,
    TEE-KAY-ENTER is a great (albeit simple) GUI toolkit. I use it quite
    often and reach for the power of wx only when i need the extra
    functionality -- which the gap is starting to close. Anyhow, welcome
    to Tkinter Terry, i only wished you would had dropped by
    sooner...??? :)

    psst: maybe you can use your influence and convince others that Tk is
    not so bad?
     
    r, Aug 31, 2009
    #13
  14. r

    r Guest

    On Aug 28, 11:12 am, Mark Roseman <> wrote:
    > Would it be useful to link to this from the main Python Tkinter
    > documentation?
    >
    > Mark


    Sorry Mark,
    i did not realize when i replied to you that YOU are the Mark of
    tkdoc.com. For some reason i only saw Tcl code when i visted the site,
    and that prompted my slightly grumpy rant. After looking a second time
    (and actually reading more) i see this site has much promise. I hope
    my post did not seem condescending of your efforts. I think your site
    is beautiful and just wish we could add MORE Python specific info to
    it like i covered in my last post. And also I would like to see a
    complete coverage of all the widgets.

    We more experienced guys already know how and where to find the
    thousand or so sites for this or that Python info, but the new users
    are going to be lost in the wilderness. I love that Python has so much
    info out there, i just hate that is so spread out! We must do
    something about this in a way that all doc/tut creators can be happy.

    PS: and i would like to contribute to your site.
     
    r, Aug 31, 2009
    #14
  15. r

    r Guest

    A few things i forgot to mention...

    +------------------------------+
    Things i forgot... IDLE Editor
    +------------------------------+
    1. class and path browsers should be available in a tabbed widget
    located in the left side of the Editor window. Should also have a show/
    hide button or have them contained in a paned window for user reszing.


    +--------------------------+
    Things i forgot... Tkinter
    +--------------------------+
    1. Class naming makes no sense...?
    Text should be TextBox
    Radiobutton should be RadioButton
    Checkbutton should be CheckButton
    ListBox should be ListBox
    (but at least Text should be Textbox!)

    2. All text related widgets (Text, Listbox, Entry, Label, CheckButton,
    RadioButton, should have a w.sets(setstr) and w.gets(getstr) methods
    along with their .insert() method. The settr/getter methods should
    take any argument in the form of [str, lst, tuple] and insert the
    lines automatically. Why you ask. Well because i hate calling...

    >>> w.delete(start, stop)
    >>> w.insert(END, str)

    #-- or even worse
    >>> for x in collection:

    w.insert(END, x)
    #-- this should be the correct ways
    >>> w.sets([1,2,3])
    >>> w.sets((1,2,3))
    >>> w.sets(line1\nline2\nline3\n) #splits lines for listbox


    thats all for now folks!
     
    r, Oct 12, 2009
    #15
  16. r

    TerryP Guest

    On Aug 27, 9:22 pm, r <> wrote:
    > ---------------------------------------------
    > 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.
    >


    'import Tkinter as tk', that I like -- my fingers are lazier then the
    mind ;).


    When I see the from whatever import *; I generally regard it in one of
    two Things: Good Thing or Bad Thing.


    Good Thing:
    sometimes program-locale modules are better used
    with import *, unless you really should be writing
    BazInternals.quxmire everywhere.

    Bad Thing:
    ahh crap, now I need to know what *is* being
    slammed into this namespace.

    The programmer should be competent to judge which is appropriate, if
    not then they should be *educated* rather then have a hand held, and
    told a lullaby. Pass the whisky.

    However, I admit that I wish more official documentation dispensed
    with the brevity of writing bar() over foo.bar(), it would save me
    from having to pay attention to what they are saying in the first
    place ;)

    On Aug 27, 9:22 pm, r <> wrote:
    > <W1> <-------- W2 ----------->
    > >>> | for x in range(10): |

    > ... | print x |
    > ... | for y in range(x): |
    > ... | print y |
    > |1
    > |2
    >


    I agree, there should be some reason to use IDLE instead of your
    systems command prompt ;).

    On my Pentium D machine, under Windows NT 5.1 (XP), just *moving* the
    IDLE shell window around causes taskmgr to report double the CPU
    usage, not to mention the choppy feeling it produces. I assume that is
    a Tkinter problem. I doubt splitting it the way you describe would
    make it any slower.


    On Aug 27, 9:22 pm, r <> wrote:
    > Since IDLE has no horizontal scroll bar you must
    > use MMB to scroll left-right.


    What about having a mouse wheel that tilts left or right? ;}


    On Aug 27, 9:22 pm, r <> wrote:
    > *Something that always gets a Python IDLE noob is "open-bracket-syntax-
    > errors" in IDLE. When Python throws this type of error normally the
    > only clue you will get from IDLE is to see the last line highlighted.
    > However, the missing or misplaced bracket is usually no where near the
    > end of the script. IDLE can be easily fixed to show a much closer or
    > even exact location of the last open bracket.


    Considering how often people fuddle up matching marks [], (), {}, '',
    "", etc --- why not make Python 'throw' something more helpful
    instead? :p.

    For the amount of time that I have used Perl over the years, I learned
    two things very important from it. 0.) All language implementations
    tend to _s_u_c_k_ at reporting syntax errors; and 1.) if the syntax
    error being reported sounds utterly insane, you probably forgot
    something; somewhere.


    On Aug 27, 9:22 pm, r <> wrote:
    >
    > *One of my all time pet peeves with all text editors. Everybody repeat
    > after me...
    >
    > """NO TEXT EDITOR SHOULD EVER COPY AN EMPTY STRING TO THE
    > CLIPBOARD!!"""
    >
    > ...I can't tell you how many times I've had to re-copy some text
    > because i accidentally pressed <Control-C> instead of <Control-V>,
    > arggh! This bug needs to be fixed yesterday! Pressing <Control-C> with
    > no active selection should sound the error bell, not copy "".
    >


    No, that is probably wrong.


    People should use (and create) better software, not create software
    that side steps even worse software. "Be liberal in what you accept,
    and conservative in what you generate" -- good idea, unless your job
    is (almost) strictly GIGO. The clipboard is a garbage buffer, not a
    water filter.


    If you use Windows a lot, might I suggest a small program called
    Qlipboard <http://code.google.com/p/heresylabs/wiki/Qlipboard>.



    ==== kind off topic ====

    The first GUI widget toolkit [sic] that I ever learned, was Qt. It
    took me three nights of after work play time to do it: one each to
    (re)learn Python, learn Qt/GUI stuff, and practice them both. I did
    that using the C++ documentation for Qt and the Python documentation
    index for Python. That was with NO experience what so ever in
    developing software around graphical user interfaces, unless you count
    a love for the `cat f1 f2 f3 | sort | uniq | mail -s "subject"
    ` school of software design.

    Tk is probably an excellent toolkit for people to use at first (I've
    never used it) but good documentation and an API that's light on brain
    damage is the *best* thing to follow up with, next to mind reading ;).

    --
    TerryP.
    Just Another Programmer
     
    TerryP, Oct 12, 2009
    #16
  17. r

    r Guest

    On Oct 12, 12:43 am, TerryP <> wrote:
    > On Aug 27, 9:22 pm, r <> wrote:
    > > *Too many noobs start out with the "from Tkinter import *" idiom,

    >
    > 'import Tkinter as tk', that I like -- my fingers are lazier then the
    > mind ;).
    >
    > When I see the from whatever import *; I generally regard it in one of
    > two Things: Good Thing or Bad Thing.



    Obviously you have never used packages that are meant for global
    importing or you would know how such systems are designed. OpenGL is
    a good example. OpenGL has over 3600 functions and constants all of
    which start with "gl" and GL respectivly. However the Tkinter package
    is not a good candidate for this in real use cases. Not only do you
    have all the widget classes and functions you have the constants
    imported too. ~180 names are imported this way, far too many when not
    protected by a naming convention! However learning to use Tkinter for
    the beginner is much eaiser when using global imports and i think that
    is OK. But very shortly after it is a good idea to get in the habit of
    quialifing names with tk.thisorthat().


    > I agree, there should be some reason to use IDLE instead of your
    > systems command prompt ;).
    >
    > On my Pentium D machine, under Windows NT 5.1 (XP), just *moving* the
    > IDLE shell window around causes taskmgr to report double the CPU
    > usage, not to mention the choppy feeling it produces. I assume that is
    > a Tkinter problem. I doubt splitting it the way you describe would
    > make it any slower.


    Sarcasm anyone? Yes IDLE is not meant for writing million line scripts
    but who would want to anyway? And I doubt leaving it in such a
    terrible condition will help anyone either. You may find the IDLE and
    Tkinter useless but many people find both to be indispensable
    (especially noobs). I think this is a case of champagne taste's on a
    whiskey budget for you friend!

    > > """NO TEXT EDITOR SHOULD EVER COPY AN EMPTY STRING TO THE
    > > CLIPBOARD!!"""

    >
    > No, that is probably wrong.


    No it's exactly right and a one-liner to fix. And btw: pass the
    reefer because it ain't just whiskey clouding your mind fella! Why do
    you reply to a thread about a subject you obviously don't care about?
    If you've never used Tkinter or IDLE (and never will) you have no
    reason to reply except for the trolling aspect?

    good day!
     
    r, Oct 12, 2009
    #17
  18. r

    TerryP Guest

    On Oct 12, 7:29 am, r <> wrote:
    > Obviously you have never used packages that are meant for global
    > importing or you would know how such systems are designed. OpenGL is
    > a good example. OpenGL has over 3600 functions and constants all of
    > which start with "gl" and GL respectivly. However the Tkinter package
    > is not a good candidate for this in real use cases. Not only do you
    > have all the widget classes and functions you have the constants
    > imported too. ~180 names are imported this way, far too many when not
    > protected by a naming convention! However learning to use Tkinter for
    > the beginner is much eaiser when using global imports and i think that
    > is OK. But very shortly after it is a good idea to get in the habit of
    > quialifing names with tk.thisorthat().
    >


    I suppose you are right about that one, the largest things I've ever
    had to imported tops out around ~600 names; although only used in
    interactive mode, not finished product.

    One thing you should also learn about me, is I do not deal in
    absolutes. If you don't understand the meanings associated with that,
    then try importing yourbrain.reflection into a private namespace.


    On Oct 12, 7:29 am, r <> wrote:
    > Sarcasm anyone?


    If you can't stand sarcasm, you are living on the wrong planet.

    On Oct 12, 7:29 am, r <> wrote:
    > Yes IDLE is not meant for writing million line scripts
    > but who would want to anyway?


    I would assume that is obvious 8=), however any editing interface may
    be used for writing million line anythings -- just look at ed <http://
    en.wikipedia.org/wiki/Ed_(text_editor)>.

    On Oct 12, 7:29 am, r <> wrote:
    > You may find the IDLE and
    > Tkinter useless but many people find both to be indispensable
    > (especially noobs). I think this is a case of champagne taste's on a
    > whiskey budget for you friend!
    >


    You are both right and wrong: I find IDLE useless because I edit code
    written in more then one (programming) language, thus any editor that
    is not (more) language agnostic is useless to me, and probably every
    other programmer that refuses to waste time learning an IDE per
    language (and so on).

    Tkinter however is not, because it is an interface to Tk ;). Ok, if
    you have a broken display , then it is probably useless, guess you are
    right on that one too.


    I said I had never used Tk, not that it was useless. Depending on your
    style of parsing English, one could also call me a liar (or a louse),
    as I have used programs built on Tk but have never written programs
    with Tk. I'll leave individual readers to determine that result.

    On Oct 12, 7:29 am, r <> wrote:
    > > > """NO TEXT EDITOR SHOULD EVER COPY AN EMPTY STRING TO THE
    > > > CLIPBOARD!!"""

    >
    > > No, that is probably wrong.

    >
    > No it's exactly right and a one-liner to fix. And btw: pass the
    > reefer because it ain't just whiskey clouding your mind fella!



    Adding data to the clipboard belongs in the program, the decision of
    *what* to place in the clipboard (generally) belongs with the user and
    not to their program. Mistakenly overwriting the contents of a buffer
    that you meant to retain for a longer period of time, is not the
    buffers problem. Get it?


    As I do not believe in absolutes, I therefore believe that there are
    times where my statement is False, in this case however I believe it
    is True. If you do not agree, then we have a _philosophical_
    difference of opinion, and should agree to disagree.



    Also the whiskey thing was an obscured reference to a song, not a
    reference to my blood alcohol level. Which is probably much lower then
    whoever created Tkinter from the looks of both the package and your
    comments.

    On Oct 12, 7:29 am, r <> wrote:
    > Why do
    > you reply to a thread about a subject you obviously don't care about?


    Where I come from, one would say that you asked for feedback:

    On Aug 27, 9:22 pm, r <> wrote:
    > ---------------------------------------------
    > Final Thoughts
    > ---------------------------------------------
    > Well, that is all i can remember for now. If you've made it this

    far
    > without losing your temper or your lunch well i am very

    surprised ;).
    > Anyway, give me some feedback on these ideas so maybe i can get
    > motivated to submit some patches/enhancements.
    >
    > psst... help is welcome too ya'know :)



    –noun
    1. Electronics.
    a. the process of returning part of the output of a circuit,
    system, or device to the input, either to oppose the input (negative
    feedback) or to aid the input (positive feedback).
    ....
    5. Psychology. knowledge of the results of any behavior, considered
    as influencing or modifying further performance. Compare biofeedback.


    Now if you only wanted "Yes sir, that is a jolly good idea" types of
    response, you should be more explicit about not wanting differing
    opinions included.


    On Oct 12, 7:29 am, r <> wrote:
    > If you've never used Tkinter or IDLE (and never will) you have no
    > reason to reply except for the trolling aspect?
    >
    > good day!


    See the above.

    Also note this: I never said I would _n_e_v_e_r_ use Tkinter.


    Evaluating Tk interfaces under several languages, has been on my todo
    list for a very long time. There are however other libraries with a
    more pressing need to be evaluated before they are cycled into
    projects.

    --
    TerryP.
    Just Another Programmer
     
    TerryP, Oct 12, 2009
    #18
  19. r

    Mel Guest

    Ben Finney wrote:

    > TerryP <> writes:
    >
    >> One thing you should also learn about me, is I do not deal in
    >> absolutes.

    >
    > What, *never*? That's a pretty uncompromising position to h—
    >
    > I'll get my coat.


    Note, he said he does not deal in absolutes. He didn't deny that he does.

    Mel.
     
    Mel, Oct 12, 2009
    #19
  20. r

    Aahz Guest

    In article <>,
    Ben Finney <> wrote:
    >TerryP <> writes:
    >>
    >> One thing you should also learn about me, is I do not deal in
    >> absolutes.

    >
    >What, *never*?


    Well, hardly ever.
    --
    Aahz () <*> http://www.pythoncraft.com/

    "To me vi is Zen. To use vi is to practice zen. Every command is a
    koan. Profound to the user, unintelligible to the uninitiated. You
    discover truth everytime you use it."
     
    Aahz, Oct 16, 2009
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Tom
    Replies:
    3
    Views:
    429
    Elliot M. Rodriguez
    Jan 21, 2004
  2. Replies:
    1
    Views:
    452
    NullBock
    Jan 5, 2006
  3. Free Online Assessment Tests

    , Jan 5, 2006, in forum: C Programming
    Replies:
    3
    Views:
    358
    Randy Howard
    Jan 5, 2006
  4. Replies:
    4
    Views:
    3,368
    JustBoo
    Jan 5, 2006
  5. Ramesh Mani
    Replies:
    2
    Views:
    311
    Richard
    Jan 5, 2009
Loading...

Share This Page