GUI:-please answer want to learn GUI programming in python , howshould i proceed.

J

Jai

GUI:-want to learn GUI programming in python , how should i proceed.

There are lots of book here so I am confuse which book i should refer so that i don't waste time . please answer
 
C

Chris Angelico

GUI:-want to learn GUI programming in python , how should i proceed.

There are lots of book here so I am confuse which book i should refer so that i don't waste time . please answer

There are many ways to build a GUI with Python. Some of the more
popular toolkits are Tk (tkinter), wxWidgets (wxpython), and GTK.
Explore those and see which one you like; I personally quite like GTK,
and the others have their fans too. There are GUI builders for each of
the above (I think; definitely wx and GTK do), or you can build
everything directly in code (my preferred style). Play around with it
and see what you like!

As a side point, though: You're using Google Groups to post, which
means your posts look messy, because GG doesn't follow internet
standards. Short of getting into Google and fixing Groups, the best
solution is to avoid using it; you can either use some other
newsreader (several here swear by Mozilla Thunderbird), or subscribe
to the email list, which carries all the same content:

https://mail.python.org/mailman/listinfo/python-list

Either way will spare you and us the hassles of malformed posts.

ChrisA
 
W

Wolfgang Keller

GUI:-want to learn GUI programming in python , how should i proceed.
There are lots of book here so I am confuse which book i should
refer so that i don't waste time .

It depends on what you want to do with the GUI, since there are many
different GUI frameworks for Python.

E.g. If you absolutely need to run your applications on MacOS X, then
PyGTK is probably not the best choice. WingIDE, a popular IDE, has been
recently ported to PyQt, apparently for this reason. Besides, PyGTK
itself seems to be "shelved", PyGObject now (since GTK 3) seems to be
the "canonical" way to implement GTK GUIs in Python.

Tkinter is a bit "special" to use since it's not just a library, but
uses some kind of RPC. It seems that "look and feel" have been greatly
improved lately.

wxWidgets (wxPython) recently (since 2.9/3.0) got support for Cocoa,
it's native on the Mac. It's quite slim, but seems to be a "moving
target" API-wise, since the developers are not shy from breaking
compatibility. Is it compatible with Python 3 yet?

PyQt looks native everywhere, but it might be a bit overweight,
depending on what you want to do and where your applications need to
run.

And then there's the licensing issue, since PyQt, unlike Qt itself, is
not available under LGPL afaik. For closed-source commercial
applications, there seems to be a way to use a commercially licensed
PyQt (much less expensive than Qt itself) together with LGPL-Qt
however. Pyside would be a LGPL alternative to PyQt, but it doesn't
seem to be as up-to-date as PyQt.

And then, there are even more frameworks, such as Pygame, PyGUI, etc....

And each of these frameworks has dedicated mailinglists.

