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

[Tamer Higazi]

For wxPython there is a good book.
You will feel convinient.


But to be honest, I don't believe that Python is the best choice for GUI
development, but it's only an opinion.
Otherwise I would advise you going into C++ and code with wxWidgets.


Tamer

 

[Mark Lawrence]

But to be honest, I don't believe that Python is the best choice for GUI
development, but it's only an opinion.
Otherwise I would advise you going into C++ and code with wxWidgets.

Tamer

Can you state why you prefer C++ and wxWidgets over Python and wxPython,
which wraps wxWidgets?

 

[Tamer Higazi]

Hi Mark!

It is an advise, in which language somebody wants to code is of course
everybodys free choice.

However, I believe according wxWidgets it would be better coding in the
native language the system had been developed.
The other thing, specially if you would make a customer project, I don't
know how to pack the app written in python in an installer. Perhaps I am
wrong, and you could give me in exchange an advise ?!

I also believe in performance. An application written in C++, can be
compiled easily on the target platform (like on windows systems) with
it's native compiler.
How would it be with wxPython ?!


Thanks for your response



Tamer

 

[Michael Torrie]

For wxPython there is a good book.
You will feel convinient.


But to be honest, I don't believe that Python is the best choice for GUI
development, but it's only an opinion.
Otherwise I would advise you going into C++ and code with wxWidgets.

Perhaps this is because the wx binding in Python is too C++-like and
lacks python concepts and idioms? Or are you saying Python in general
is not a good language for GUI development?

GUI design is moving firmly into the realm of interpreted or
non-compiled languages, with compiled languages often doing the real
back end work. For example Firefox implements its entire GUI in
Javascript using XML GUI definitions. This all drives a C-based
rendering engine. Also Qt 5 emphasizes developing GUIs using QtQuick,
which is also Javascript-based with XML and CSS for styling. And all
modern web apps are a combination of many languages and domains, most of
which are "compiled" in the traditional sense.

I think Python is a great overall application development language,
especially for the GUI. First-class functions for callbacks make it
very nice compared to other languages. Python is fast enough for
full-blown apps too. Slow parts can be factored out to other languages.

 

[Michael Torrie]

However, I believe according wxWidgets it would be better coding in the
native language the system had been developed.
The other thing, specially if you would make a customer project, I don't
know how to pack the app written in python in an installer. Perhaps I am
wrong, and you could give me in exchange an advise ?!

Nonsense. That's what an installer on windows is for, or what a package
on Linux is for. There are also ways to bundle up everything you need
to run a Python app in a single exe file.

Ever take a look at the e-book manager, Calibre? It's 90% Python. You
can install it on Windows like any other app. If you're curious as to
how they do things, you can always contact their developers.

I also believe in performance. An application written in C++, can be
compiled easily on the target platform (like on windows systems) with
it's native compiler.
How would it be with wxPython ?!

It would probably perform just fine. Anything that can't get enough
speed to run in Python can easily be delegated to native libraries or
subroutines.

 

[Michael Torrie]

And all modern web apps are a combination of many languages and
domains, most of which are "compiled" in the traditional sense.

^^^^^^^^^^^^^^^^^^^^
Meant to say, *not* compiled.

 

[Chris Angelico]

I also believe in performance. An application written in C++, can be
compiled easily on the target platform (like on windows systems) with it's
native compiler.
How would it be with wxPython ?!

It's going to spend more than 99% of its time waiting for the user.
Most applications aren't performance-bound. Over the past few years, I
can think of *one* case when my GUI program was actually saturating a
CPU core and I had to dig into a performance fault; the simplistic
design had meant that it would iterate over an entire list of strings
to find which ones it needed to draw, and once that list got huge, the
redraw operation started taking time. But there was no visible problem
except when the app was redrawing itself many times a second in
response to user action AND the set of strings got, as I said, huge.
Every other part of that program, and all of every other GUI
interactive program I've written in recent years, has been coded for
simplicity and not for performance. (This particular example is
actually quite pertinent, as it's the "designated replacement" for a
very similar program written in C++. The C++ one has a tendency to
crash hard if user code does the wrong thing, as there is absolutely
no protection anywhere, while the new code will, at very worst, spew a
traceback and then go back to processing events.)

Of course, performance is a relative thing. If you're running on a PC,
there's no difference at all between taking 1ms and taking 2ms - no
human will notice. But if you're running on a server, that's the
difference between 1000tps and 500tps. And on a phone, that CPU usage
might have an impact on battery life, and running on a tiny PCB the
same coding difference might be the difference between 400ms and
800ms. But in the day-to-day realm of desktop apps, maintainable code
will always be better than marginally faster code.

