tk_happy Has Some Warts
Iknow there are some shortcommings in tk_happy, however, my
goal was to create a fast convenient path to a working Tkinter GUI for everyday use.
I feel like the alternatives to tk_happy tend to focus more on complete support for the
Tkinter inferface. My approach was to try and eliminate many of the Tkinter options
in favor of simplicity. Experienced users can easily add advanced options to an interface
created by tk_happy. User modification of the generated python file is actually one
of tk_happy's better features.
I apologize for the name "tk_happy".
I was looking for an approach
to Tkinter programming that would make me happier and a name that both incorporated
the obligatory "py" and linked in Tk... Enter "tk_happy".
I need to refactor tk_happy. It was created pretty quickly and with a little too much
"organic" development, however, I think it is still effective at creating quick
GUI interfaces. I'm very happy with the fact that a working GUI framework can be
created in minutes. Rather than delay the release of tk_happy, I am making this 1st draft
available. I will no-doubt do the rewrite as part of getting out of alpha stage software.
I use "place" not "pack" in tk_happy. I think because of my experience with Delphi, I
tend to be more placement oriented than pack oriented. It seems like the big benefits of
pack are the ability of windows to resize themselves with "often reasonable" logic, as well as
more cross-platform friendliness.
For me, the use of pack reminded me of the Jamie Zawinski quote regarding
regular expressions. (substitute "pack" for "regular expressions")
Some people, when confronted with a problem, think
“I know, I’ll use regular expressions.” Now they have two problems.
—Jamie Zawinski, in comp.lang.emacs
Rather than ask users who might be unfamiliar with the various pack commands
(anchor, side, fill, expand, padx, pady, etc.), I chose to let the user simply
click the spot where they wanted the widget. Advanced users can edit their python
files if they so choose, however, more novice users will simply have an interface that
works pretty well under most circumstances.
TODO List:
1) Add pop-up menus on Edit Form
2) Add more Tk widgets
3) Add native Tk based tabbed notebook
4) Add Pmw widgets
I hope the benefits of quickly making a working Tkinter GUI will outweigh any
tk_happy shortcomings or over simplifications.
Alternatives to tk_happy:
There are other options for creating Tkinter-based python applications.
I believe that the 2 shown below are the most common.
1) Python code generation with
SpecPython by Erik Brunel
SpecPython is an add-on to SpecTcl shown below.
SpecTcl is obviously more mature than tk_happy
however the SpecPython package is labeled "Experimental".
|
|
2) Another option is
Rapyd-Tk ( Rapid python development with Tkinter) - which
is an open-source development environment specifically tailored for developing applications using
Python, Tkinter and, optionally, Pmw.
|
|
|