Re: [pygtk] Threads and applets (gnome.applet)
On Fri, 18 Feb 2005, Johan Dahlin wrote: Brad Tonkes wrote: Hi, I've recently encountered some problems with threads in a (python) gnome panel applet. My problem is that any spawned threads don't seem to get Don't use threads together with the panel applet code. Neither ORBit, bonobo, nor orbit-python is thread safe. And the pygtk code is less than perfect when it comes to threads. I'd really advise you to use something other than threads. Since I have am interfacing with a threaded, third party networking library I have only two options: (1) use threading, (2) fork a process and communicate using pipes or shared mem. Solution (2) is ugly and potentially less portable than solution (1). Solution (1) is straightforward: I am careful to only perform gtk/gnome operations within the mainloop thread, and the gtk-only version works perfectly, as did my gnome panel applet in the 1.x days and as of a few weeks ago in 2.x (x = 2). Moreover, it is working just fine (for someone else) on Fedora core 2 (pygtk 2.2.0, gnome-python 2.0.0). My problem is that due to a (relatively) recent change somewhere, I cannot even get a spawned thread to run, even if it has nothing to do with gtk/gnome (as in my earlier example where the spawned thread just did a sys.stdout.write). Does anyone know if this is a change to pygtk, gnome-python, gtk+ or the gnome libs? Has the API for running threads in a gnome applet changed subtly somewhere between 2.0.x (known to work) and 2.6.x (not working), or have the libs been completely re-organised to preclude threads altogether? thanks, brad +--+--++ | Brad Tonkes, Research Fellow | | There were too many of us, | | Centre for Autonomous Systems, | _--_|\ | we had access to too much | | School of Computer Science and | / \ | money, too much equipment, | | Engineering| \_.--._* | and little by little, we | | UNSW, 2052 | v | went insane. | | NSW, Australia | || +--+--++ ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] Threads and applets (gnome.applet)
Hi,
I've recently encountered some problems with threads in a (python) gnome
panel applet. My problem is that any spawned threads don't seem to get
scheduled and consequently never run (at least, not until the gtk
mainloop exits). A simple example:
=
#!/usr/bin/python
import sys
sys.stdout = open('debug', 'w') # redirect stdout/stderr to a file
sys.stderr = sys.stdout
import gtk
gtk.gdk.threads_init() # (!)
import gnome.applet
import gobject
import thread
import time
class AppletClass(gnome.applet.Applet):
def __init__(self, applet, iid):
self.__gobject_init__()
self.applet = applet
self.label = gtk.Label('Hello World')
self.applet.add(self.label)
thread.start_new_thread(self.thread_function, ())
def thread_function(self):
sys.stdout.write('Thread started.\n')
sys.stdout.flush()
while True:
sys.stdout.write('I like threads.\n')
sys.stdout.flush()
time.sleep(1)
gobject.type_register(AppletClass)
def class_applet_factory(applet, iid):
AppletClass(applet,iid)
return gtk.TRUE
gnome.applet.bonobo_factory(OAFIID:GNOME_PythonAppletSample_Factory,
AppletClass.__gtype__,
hello, 0, class_applet_factory)
=
I expect this applet (with the appropriate bonobo .server file) to show
a Hello World label in the panel and write I love threads. to stdout
(which is redirected to a file debug in this case). The widget part
works fine, but the stdout thread is never run (nothing written to stdout).
Points to note:
* My applet (of which the above is a highly simplified version) used to
work; a recent update of gnome-python seems to have broken it, but I'm
not sure exactly when.
* For threaded applications, gtk.gdk.threads_init() is supposed to be
called before gtk.main, but in the case of an applet, aren't we already
inside gtk.main? Can/should the threads_init call be moved elsewhere?
* I'm running Debian (unstable), relevant packages:
python2.3-gtk2 (2.4.1-2)
python2.3-gnome (2.6.1-1)
python2.3 (2.3.4-19)
libgtk2.0-0 (2.4.14-2)
libgnome2-0 (2.8.0-6)
Does anybody know what/where the problem might be? Is it most likely a
problem with gtk+, gnome, pygtk, pygnome or the Debian packaging?
thanks,
brad
+--+--++
| Brad Tonkes, Research Fellow | | There were too many of us, |
| Centre for Autonomous Systems, | _--_|\ | we had access to too much |
| School of Computer Science and | / \ | money, too much equipment, |
| Engineering| \_.--._* | and little by little, we |
| UNSW, 2052 | v | went insane. |
| NSW, Australia | ||
+--+--++
___
pygtk mailing list pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] pygtk2 TextView cursor with black background
This is probably more of a GTK2 question rather than being pygtk-specific,
but I wonder if anyone here has come across it. I have a TextView whose
background is set to black via a gtkrc file:
style foo
{
text[NORMAL] = {1.0, 1.0, 1.0}
base[NORMAL] = {0.0, 0.0, 0.0}
}
widget_class *GtkTextView style foo
which works fine. However, the TextView cursor is drawn in black and can't
be seen against the black background. Note that the cursor is set to be
visible with set_cursor_visible(gtk.TRUE), and it is visible if the style
isn't applied. Is there any way to make the cursor visible against a black
background? I tried (hoped) that adding a fg[NORMAL] = {1.0, 1.0, 1.0} would
work, but it doesn't seem to.
thanks,
brad
___
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] PyGNOME2 panel applets
The topic of panel applets in pygnome2 has been raised before, and seemingly, answered succinctly: http://www.daa.com.au/pipermail/pygtk/2002-September/003393.html However, I'm still confused. Using the files attached to the above post, I put GNOME_HelloApplet.server in /home/btonkes/lib/oaf which is in the oaf path: $ oaf-sysconf --display-directories OAF configuration file contains: /home/btonkes/lib/oaf and python-applet in /home/btonkes/src/pyapplet, changing the PATH TO PYTHON APPLET string in GNOME_HelloApplet.server to /home/btonkes/src/pyapplet/python-applet. My question: what next? Running python-applet seems to do nothing. Am I doing something fundamentally wrong? I'm using Red Hat 8.0 with the supplied gnome-python rpms, i.e., gnome-python2-applet-1.99.11-8 gnome-python2-gtkhtml2-1.99.11-8 gnome-python2-canvas-1.99.11-8 gnome-python2-bonobo-1.99.11-8 gnome-python2-1.99.11-8 orbit-python-1.99.0-4 Is this the only way to create panel applets? I initially thought that import gnome import gnome.applet applet = gnome.applet.Applet() might work, but this just dumps core. Any help appreciated, thanks, brad ___ 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] get_colormap().alloc(...) on Solaris
I'm having trouble with a Solaris (8) install of gnome-python (1.0.53, gtk
1.2.8) with respect to get_colormap().alloc(). Most easily reproduced with:
from gtk import *
w = GtkWindow()
w.get_colormap().alloc('red') # Works fine.
w.get_colormap().alloc(0, 0, 0)# Generates a bus error and dumps core.
Any rgb trio gives the same result. GdkColor(r, g, b) works just fine, which
is perhaps not surprising. The example above also works just fine on a linux
box with the same versions of gnome-python and gtk. Is this most likely a
problem with the gtk libs or with the python bindings? Any help appreciated.
thanks,
brad
+--+--++
| Brad Tonkes, PhD student | _--_|\ | There were too many of us |
| School of Computer Science | / * | we had access to too much |
| Electrical Engineering | \_.--._/ | money, too much equipment, |
| University of Queensland, 4072 | v | and little by little, we |
| Queensland, Australia| | went insane -- UNKLE |
+--+--++
___
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Re: [pygtk] get_colormap().alloc(...) on Solaris
On Thu, 22 Feb 2001, James Henstridge wrote:
On Thu, 22 Feb 2001, Brad Tonkes wrote:
I'm having trouble with a Solaris (8) install of gnome-python (1.0.53, gtk
1.2.8) with respect to get_colormap().alloc(). Most easily reproduced with:
from gtk import *
w = GtkWindow()
w.get_colormap().alloc('red') # Works fine.
w.get_colormap().alloc(0, 0, 0)# Generates a bus error and dumps core.
[snip]
Please try this with gnome-python 1.4.0 (available from your closest
ftp.gnome.org mirror (which would be mirror.aarnet.edu.au)). I think this
problem should be fixed now.
James.
I finally found Frank Warmerdam's patch for IRIX in the archives (and your
follow-up). That patch has certainly fixed things.
Many many thanks,
brad
___
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