ChrisA

 

[Chris Angelico]

I think Python is a great overall application development language,
especially for the GUI. First-class functions for callbacks make it
very nice compared to other languages. Python is fast enough for
full-blown apps too. Slow parts can be factored out to other languages.

Python is sooooooo slow when it waits for the human. That pesky
input() function can take *minutes* to return. It's terrible! Factor
that out and your job's done.

And yeah. First-class functions *rock*. ECMAScript is almost there -
not supremely, perhaps, but oh so "all-but"! [1] A function can retain
all sorts of state by being a closure, and yet somehow it doesn't
retain the state of which 'this' (in Python terms, 'self') it should
reference. Why? I don't know. But it's part of the spec now, so
callbacks have to take a function and a context.

var func=document.getElementById;
var foo=func("foo"); /* Won't work */

function funcgen(obj)
{
return function(desc) {return obj.getElementById(desc);}
}
var func=funcgen(document);
var foo=func("foo"); /* Will work! */

In Python, the simple and obvious thing works, because there's less
magic. The incantation "obj.member" followed by the incantation
"callable(args)" has exactly the same meaning as "obj.method(args)".

ChrisA

[1] http://math.boisestate.edu/gas/patience/webop/pat16d.html

 

[Jeremy Sanders]

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.

That's not the impression I get from the PySide mailing lists. Work seems
slow now everyone is a volunteer. For example, Qt 5 is not yet supported
(there's no effort towards this according to the mailing list) and bugs seem
to take a long time to be fixed. PyQt support is much better, even when I'm
using it for a free project.

Jeremy

 

[Mark Lawrence]

Python is sooooooo slow when it waits for the human. That pesky
input() function can take *minutes* to return. It's terrible! Factor
that out and your job's done.

I've done the latter, but still can't fit all the data for my 100+
screens into a one liner, help please

 

[Mark Lawrence]

With 100 screens, you should be able to use lines of text up to 8000
characters long - just make sure your screens are organized
horizontally. Shorten all variable names to a single letter, omit all
unnecessary spaces, and you should be able to fit the code within that
space.

ChrisA

Thanks for this extremely useful advice, it's much appreciated

 

[Kevin Walzer]

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.

Yes, a Tkinter app has both a Python interpreter and an underlying Tcl
interpreter. Let's be clear about that.

The technical reason for this is that, during Python's early
development, Tk was the simplest, most powerful and OSS-friendly GUI
toolkit out there (compared to, let's say, Motif). Its reliance on Tcl
was a plus because Tcl's C API is exceptionally clean and easy to
embed/call from other C libraries (that was Tcl's original main focus,
embedding in C).

Embedding the Tcl interpreter remains a sound decision today. It makes
it trivial to keep Tkinter updated in sync with Tk updates, since the
Tcl interpreter does most of the heavy lifting. The recent effort to
wrap Tk's new themed widgets is a good one: nearly all of the work was
done at the Python level. Compare this approach to Perl's original one,
which stripped out Tcl and implemented Tk integration entirely in C. Any
updates require heavy lifting in C and, in fact, Perl/Tk has not kept up
with Tk's main line of development (it does not run natively on the Mac,
for instance).

Calling through Tkinter to Tcl also provides some other conveniences. If
you're writing a Tkinter app and want to access some platform-specific
functionality that requires C calls, that may require a library
extension written against Tcl/Tk's C API (i.e. the Mac's NSServices
API--that can't be accessed using ctypes because it hooks into the
window server). Fortunately, Tk is very easy to extend in C--much
simpler than extending wxWidgets or Qt.

Finally, Tcl is itself a fully-featured, general programming language
that is a peer to Python both generationally and in terms of its
capabilities; the main way it lags is in the size of its development
community. In other words, you are not handing the ball off to a
90-pound weakling if you need to call into Tcl from Python via Tkinter. ;-)

--Kevin

 

[Chris Angelico]

Finally, Tcl is itself a fully-featured, general programming language that
is a peer to Python both generationally and in terms of its capabilities;
the main way it lags is in the size of its development community. In other
words, you are not handing the ball off to a 90-pound weakling if you need
to call into Tcl from Python via Tkinter. ;-)

Having made a tweak to gitk at one point, I have to say Tcl is
definitely inferior to Python. I'd much rather work with Python
itself.

ChrisA

 

[Kevin Walzer]

Having made a tweak to gitk at one point, I have to say Tcl is
definitely inferior to Python.

Without starting a flame war, can you elaborate? I'm curious about your
perspective.