Personally I found it difficult to use any of the "wrapped" C++
frameworks without being able to understand the documentation made
for C++. :-(

Sincerely,

Wolfgang
 
R

rurpy

There are many ways to build a GUI with Python. Some of the more
popular toolkits are Tk (tkinter), wxWidgets (wxpython), and GTK.
Explore those and see which one you like; I personally quite like GTK,
and the others have their fans too. There are GUI builders for each of
the above (I think; definitely wx and GTK do), or you can build
everything directly in code (my preferred style). Play around with it
and see what you like!

For learning, tkinter is probably the easiest because it comes
with Python and you don't need to install anything else. The
best way to get started with it is to search for tutorials and
examples on web. Searching for "python tkinter" on Amazon shows
a few books but I don't know anything about them.

wxPython currently runs only with Python2, not Python3. There
is a drag-and-drop form designer available for it but it is a
commercial product that costs money. It also comes with a
useable (once you get used to it) form builder tool that works
by graphically manipulating a text tree of widgets.

The other big, widely-used GUI toolkit is PyQt. It runs on
both Python2 and Python3. There is another version of it
called PySide which is API compatible with PyQt but has
different licensing terms. PyQt comes with a very good
drag-and-drop form designer.

I have played a little with both wxPython an PyQt and found
learning to use them from the web difficult because of their
size and complexity. But both of them have pretty good books
about them available:

Rapid GUI Programming with Python and Qt (Summerfield)
http://www.amazon.com/Programming-Python-Prentice-Software-Development/dp/0132354187

WxPython in Action (Dunn and Rapin)
http://www.amazon.com/Wxpython-Action-Noel-Rappin/dp/1932394621/
As a side point, though: You're using Google Groups to post, which
means your posts look messy, because GG doesn't follow internet
standards. Short of getting into Google and fixing Groups, the best
solution is to avoid using it; you can either use some other
newsreader (several here swear by Mozilla Thunderbird), or subscribe
to the email list, which carries all the same content:

https://mail.python.org/mailman/listinfo/python-list

Either way will spare you and us the hassles of malformed posts.

Chris and some other people here dislike Google Groups and
try to imply that everyone here feels the same way. Not true.

I and many other people here use Google Groups and have been
doing so for years so if Google Groups works for you, please
feel free to continue using it.

If you want to reduce the noise level from people like Chris
you might want to take a look at:

https://wiki.python.org/moin/GoogleGroupsPython
 
M

Mark Lawrence

wxWidgets (wxPython) recently (since 2.9/3.0) got support for Cocoa,
it's native on the Mac. It's quite slim, but seems to be a "moving
target" API-wise, since the developers are not shy from breaking
compatibility. Is it compatible with Python 3 yet?

This is one of the goals of the so called Phoenix project
http://wiki.wxpython.org/ProjectPhoenix
 
M

Mark Lawrence

On 12/14/2013 05:25 AM, Chris Angelico wrote:

wxPython currently runs only with Python2, not Python3. There
is a drag-and-drop form designer available for it but it is a
commercial product that costs money. It also comes with a
useable (once you get used to it) form builder tool that works
by graphically manipulating a text tree of widgets.

Development versions which support Python 3 are available here
http://wxpython.org/Phoenix/snapshot-builds/ Unfortunately they've not
been updated since 3rd December. I've asked why and been told that
Robin Dunn is simply too busy. There's Open Source for you :)
Chris and some other people here dislike Google Groups and
try to imply that everyone here feels the same way. Not true.

I and many other people here use Google Groups and have been
doing so for years so if Google Groups works for you, please
feel free to continue using it.

If you want to reduce the noise level from people like Chris
you might want to take a look at:

https://wiki.python.org/moin/GoogleGroupsPython

Of course I dislike Google Groups, users keep sending double spaced crap
which I don't want to see. There is no "noise level" from people like
Chris, which obviously includes me. There is a constant stream of
polite requests not to send double spaced crap which we do not wish to
see. There are at least two solutions to this, follow the instructions
in the link repeated above for the umpteenth time or use a different tool.
 
M

Michael Torrie

Tkinter is a bit "special" to use since it's not just a library, but
uses some kind of RPC. It seems that "look and feel" have been greatly
improved lately.

I know Tkinter originated with the Tcl/Tk language. With Tkinter in
Python is it still using Tcl/Tk under the hood? IE embeds the Tcl
language interpreter into Python's interpreter? If so I've always found
it a bit strange that the de facto GUI library that's shipped with
Python ships an entirely different language with it under the hood.
 
M

Michael Torrie

PyQt looks native everywhere, but it might be a bit overweight,
depending on what you want to do and where your applications need to
run.

And then there's the licensing issue, since PyQt, unlike Qt itself, is
not available under LGPL afaik. For closed-source commercial
applications, there seems to be a way to use a commercially licensed
PyQt (much less expensive than Qt itself) together with LGPL-Qt
however. Pyside would be a LGPL alternative to PyQt, but it doesn't
seem to be as up-to-date as PyQt.

I think PyQt is slowly being pushed aside in favor of PySide, which is
more license-friendly for use in closed or open projects. I would
recommend using PySide unless PyQt is a requirement for your project.
 
M

Michael Torrie

The other big, widely-used GUI toolkit is PyQt. It runs on
both Python2 and Python3. There is another version of it
called PySide which is API compatible with PyQt but has
different licensing terms. PyQt comes with a very good
drag-and-drop form designer.

Just to be clear, PyQt does not provide the drag and drop form designer.
That comes from QtDesigner or QtCreator, which is part of Qt itself and
you can use it to design GUIs for use in any language that Qt has
bindings for, not just Python. PyQt probably does come with a code
generator to convert the xml GUI definitions into Python, but these days
such use is discouraged in favor of using Qt itself to load the XML file
at runtime and build the objects on the fly for you. It's way more
flexible and there's no code generation needed. (Apple has done this
for years with Cocoa with their nib files in the bundle.)
I have played a little with both wxPython an PyQt and found
learning to use them from the web difficult because of their
size and complexity. But both of them have pretty good books
about them available:

Yes there are concepts you'll have to wrap your brain around such as how
to do proper widget layout. Things aren't placed in a fixed way
usually. They are allowed to grow and shrink with the window size. And
you will have to grasp how events work.

Of all the APIs I've used, I think GTK in Python is the cleanest (PyGTK
or PyObject). But if I was targeting Windows or Mac I'd stick with
PySides/PyQt.
 
N

Ned Deily

