Hi,
I've been reading some conflicting advice on PyGTK and threading
recently, probably because the API went through some fairly rapid
changes recently.
I'm a bit confused about the following points (consider them in
context of PyGTK/PyGObject unstable, ie. 2.17/2.21 respectively):
1. If I
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
Il giorno lun, 05/07/2010 alle 16.32 +0800, Jason Heeris ha scritto:
Hi,
I've been reading some conflicting advice on PyGTK and threading
recently, probably because the API went through some fairly rapid
changes recently.
I'm a bit confused about the following points (consider them in
Hello,
I agree with that wholeheartedly. I typical code in 3 or 4
languages and the other languages I use (C#, Java, etc) just have threads
which are easy to use. When I was told to use twisted I looked at the
website and though 'phew that is a lot to learn'. I was then about to drop
On 5 July 2010 18:05, Neil Benn neil.b...@ziath.com wrote:
I persevered however and threads work fine in Python - OK the GIL can make
things a little more complicated but threading in Python is not much harder
to use then in Java or C# (in fact because of the GIL and single processor I
don't
Ok, I found the solution (thanks to help from Tadej Borovšak on
gtk-app-devel-list):
I had to call textview.set_size_request(0, 0), so now the textview
doesn't request space for all its contents.
Noam
On Sun, Jul 4, 2010 at 3:45 PM, Noam Yorav-Raphael noamr...@gmail.com wrote:
Hello,
I would
Il giorno lun, 05/07/2010 alle 18.09 +0800, Jason Heeris ha scritto:
On 5 July 2010 17:53, Pietro Battiston m...@pietrobattiston.it wrote:
Apart from 2.c, I guess
http://faq.pygtk.org/index.py?file=faq20.006.htpreq=show
is clear enough?
It's clear, except I can't tell if it applies to
On 07/05/2010 04:57 PM, 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
Il giorno lun, 05/07/2010 alle 18.55 +0800, Jason Heeris ha scritto:
On 5 July 2010 18:32, Pietro Battiston m...@pietrobattiston.it wrote:
You wouldn't need threading if you could do:
def do_processing(self):
if self.counter 1000:
import time
time.sleep(.01)
I just sent a mail to the python-hackers list with some of my queries.
Replying here as well as application authors will be interested.
Cool.
But my concerns are basically
* What is the state of the more advanced GObject features in PyGI
- _gsignals_, interface implementation,
This seems a little soft. Please do not take offence, but can this
please be treated with similar stability guarantees and respect as gtk+
- if your commit breaks backwards compatibility with no warning then it
will be reverted.
Sorry,
s/will/should
I'm not the boss!
John
Regards,
Hi All,
It would be great if we could do a PyGtk stable release to align with
the last gtk-2.0 release. I am happy to do this if no-one else wants to.
Also, would it be worth numbering this release as pygtk-2.22? It would
be nice if the version numbers matched again. Although this might not be
Hi,
First of all, PyGI and GObject introspection is the way forward.
Now, that being said, it seems a little silly to spend all this effort
porting C apps in GNOME to gtk-3.0 only to see the first PyGtk app drag
back in the gtk-2.0 libraries with import gtk.
So I spent a little time trying to
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
On 5 July 2010 21:48, A.T.Hofkamp a.t.hofk...@tue.nl wrote:
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.
It's not complicated, there's simply a time consuming operation
On 2010-07-05 20:32, Jason Heeris wrote:
2. Any GTK interaction, such as emitting a signal from this new
thread, must be either:
a. done via glib.idle_add (if I'm happy to let GTK do it
whenever it next feels like it), -OR-
b. wrapped in gtk.gdk.threads_enter()/...leave(),
On 07/01/2010 11:48 AM, Robert Schroll wrote:
Is it possible to create a horizontal TreeView in pyGTK? That is, a
treeview where each row appears to the right of, instead of below, the
preceding row?
I don't need a general solution - this is for a ListStore with a single
column. If there's a
On 5 July 2010 17:53, Pietro Battiston m...@pietrobattiston.it wrote:
Il giorno lun, 05/07/2010 alle 16.32 +0800, Jason Heeris ha scritto:
3. I don't need to do the threads_enter/leave (or use the context
manager) if I only use glib.idle_add (or timeout_add, etc)
No, you don't. If you don't
18 matches
Mail list logo
