Re: [pygtk] threading
On Sat, 2004-08-28 at 23:19, Yann Le Boulanger wrote:
> >
> > So this didn't work?
> > ===
> > thr = GajimThread('gt')
> > thr.start()
> > while thr.isAlive()
> > thr.join(timeout=0.1)
> > time.sleep(2)
> > print "core"
> > ===
> >
>
>
> This works, but it's not what I want : I doesn't want the main thread
> (core.py) to stop when I close the second thread. What I want is that
> when the second thread finish, gtk closes all opened windows and stops,
> but the main thread must continue running.
>
> any idea ?
How about:
thr = GajimThread('gt')
thr.start()
while 1:
if thr.isAlive():
thr.join(timeout=0.1)
time.sleep(2)
print "core"
> Thanks
> Asterix
> ___
> pygtk mailing list [EMAIL PROTECTED]
> http://www.daa.com.au/mailman/listinfo/pygtk
> Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
--
Steve McClure <[EMAIL PROTECTED]>
___
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] gnome-python split proposal
On Sat, 2004-08-28 at 18:59, Christian Robottom Reis wrote: > On Sat, Aug 28, 2004 at 06:07:59PM +0100, Gustavo J. A. M. Carneiro wrote: > > I would like to know what the pygtk/gnome community thinks about > > splitting gnome-python, according to the following plan: > > > > - gnome-python keeps the modules that are part of gnome developer > > platform[1]: > > o gnome, gnome.ui, gnome.vfs, gnome.canvas > > o bonobo, bonobo.activation, bonobo.ui > > o gconf > > > > - We create a new pygtk-extra package containing everything else, > > including: > > o gnome.applet > > o gnome.nautilus > > o gtkhtml2 > > o gnomeprint, gnomeprint.ui > > Given that most/all packages are gnome-dependent, we should probably > just have gnome-python-extra include the gnome bits we want, and leave > pygtk-extra for whenever it becomes necessary. > > People could request addition of pygtk-only modules in > gnome-python-extra for now if they wanted "official" distribution from > pygtk.org. > > > I believe this split leaves gnome-python in a better position for > > inclusion in the next gnome bindings release. > > Agreed 100%. Murray will be proud . I thought Murray said that just having compile switches with the default building only the gnome platform bits would be acceptable to him. Either way, whatever gets python bindings as part of the official gnome bindings release sounds good to me. -- J5 ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] gnome-python split proposal
On Sat, Aug 28, 2004 at 06:07:59PM +0100, Gustavo J. A. M. Carneiro wrote: > I would like to know what the pygtk/gnome community thinks about > splitting gnome-python, according to the following plan: > > - gnome-python keeps the modules that are part of gnome developer > platform[1]: > o gnome, gnome.ui, gnome.vfs, gnome.canvas > o bonobo, bonobo.activation, bonobo.ui > o gconf > > - We create a new pygtk-extra package containing everything else, > including: > o gnome.applet > o gnome.nautilus > o gtkhtml2 > o gnomeprint, gnomeprint.ui Given that most/all packages are gnome-dependent, we should probably just have gnome-python-extra include the gnome bits we want, and leave pygtk-extra for whenever it becomes necessary. People could request addition of pygtk-only modules in gnome-python-extra for now if they wanted "official" distribution from pygtk.org. > I believe this split leaves gnome-python in a better position for > inclusion in the next gnome bindings release. Agreed 100%. Murray will be proud . Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] threading
So this didn't work?
===
thr = GajimThread('gt')
thr.start()
while thr.isAlive()
thr.join(timeout=0.1)
time.sleep(2)
print "core"
===
This works, but it's not what I want : I doesn't want the main thread
(core.py) to stop when I close the second thread. What I want is that
when the second thread finish, gtk closes all opened windows and stops,
but the main thread must continue running.
any idea ?
Thanks
Asterix
___
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] gnome-python split proposal
On Sat, 28 Aug 2004 21:22:46 +0100, Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> wrote: > I just realized that there is a project called python-gtkextra, so > pygtk-extra is bound to cause some confusion. Any ideas for alternative > names? Does gnome-python-extra sound good? Any other idea? Thanks. > "pygtk-plus" -- Sridhar - http://cs.annauniv.edu/~rsridhar Blog: http://www.livejournal.com/users/sridharinfinity ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] gnome-python split proposal
On Sat, Aug 28, 2004 at 09:22:46PM +0100, Gustavo J. A. M. Carneiro wrote: > I just realized that there is a project called python-gtkextra, so > pygtk-extra is bound to cause some confusion. Any ideas for alternative > names? Does gnome-python-extra sound good? Any other idea? Thanks. Doesn't gnome-python-extra indicate that it's necessarily associated with GNOME? Let me try and think up a few names. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] gnome-python split proposal
I just realized that there is a project called python-gtkextra, so pygtk-extra is bound to cause some confusion. Any ideas for alternative names? Does gnome-python-extra sound good? Any other idea? Thanks. A Sáb, 2004-08-28 às 18:07, Gustavo J. A. M. Carneiro escreveu: > I would like to know what the pygtk/gnome community thinks about > splitting gnome-python, according to the following plan: > > - gnome-python keeps the modules that are part of gnome developer > platform[1]: > o gnome, gnome.ui, gnome.vfs, gnome.canvas > o bonobo, bonobo.activation, bonobo.ui > o gconf > > - We create a new pygtk-extra package containing everything else, > including: > o gnome.applet > o gnome.nautilus > o gtkhtml2 > o gnomeprint, gnomeprint.ui > > At this point we would have more liberty to add other useful modules > to pygtk-extra, such as: > o pygtksourceview > o some libegg stuff (tray, recent-files, ...) > o gtkspell > o ... > > I believe this split leaves gnome-python in a better position for > inclusion in the next gnome bindings release. > > [1] http://www.gnome.org/start/2.7/platform/ > > Regards. -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] gnome-python split proposal
"Gustavo J. A. M. Carneiro" <[EMAIL PROTECTED]> writes: > I would like to know what the pygtk/gnome community thinks about > splitting gnome-python, according to the following plan: This is a good idea. I am in favor. ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] gnome-python split proposal
I would like to know what the pygtk/gnome community thinks about splitting gnome-python, according to the following plan: - gnome-python keeps the modules that are part of gnome developer platform[1]: o gnome, gnome.ui, gnome.vfs, gnome.canvas o bonobo, bonobo.activation, bonobo.ui o gconf - We create a new pygtk-extra package containing everything else, including: o gnome.applet o gnome.nautilus o gtkhtml2 o gnomeprint, gnomeprint.ui At this point we would have more liberty to add other useful modules to pygtk-extra, such as: o pygtksourceview o some libegg stuff (tray, recent-files, ...) o gtkspell o ... I believe this split leaves gnome-python in a better position for inclusion in the next gnome bindings release. [1] http://www.gnome.org/start/2.7/platform/ Regards. -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] threading
On Sat, 2004-08-28 at 06:07, [EMAIL PROTECTED] wrote:
> On Tue, Aug 24, 2004 at 09:40:43PM +0200, [EMAIL PROTECTED] wrote:
> > On Mon, Aug 23, 2004 at 08:55:36AM -0400, Steve McClure wrote:
> >
> > In fact, not really. I'd like that when the thread finishes, gtk close
> > properly (it should close all the opened windows), but i'd like the core
> > to continue running.
> >
> > Thanks for help,
> > Asterix
> > ___
>
> I had no answer, so does it mean that it's not possible to run _and stop_
> gtk in a thread ?
>
> Asterix
So this didn't work?
===
thr = GajimThread('gt')
thr.start()
while thr.isAlive()
thr.join(timeout=0.1)
time.sleep(2)
print "core"
===
> ___
> pygtk mailing list [EMAIL PROTECTED]
> http://www.daa.com.au/mailman/listinfo/pygtk
> Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
--
Steve McClure <[EMAIL PROTECTED]>
___
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Catching gobject.GError..
A Sáb, 2004-08-28 às 04:07, alejandro david weil escreveu: > How should I catch gobject.GError, or where is it? > I couldn't find where to take this class from :-( I don't see the problem: >>> import gobject >>> gobject.GError > Thanks, > dave -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] threading
On Tue, Aug 24, 2004 at 09:40:43PM +0200, [EMAIL PROTECTED] wrote: > On Mon, Aug 23, 2004 at 08:55:36AM -0400, Steve McClure wrote: > > In fact, not really. I'd like that when the thread finishes, gtk close > properly (it should close all the opened windows), but i'd like the core > to continue running. > > Thanks for help, > Asterix > ___ I had no answer, so does it mean that it's not possible to run _and stop_ gtk in a thread ? Asterix ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] Catching gobject.GError..
How should I catch gobject.GError, or where is it? I couldn't find where to take this class from :-( Thanks, dave -- + There is no dark side of the moon really. Matter of fact it's all dark. ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