Michael Torrie <[email protected]> said:
I know Tkinter originated with the Tcl/Tk language. With Tkinter in
Python is it still using Tcl/Tk under the hood? IE embeds the Tcl
language interpreter into Python's interpreter?

Yes, it does.
If so I've always found
it a bit strange that the de facto GUI library that's shipped with
Python ships an entirely different language with it under the hood.

It is a bit strange but, back in the day, there wasn't a better multi-platform
GUI option and, even today, Tk (and Tcl) remain attractive because it is
supported on the many important platforms and does not have the license issues
that some other GUI toolkits have had. And because of inertia. Also, Python
is not alone in this: Perl and Ruby also have Tk bindings that work the same
way, AFAIK.
 
T

Terry Reedy

I know Tkinter originated with the Tcl/Tk language.

Tcl is the language. Its standard interpreter is written in C, as with
Python. (I do not know if there are other Tcl implementations.) Tk is
the gui framework written, I believe, in a mixture of Tcl and C.

Tkinter (Tk interface) is entirely a Python to Tcl/Tk and back interface.
With Tkinter in Python is it still using Tcl/Tk under the hood?

Yes. _tkinter.c defines Python-callable functions that call Tcl/Tk C
api functions. tkinter.py defines Python classes and methods. The
methods call _tkinter functions. Most of the classes correspond to Tk
widgets such as Button and Text.
IE embeds the Tcl language interpreter into Python's interpreter?

Both interpreters run in one process.
If so I've always found
it a bit strange that the de facto GUI library that's shipped with
Python ships an entirely different language with it under the hood.

Tcl/Tk is only shipped with the Windows Python installer. On other
systems, it is a separate install if not already present.

There once (over 10 years ago) was a project to re-write Tk entirely in
C. What I read it that people decided that Tk made too much use of Tcl
functions to make that worthwhile.

There have been starts on projects to write a gui framework based on
Python and wrapped C libraries. PyGui is one, last updated July 2011.
http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/
 
S

Steven D'Aprano

I know Tkinter originated with the Tcl/Tk language. With Tkinter in
Python is it still using Tcl/Tk under the hood? IE embeds the Tcl
language interpreter into Python's interpreter? If so I've always found
it a bit strange that the de facto GUI library that's shipped with
Python ships an entirely different language with it under the hood.

That's just the "Interpreter" design pattern, except the Domain Specific
Language is already written for you :)