(I studied PSL--Python as a Second Language--so develop in it with a
slight accent. I'm a native Tcl developer, for better or worse.)

--Kevin

 

[Chris Angelico]

Without starting a flame war, can you elaborate? I'm curious about your
perspective.

(I studied PSL--Python as a Second Language--so develop in it with a slight
accent. I'm a native Tcl developer, for better or worse.)

Here's the Tcl procedure that I tweaked. This is from gitk; I find the
word diff not all that useful, but a character diff at times is very
useful. I haven't found a way to configure the word diff regex through
gitk's options, so I tweaked it in the source code.

proc getblobdiffs {ids} {
global blobdifffd diffids env
global diffinhdr treediffs
global diffcontext
global ignorespace
global worddiff
global limitdiffs vfilelimit curview
global diffencoding targetline diffnparents
global git_version currdiffsubmod

set textconv {}
if {[package vcompare $git_version "1.6.1"] >= 0} {
set textconv "--textconv"
}
set submodule {}
if {[package vcompare $git_version "1.6.6"] >= 0} {
set submodule "--submodule"
}
set cmd [diffcmd $ids "-p $textconv $submodule -C --cc
--no-commit-id -U$diffcontext"]
if {$ignorespace} {
append cmd " -w"
}
if {$worddiff ne [mc "Line diff"]} {
append cmd " --word-diff=porcelain --word-diff-regex=."
}
if {$limitdiffs && $vfilelimit($curview) ne {}} {
set cmd [concat $cmd -- $vfilelimit($curview)]
}
if {[catch {set bdf [open $cmd r]} err]} {
error_popup [mc "Error getting diffs: %s" $err]
return
}
set targetline {}
set diffnparents 0
set diffinhdr 0
set diffencoding [get_path_encoding {}]
fconfigure $bdf -blocking 0 -encoding binary -eofchar {}
set blobdifffd($ids) $bdf
set currdiffsubmod ""
filerun $bdf [list getblobdiffline $bdf $diffids]
}

First off, everything's done with commands, rather than assignment
("set diffinhdr 0"), which is very shell-style and not very
programming-style. Can live with that, though even shells can use
equals signs for simplicity. Similarly, the shell style of adorning
variable usage feels messy. There are string literals, some of which
contain interpolated variables; there are dollar-sign adorned
variables; and then there are other words. What are the other words?
Are they implicit strings (as they would be in, say, bash)? I've never
really liked that style. Anyway. Can get past that.

Secondly, what does this do?
if {$worddiff ne [mc "Line diff"]}

I *think* it means 'if $worddiff is not equal to "Line diff" (this
code is executed for the options "Markup words" and "Color words", but
what's the mc do? How am I supposed to figure out what it does? Where
do I begin to look?

This is where, IMO, Python tends to be a lot clearer. It's easy to see
what's an object and what's a method on it, and every bare word is
either a local name or a standard built-in name. I'm sure Tcl's a
great language, but I'd rather not have to drop out of Python into it
if I can help it.

ChrisA

 

[88888 Dihedral]

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

Please check JYTHON and those
ready-for-novice GUI tools in java.

Python is a higher level language
that can support manny lower
level languages.

 

[Grant Edwards]

I wrote a few Tcl apps once many, many years ago. After attempting to
write something more than a few hundred lines long, I gave up and
swore off Tcl completely. I switched to Scheme, and later to Python.

The things I found infuriating about Tcl:

* The "everything is a string" view of the world is severly
limiting if you're not just processing strings.

* The quoting syntax and semantics appears to have been invented by
somebody at the CIA as a way to torture programmers into doing...
something... I don't know what.

* Tcl doesn't seem to have any sort of coherent design or philosophy
behind it but rather consists of a bunch of hacks piled on top of
a simple and limited shell-like string processing language. It
sort of feels like PHP in that regard.

When I finally gave up fighting with Tcl's quoting semantics half way
through a medium/small application and switched to Scheme/Tk, I had my
app written from scratch in a fraction of the time it took to get
about half way done in Tcl, and with about 1/3 the lines of code.

Python probably would have cut both hours and lines by half again
compared to Scheme.

 

[Chris Angelico]

* The "everything is a string" view of the world is severly
limiting if you're not just processing strings.

I wasn't sure if that was the case, from what I was seeing. Are there
any aggregate types at all?

ChrisA

 

[Grant Edwards]

I wasn't sure if that was the case, from what I was seeing. Are there
any aggregate types at all?

There are arrays with string keys (similar to Python dictionaries).

 

[Gregory Ewing]

There are arrays with string keys (similar to Python dictionaries).

Well... sort of. They can only hold strings, not other arrays.
They're not first-class entities: you can't pass them around
or keep them in local variables; they're always global. (And
there are no modules, so global is *truly* global.)

In short, they're a very poor substitute for having real data
structures.