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

[Chris Angelico]

On Tue, Dec 17, 2013 at 8:33 PM, Christian Gollwitzer <auriocus at gmx.de> wrote:
> Am 16.12.13 23:40, schrieb Chris Angelico:
>> 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.

You can create functions, which then effectively become new commands.
You can source (the . command) another file, which mostly is a
#include style of thing. But mainly, a bash script is doing exactly
what would happen at the interactive shell (modulo environment
differences - your interactive shell might well have a different $PATH
or something, but command execution still follows the same rules). If
I look at a bash script and see it execute "bc", I can type "man bc"
and have a reasonable chance of it being the same thing.

> 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.

Okay. Now that you've told me that, I can find those lines... down the
very bottom of the script. The first thing I did when trying to figure
this out was to go to the top of the file and search for "mc", and I
didn't find a definition.

In Python, it's conventional to put imports at the top, so this would
have worked. (Unless there's a "from x import *", but this is
precisely why that's frowned upon.) Is the convention different in
Tcl, or is gitk just laid out unhelpfully?

> 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]

Everything I ever did on OS/2 allowed GUI operations from multiple
threads. The C APIs, I think, were restricted to manipulating each
widget from the thread that created it (or at least, you could confuse
yourself thoroughly if you didn't; I always just stuck to "this
window, this thread"); VX-REXX allowed any thread to manipulate any
object belonging to that process. If you send a message to a widget,
its thread will handle it (and yours will block until you get a
response - or you can post a message, which doesn't block); this
functions the same whether it's a thread in your process or one in
another process.

> 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).

I learned to love async processing a couple of years ago with Pike.
You just return a negative number from main(), which normally has no
meaning, and it goes into a back-end event loop. (And there are other
ways to invoke the back-end.) That can then handle callbacks from
files/sockets, clock-based timeouts ("call this function in X
seconds"), GUI events, pretty much everything (except signals - they
interrupt everything else, as they should). It takes a bit of getting
your head around, if you're used to thread-based programming (as I had
been for a decade or so), but it's so convenient.

>> 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.

>> [1] What is an etc() in Python?
>
> Is this a quizzy question? I have no idea.

I mentioned four of Python's fundamental types: the dict, the set, the
list, and the etc. :)

> 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.

Having grown up with REXX, I completely understand the concept of
"everything is a string" (though REXX does have compound variables,
which aren't quite lists, aren't quite dicts, and aren't quite sets,
and definitely aren't quite multidimensional anything, but are their
own beast with unique semantics); and having since met Python and Pike
and other such languages, I prefer object semantics. The only
first-class type in REXX is the string; a compound variable is a
different sort of name, not a different sort of value, so you can't
actually pass an array as an argument. What you have to do is pass the
_name_ of the compound variable, so it's a lot fiddlier.

>> 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.

That's true of every language, but sometimes the community adopts
habits based on the early versions and those habits don't change.
Coding styles and best-practices are nearly as much a part of the
language ecosystem as semantics and standard library - a typical Ruby
application has piles and piles and PILES of dependencies (gems),
whereas a typical Python program will need maybe just a couple of
non-standard modules. Is that a fundamental difference between the
languages? Unless the Ruby standard library is positively minimalist,
I don't think it is. It's just the way the community works... which
changes very, very slowly. Maybe in 2015 there'll be a version of Ruby
with a hundred times as much in its stdlib as the current versions
have, but people will still use their favorite gems, because they're
used to them. Python programs will still tend to have shorter chains
of dots in their method calls than Java programs will have, even if
Python were to get compile-time lookups. C programs will still tend to
crash, even if C gets a refcounting garbage collector... hmm, that
one's already happened, and yep, still true. :)

ChrisA