(I'm half-serious here.)

But more seriously, 100% seriously in fact, I think that you'll find that
*every* GUI framework for Python ships with an entirely different
language under the hood, usually C. Even if the top level of the
framework is written in Python, the underlying graphics routines used for
drawing controls and windows will surely not be. Given that the actual
maintenance of the GUI itself is unlikely to be a bottleneck in any real
application, I don't think it is a significant problem efficiency-wise
that Python tkinter relies on an intermediate framework written in Tcl.
 
G

Grant Edwards

But more seriously, 100% seriously in fact, I think that you'll find that
*every* GUI framework for Python ships with an entirely different
language under the hood, usually C.

Name one GUI framework that ships with a C implementation.
Even if the top level of the framework is written in Python, the
underlying graphics routines used for drawing controls and windows
will surely not be.

You seem to be equating "was compiled from" with "includes an
implemenation of". Do you say that CPython "ships with C"?
 
W

Wolfgang Keller

I think PyQt is slowly being pushed aside in favor of PySide, which is
more license-friendly for use in closed or open projects. I would
recommend using PySide unless PyQt is a requirement for your project.

Except the issue that Pyside always seems to lag a bit behind Qt
releases, while PyQt usually supports more recent releases of Qt.

Besides that, according to what I've been reading on the PyQt mailing
list, support is impressive. The developer often fixes issues over
night, if there actually are any. And besides, again, a commercially
licensed PyQt itself isn't *that* expensive.

Sincerely,

Wolfgang
 
S

Steven D'Aprano

Name one GUI framework that ships with a C implementation.

Er, all of them? I daresay that Tcl itself eventually calls graphics
routines written in C. There's not that many languages that commonly get
used for low-level graphics routines, but C is one of them.

If you mean, ships with a C *compiler*, or even a C interpreter, then no,
probably not. But it wouldn't surprise me if some of those GUI frameworks
are powerful enough to count as mini-languages in their own right.

You seem to be equating "was compiled from" with "includes an
implemenation of". Do you say that CPython "ships with C"?

Well, when you take my comments out of their context, that does seem to
be a totally stupid thing to say. But in context, it's only *mostly*
stupid, and mostly stupid means a little bit sensible *wink*

The context was a complaint, or at least expression of surprise, that
Python use Tcl for a GUI, this being contrasted with (paraphrasing the
legions of people who have expressed surprise about this in the past)
"some hypothetical GUI written in Python". But in practice, it won't be
written in Python, it will be likely written in C or some other low-level
language with some interface to Python. The main difference between this
hypothetical "Python GUI" and Tcl is that Tcl is a Turing-complete
interpreter which lives in it's own process.

[Aside: I wonder how many other GUI toolkits are Turing complete?]

As I stated earlier, this is just the Interpreter design pattern, with
the minor complication that the domain specific language happens to be an
existing language, Tcl, with an interpreter that usually runs in a
separate process, instead of some mini-language running inside Python.

So I don't see anything surprising about Tkinter (or for that matter,
Ruby and it's bindings to Tcl/Tk). Maybe it's because I'm used to Unix/
Linux systems, where it is common for tools that execute in one
interpreter to call other tools which execute in a different interpreter.
E.g. a shell script which calls a Ruby script which calls some command
which happens to be written in Python. Python, after all, was originally
invented to be a glue language, and I don't really see anything weird
about Python delegating work to Tcl any more than I see anything strange
about IronPython delegating work to the .Net runtime.
 
M

Michael Torrie

Except the issue that Pyside always seems to lag a bit behind Qt
releases, while PyQt usually supports more recent releases of Qt.

Which is a bit odd, seeing as Pyside is an official Qt project. It was
started by Nokia when they owned Qt, and now is hosted at the official
Qt web site.
Besides that, according to what I've been reading on the PyQt mailing
list, support is impressive. The developer often fixes issues over
night, if there actually are any. And besides, again, a commercially
licensed PyQt itself isn't *that* expensive.

That's good to know.
 
C

Chris “Kwpolska†Warrick

And besides, again, a commercially licensed PyQt itself isn't *that*
expensive.
The cost of a commercial PyQt license for a single developer is £350
(GBP). You may pay in either US Dollars, Euros or GBP.

(£420 incl. VAT for UK and select EU entities)
one [license] per developer

For some people, it might be a lot. Why waste money on something,
that has an almost-identical free-for-everyone version? (which also is
easier to install, BTW)
PyQt does not include Qt itself. You must also obtain an
appropriately licensed copy (either the commercial version from
Digia or the LGPL version from the Qt Project).

So, you have four options:

a) use PySide and Qt@Project, pay $0 and be sane (albeit saner than
person B);
b) use PyQt4 and Qt@Digia, pay £350/£420 + £??? and be sane;
c) use PySide and Qt@Digia, pay £??? and look like a hypocrite (albeit
less than person D);
d) use PyQt4 and Qt@Project, pay £350/£420 and look like a hypocrite.

DISCLAIMER: Some things are based on assumptions, many of which may be
incorrect.

PS. For those living in the past without proper Unicode support: £ =GBP.
 
M

Mark Lawrence

(£420 incl. VAT for UK and select EU entities)

Four weeks income, no thanks :(
one [license] per developer

For some people, it might be a lot. Why waste money on something,
that has an almost-identical free-for-everyone version? (which also is
easier to install, BTW)
PyQt does not include Qt itself. You must also obtain an
appropriately licensed copy (either the commercial version from
Digia or the LGPL version from the Qt Project).

So, you have four options:

a) use PySide and Qt@Project, pay $0 and be sane (albeit saner than
person B);
b) use PyQt4 and Qt@Digia, pay £350/£420 + £??? and be sane;
c) use PySide and Qt@Digia, pay £??? and look like a hypocrite (albeit
less than person D);
d) use PyQt4 and Qt@Project, pay £350/£420 and look like a hypocrite.

DISCLAIMER: Some things are based on assumptions, many of which may be
incorrect.

PS. For those living in the past without proper Unicode support: £ = GBP.

Thanks for making my day, I've roared with laughter at the PS.
 
C

Chris Angelico

As I stated earlier, this is just the Interpreter design pattern, with
the minor complication that the domain specific language happens to be an
existing language, Tcl, with an interpreter that usually runs in a
separate process, instead of some mini-language running inside Python.

Yeah, but there's a difference between passing your GUI incantations
on to a library function (written in C but now just part of a binary
library) and feeding them to a completely different language
interpreter. When I write something with PyGTK, I can't, even in
theory, give it arbitrary C code to execute. From what I understand
here, that *is* true of Tcl, which means that the Python download
contains a Python interpreter and a Tcl interpreter. I'm not saying
that's a bad thing to do, but it is calculated to provoke remark.

ChrisA
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,733
Messages
2,569,439
Members
44,829
Latest member
PIXThurman

Latest Threads

Top