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

[Christian Gollwitzer]

Am 16.12.13 23:40, schrieb Chris Angelico:
> On Tue, Dec 17, 2013 at 9:06 AM, Christian Gollwitzer <auriocus at gmx.de> wrote:
>> Let the flame war begin!
>
> I'll try to avoid flamage :)

:) So let's vigorously discuss about facts;)

> But my rule of thumb with bash scripts is: If it exceeds a page or
> two in length, it's probably time it got rewritten in an application
> language. When a program is the size of gitk (>10KLOC), the benefits
> relating to interactive use (as you mention below) become less
> significant, and benefits relating to discoverability of the more
> obscure features become more significant.

I do not know, whether bash has means to structure large programs, I 
suppose not. Tcl has (see below), and concerning discoverability, see 
also below.

>> It does command substitution (indeed the brackets [] do) and is one of the
>> key concepts of Tcl. mc is probably the command from msgcat which translates
>> i18n strings. Complaining about these basic things is like complaining about
>> indentation in Python.
>
> Okay. Now, how am I to figure out where this command comes from? It's
> not a host command (typing "mc" at the bash prompt comes up failure),
> and it's not defined in the script itself (at least, I can't find
> "proc mc" anywhere); is it a Tcl built-in? Where do I start looking?

Usually, I run the program in tkcon, an excellent interactive shell for 
Tcl. There you type "edit mc", and it shows you the definition, plus you 
can change it, send it back to the program and see how the modified 
program behaves now (without restarting it!) Under the hood, it executes 
commands like "info commands", "info args", "info body", which do the 
work. If it tells you that there is no such thing as "mc", it came from 
a compiled extension (a C procedure). Indeed, in this case you are out 
of luck, to my knowledge there is no info which extension loads that 
thing. But you could observe it before startup by putting up a command 
trace (some sort of callback) on "mc".

In the gitk case, mc comes from these lines:

	package require msgcat
	namespace import ::msgcat::mc

Now, be prepared: These lines do almost the same as

	import msgcat
	from msgcat import mc

would do in Python.

*What is this? I heard Tcl has no modules?* Don't listen to these 
people, today (well, namespaces exist since 8.0, 1997, packages date 
back further) you can use namespaces and packages to structure your 
programs and separate data. And because Tcl is highly introspective, you 
can ask about almost everything:

(src) 61 % namespace import
mc
(src) 62 % namespace origin mc
::msgcat::mc
(src) 63 %

(there is only one imported command in gitk, namespace import returns a 
list)


About globals: Yes "global" gives you a true global, but namespaces have 
namespace variables, which you should use instead. The awkward thing is 
that you need to import these (as the globals) into every proc which 
uses them, but by using an OO framework such as Snit, this burden is 
taken away from the programmer.

Still Python *has* advantages here. If there is a docstring, you can get 
help() about the unknown thing, it has a type() and in Tcl, the package 
author is responsible for wrapping the package content into a namespace. 
Something like "import Tkinter as Tk" is not possible in Tcl (well, you 
could rename the namespace, but if not carefully written, it may break 
the package).

>> * Interpreters in threads. There is no GIL, Tcl interpreters are thread safe
>> and more than one can coexist in a process and run concurrently. This is
>> accessible from script level through the Threads package.
>
> Nice, though Python's threading and/or multiprocessing can do 90% of
> what people want. Side point: What about Tk? Can you (a) run separate
> GUI threads for separate windows? (b) manipulate widgets created by
> another thread?

You can't run Tk more than once, that applies to almost every toolkit I 
know. But you can pass a message to the main thread to do it for you. 
This is quite easy; it looks like

thread::send -async $main [list doit $somedata]

You pass an arbitrary Tcl command which executes in the main thread as 
soon as it is idle. In fact, because of the embedded event loop in Tcl 
(not bound to Tk), you rarely need threads at all. Asynchronous I/O is 
very easy in Tcl (fileevent command).

That one question here with replicating nc to control a device would be 
a textbook example of fileevent usage in Tcl.

> So there definitely are some advantages that Tcl has over Python. Put
> against them is a superior object model, a large corpus of first-class
> object types (dict, set, list, etc[1]), and a syntax that more clearly
> differentiates names and strings without making variable references
> look like a lot more than they are.

Lists and dicts exist in Tcl as first class objects. You just can't tell 
them apart from strings. Sets are in tcllib. Python is more strongly 
typed than Tcl in that respect, which can be an advantage. Specifically 
doing math is easier in an evaluation based syntax than in a command 
based syntax, this sometimes sucks in Tcl.

> Huge room in the world for both languages to exist and thrive.

Yes, you name it. I wish people who criticize Tcl would not use their 
knowledge from 15 years ago; that beast has evolved. I'm not complaining 
about Python 1.0 either. And I wish Tcl would be used more often for 
large-scale programs, such that the idioms really develop.


	Christian

> [1] What is an etc() in Python?

Is this a quizzy question? I have no idea.