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 wan
Jason Heeris wrote:
> 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.1
On 5 July 2010 17:36, A.T.Hofkamp 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 ha
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
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
Py
On 5 July 2010 18:05, Neil Benn 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 have to worry abo
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 wrote:
> Hello,
>
> I would like to impleme
Il giorno lun, 05/07/2010 alle 18.09 +0800, Jason Heeris ha scritto:
> On 5 July 2010 17:53, Pietro Battiston wrote:
> > Apart from 2.c, I guess
> > http://faq.pygtk.org/index.py?file=faq20.006.htp&req=show
> > is clear enough?
>
> It's clear, except I can't tell if it applies to PyGObject 2.20 o
On 07/05/2010 04:57 PM, Jason Heeris wrote:
> On 5 July 2010 17:36, A.T.Hofkamp 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)
Il giorno lun, 05/07/2010 alle 18.55 +0800, Jason Heeris ha scritto:
> On 5 July 2010 18:32, Pietro Battiston wrote:
> > You wouldn't need threading if you could do:
>
> > def do_processing(self):
> >if self.counter < 1000:
> >import time
> >time.sleep(.01)
> >return T
> > 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 imp
>
> 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
>
> Rega
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
wo
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 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
On 5 July 2010 21:48, A.T.Hofkamp 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 involved.
> About
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 ther
On 5 July 2010 17:53, Pietro Battiston 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 really need thre
19 matches
Mail list logo
