Jason Heeris wrote:
> On 5 July 2010 17:36, A.T.Hofkamp <a.t.hofk...@tue.nl> wrote:
>> Or you could drop threads entirely, and do your async activities using the
>> Twisted framework, designed for making asynchronous programs (where GTK
>> event handling is just one of the asynchronous sources).
> 
> Please don't take this as a flame, but I've had this advice before
> (usually on #python), and I usually go through this process:

I was mostly triggered by the fact that you are doing asynchronous activities 
next to the GTK 
application, which are apparently complicated enough to use threads for.


> 1. Look at Twisted website
> 2. Only read things about twisted being a networking framework

Network communication is *by* *far* the most complicated form of asynchronous 
communication 
(anything can go wrong at any moment). Obviously, a framework for asynchronous 
communication should 
put the focus there.

About not mentioning guis:
If you write a spread sheet program, and explain its features, you don't 
explain that you can add 
two numbers, do you?

> 3. Someone corrects me, saying "Twisted is so much more!" (That may be
> the case, but the fact that the website goes on and on without
> mentioning this does not inspire confidence.)

Twisted is technically very good, but their PR is not, let's say, optimal.

Combined with the (at first) twisted way of doing things (namely event-based 
programming in the 
extreme), you are looking at a very steep learning curve.

I completely agree with you that this is a weak point.
I found the best source of information to be their howtos and 
tutorials/examples, to get the global 
picture, and the API documentation (for the protocols, mostly).

> 4. I search the Twisted website for documentation on/examples of GTK
> applications

Basically, asynchronous communication means you are doing event-based 
programming everywhere.

You are constantly waiting for something of interest to happen (the Deferreds 
in Twisted-speak). 
When the event does happen, the handler is triggered, which handles the event, 
and sets up new 
Deferreds (new handlers) for new events that may happen.

 From this point of view, it is totally irrelevant what event you get (a 
network comm event, a GUI 
event, or something from another source), only the actual handler of the event 
needs to know details 
of the event.
The Twisted main-loop (reactor) only needs to know that it should watch for 
GTK+ events too, so you 
need a gtk2reactor instead of a normal one.

See also

http://twistedmatrix.com/documents/current/core/howto/choosing-reactor.html#auto11

That page also refers to an example "doc/core/examples/pbgtk2.py"


 From a complexity point of view, there is very little that can go wrong with 
event handling in a 
GTK gui, so little need to discuss things at length.


> 5. I give up and search the Twisted website for documentation
> on/examples of *any* non-network based applications

As I tried to explain above, to Twisted *everything* is an event that is waited 
for, and when it 
happens, it should be handled.

There is no difference between network-based events and non-network-based 
events. They are all done 
using Deferreds that fire when the event happens.

In the same way, Twisted does not care about the comm protocol use to deliver 
the event. Whether a 
user pressed a button at a web-form, or sent a IRC message does not matter for 
computing the response.

> 6. I give up and search the greater web for documentation on/examples
> of Twisted GTK applications
> 7. I give up on Twisted and find another way.
> 
> Really, I would love to get a grip on Twisted. It seems really useful.
> But I've still not found any kind of stepping stone into it. Please,
> please, please if you know of one, post it so I can add another tool
> to my belt. I will rescind everything I've said here and then some.

I'd recommend to get to grips with the Deferreds using a communication protocol 
example, as those 
are around. Once you get how events are done, apply it to gtk events.

> (Since the Twisted website is currently down, I can't tell if things
> have changed and I should get over it and have another try.)

It's up again (or was, at least). It has not changed much, at first sight.

I am not sure why there is so little nice introductory information. I think it 
is because the gap 
between both worlds is so big. Either you don't get it, and then you cannot 
write about it due to 
lack of understanding, or you do get it, and then you cannot imagine how to 
explain it to somebody 
that doesn't.

(Like programming, can you explain the essence of what programming is, to 
somebody that has no clue 
about computers?)

Albert
_______________________________________________
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Reply via email to