JAIPUR ENGINEERING COLLEGE AND RESEARCH CENTRE

DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING

Seminar Synopsis

TITLE: Tkinter: A python Library To Create GUI

IMPORTANCE OF PROPOSED INVESTIGATION:

Tk/Tcl has long been an integral part of Python. It provides a robust and platform
independent windowing toolkit, that is available to Python programmers using the
tkinter package, and its extension, the tkinter.tix and the tkinter.ttk modules.

The tkinter package is a thin object-oriented layer on top of Tcl/Tk. To use tkinter ,
you don’t need to write Tcl code, but you will need to consult the Tk documentation,
and occasionally the Tcl documentation.Tkinter is a set of wrappers that implement
the Tk widgets as Python classes. In addition, the internal module _tkinter provides a
threadsafe mechanism which allows Python and Tcl to interact.

Tkinter’s chief virtues are that it is fast, and that it usually comes bundled with
Python. Although its standard documentation is weak, good material is available,
which includes: references, tutorials, a book and others. Tkinter is also famous for
having an outdated look and feel, which has been vastly improved in Tk 8.5.
The tkinter package (“Tk interface”) is the standard Python interface to the Tk GUI
toolkit. Both Tk and tkinter are available on most Unix platforms, as well as on
Windows systems. (Tk itself is not part of Python; it is maintained at ActiveState.)

Basic window in tk is as below:

REVIEW OF LITERATURE AND RESEARCH GAP:

In this section, we will highlight the comparison between tkinter and other GUI
modules.
They have comparable controls and layouts. The wxPython version is 76 lines and the
tkinter version is 48 lines, most of which is accounted for by layout code.
The wxPython example uses nested HBOX and VBOX sizers, which is my preferred
way to handle layout using that toolkit because I find it easier to reason about, and
therefore, easier to maintain and modify. The tkinter example uses a grid layout, and
this does account for some of the difference in program length. However, it also
points to quite a different design choice between the two toolkits: wxPython
externalizes the layout classes in its sizer hierarchy, whereas tkinter internalizes
layout so that each widget manages its own children using a variety of policies, of
which grid is just one.
UI layout in wxPython is not a lot of fun, and I’ve never found GUI builders–from
DialogBlocks to BoaConstructor and beyond–to be much help. Managing the parallel
hierarchies of sizers and windows adds complexity without a lot of additional
functionality – in that delightful 1990’s object-oriented way that seemed like such a
good idea to all of us at the time.
tkinter does away with all that by hiding layout policy behind the widget interface.
You just add children to their parent’s grid. You don’t have to create the grid sizer,
add the children to it, and then set it as the sizer on the parent. This inevitably creates
a bunch of names like “gridSizer1” along the way that you’ll regret when it comes
time to edit the UI code.
Then there is the speed comparison. For example, how long does it take from
typing python myapp.py at the command prompt to the UI being shown on the
screen? The difference is negligible on a desktop machine, but on a little embedded
ARM processor the wall-clock seconds for these simple example programs come out
like this:
wxPython: 6 seconds
tkinter: 1 second
It wasn’t the world’s most sophisticated test–I just used my watch for the timings–but
the difference is so big it doesn’t have to be. The canonical absolute response time
that users are willing to tolerate is 2 seconds, going from three times that to less than
half is kind of a big deal.
I’ve done a lot of embedded work over the years, and even got wxX11 to compile on
an ARM board that has almost as much computing power as a toaster. The C++
version is fast enough that users don’t experience perceptible lag. I’ve run some
wxPython-based tools on the same system (maintenance scripts for field engineers,
who will tolerate anything) and have always been disappointed at how slow they
were. I would love to re-write the main application UI in Python and let C++ do all
the low-level stuff underneath, but it just didn’t seem practical given even
wxGTK/C++ was unacceptably slow on that board.
I’ve looked at a lot of different toolkits for embedded UI over the years: Qt
Embedded, GTK and GTK+, FLTK, and so on. None of them met the criteria of

2
power, maturity, i18n/l10n, and speed that I needed for embedded systems running on
boards in the “Raspberry Pi or a bit smaller” category.
Now, I feel like the search may be over, and the solution was right under my nose the
whole time. I just never paid attention to it because of an outdated and incorrect
attitude toward Tcl/Tk and tkinter.
If you haven’t had a chance to try ActivePython it comes pre-compiled with all the
most popular Python packages and is free to use in development and testing.

3
 Objectives:

(A) Evaluate Understanding the concept of a root window and a main loop.

(B) Understanding widgets-the building blocks of programs.

(C) Getting acquainted with a list of variable widgets.

(D) Developing layouts by using different geometry managers.

(E) Applying events and callbacks to make a programs functional.

(F) Styling widgets by using options and configuring the root widget

Facilities required for proposed :

 Processors: Intel Atom® processor or Intel® Core™ i3 processor
 Disk space: 1 GB
 Operating systems: Windows* 7 or later, macOS, and Linux
 Python* versions: 2.7.X, 3.6.X

Signature of the candidate with date

Ashutosh Agrawal
16EJCCS713
Computer Science
Jaipur Engineering College & Research Centre
Outline Approved
( …………..)
(Supervisor)
Name : …………………………………
Designation : ………………………….
Department Name :……………………
College Name:………………………….