Re: [pygtk] Stability of threading support?
On Fri, 2003-04-04 at 21:32, Greg Ward wrote: > Back in January, James said this: > > The threading in pygtk-1.99.x is not quite solid at the moment... > > Is this still the case? Thankfully, no. People have spent some time hacking on the threading, and it now seems to be pretty solid. Of course, YMMV -- but if you find any problems, please file a bug. That set, allow me to offer a suggestion: you can make your life a lot easier by not making gtk calls from threads. Instead, do all of your gtk calls from inside of one-shot idle functions launched from inside threads. gtk.timeout_add and gtk.idle_add are fully thread-safe, so there is no locking to worry about. And idles and timeouts are guaranteed to execute in the main thread. Your "eject" example could be handled by code like this: import threading def eject(): class EjectThread(threading.Thread): def run(self): cdrom.eject() # might block, but that is OK gtk.idle_add(eject_button.set_sensitive, True) eject_button.set_sensitive(False) EjectThread().start() Disclaimer: I haven't run this code, it probably contains stupid typos, etc. -JT ___ 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] Stability of threading support?
Back in January, James said this: > The threading in pygtk-1.99.x is not quite solid at the moment (which is > why you need to manually enable it during configure). If you are having > troubles, I recommend you try the latest CVS version. (http://www.mail-archive.com/[EMAIL PROTECTED]/msg05333.html) Is this still the case? I'm working on an application that just cries out for threading (a CD ripper -- operations like ejecting the CD, reading the TOC, querying the CDDB etc. should all be done in the background), and it doesn't quite work. Details: if I restrict background threads so they make no GTK/GDK calls, everything seems to work fine. But that makes it hard to, eg., make the "Eject" button insensitive while the drive is ejecting. (At least under Linux, the "eject CD" ioctl() doesn't return until the drive door is fully open.) I'm sure it's possible to make this happen by cooking up a protocol between the eject thread and the main thread, but it would be so much cleaner if the eject thread just did this: eject_button.set_sensitive(False) gtk.mainiteration() cdrom.eject() eject_button.set_sensitive(True) Unfortunately, if I make any GTK calls in the background thread, the application freezes. Even if I call gtk.threads_enter(), it still freezes -- it just happens in the threads_enter() call, rather in the first widget-twiddling call. So, first question: is threading support stable/reliable yet? (I'm running Debian unstable with libgtk 2.2.1-3 and pygtk 1.99.16-1.) If so, can anyone tell me how to do it right, ie. how to write a background thread that manipulates the GUI? Thanks -- Greg -- Greg Ward <[EMAIL PROTECTED]> http://www.gerg.ca/ Laziness, Impatience, Hubris. ___ 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] code generation from *.glade files
On Wed, 2 Apr 2003, Fabien COUTANT wrote: > > ... I however would like to be > > able to get Python source code as it is possible for C or C++. Is > > there any up to date utility that is capable of doing this? I am > > talking about the GTK+-2.x related bindings not the older ones. > > I intend to "port" gladepyc to pygtk2 soon... > But I am in the (quite long) process of migrating my Linux/Debian > installation to woody/Python2.2/Gtk2, so I'm not going to start work > on it before some weeks, and the port will take some weeks by itself > (since I can only work on it during week-ends). > > AFAIK for now there isn't any Python code generators available for > GTK2 :'( > The other python code generator "glc" seems as idle as "gladepyc" has > been for the past months... More like the last few years. As much as I like libglade, I still think there is a valid use/need for python code generation > > NB: If you don't know it yet -> > http://www.fcoutant.freesurf.fr/gladepyc.html > > ___ 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] ANNOUNCE: Gaphor 0.2.0
Application === Gaphor 0.2.0 Description === Gaphor is an UML modeling tool written in Python. It is designed to be extensible and easy to use. Enhancements It's been a while ago since 0.1.0 was announced. In the mean time a lot has changed: - Gaphor is completely written in Python - Supports Class and UseCase diagrams - UML meta-model based datamodel Requirements - GNOME2 libraries - Gnome-Python 1.99.16 - DiaCanvas2 0.9.2 Download http://sourceforge.net/projects/gaphor Homepage http://gaphor.sourceforge.net Have fun, Arjan ___ 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] how to attach a gtk.Layout to a gtk.Scrollbar
I read the pygtk2 tutorial[1] and have some problems with the Layout Container[2]. When i try to use a vertical scrollbar with my Layout container something weird happens: mylayout = gtk.Layout(None, None) myscrollbar - gtk.VScrollbar(None) adjust = mylayout.get_vadjustment() myscrollbar.set_adjustment(adjust) The thing is that if I click in the trough or if I drag the slider everything works but if I click in the scrollbar buttons nothing happens. Do I have to connect some signal in order to make it work? or is it a bug? Thanks in advance [1] http://www.moeraki.com/pygtktutorial/pygtk2tutorial/index.html [2] http://www.moeraki.com/pygtktutorial/pygtk2tutorial/sec-Layout.html -- Lorenzo Gil Sánchez <[EMAIL PROTECTED]> signature.asc Description: PGP signature ___ 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] Problem with GtkDrawingArea
On Fri, 2003-04-04 at 09:01, Steve McClure wrote: I don't know what happened with that reply, my sent box has the full text of my reply. Here it is again. (script deleted) Yes, that works fine, producing dark slate gray ovals. I added print statements around the gc creation and setup and get the same sort of results # this is DarkSlateGray on a (255,255,255) color scale. I # multiply by 255 to scale to the units of alloc, which are # 0-65535 for each (R,G,B) value color = cmap.alloc(49*255,79*255,79*255) print 'color: ', color gc = widget.get_parent_window().new_gc() print 'before:', gc.foreground gc.foreground = color print 'after:', gc.foreground produces: color: before: after: color: before: after: So I guess that debugging method cannot be relied upon and that your thought that I must not be using the right gc is correct. Unfortunately I have no idea how the color came to be blue. Thanks for the help. -- Steve McClure <[EMAIL PROTECTED]> Racemi, Inc. signature.asc Description: This is a digitally signed message part ___ 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] Problem with GtkDrawingArea
On Fri, 2003-04-04 at 08:24, John Hunter wrote: > > "Steve" == Steve McClure <[EMAIL PROTECTED]> writes: > > Steve> That's probably not practical, but I am using the new gc in > Steve> the draw_line and draw_point commands. > > Hmmm... Here's an old script I worked with when I was first learning > pygtk that should run under pygtk-0.6.4 and draws in a specified > color. Does it draw in dark slate gray when you run it? If so, try > and figure out what is different from your code. > [ script deleted ] Yes, that works fine, producing dark slate gray ovals. I added print statements around the gc creation and setup and get the same sort of results # this is DarkSlateGray on a (255,255,255) color scale. I # multiply by 255 to scale to the units of alloc, which are # 0-65535 for each (R,G,B) value color = cmap.alloc(49*255,79*255,79*255) print 'color: ', color gc = widget.get_parent_window().new_gc() print 'before:', gc.foreground gc.foreground = color print 'after:', gc.foreground produces: color: before: after: color: before: after: So I guess that debugging method cannot be relied upon and that your thought that I must not be using the right gc is correct. Unfortunately I have no idea how the color came to be blue. Thanks for the help. > ___ > 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]> Racemi, Inc. signature.asc Description: This is a digitally signed message part ___ 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] Problem with GtkDrawingArea
> "Steve" == Steve McClure <[EMAIL PROTECTED]> writes:
Steve> That's probably not practical, but I am using the new gc in
Steve> the draw_line and draw_point commands.
Hmmm... Here's an old script I worked with when I was first learning
pygtk that should run under pygtk-0.6.4 and draws in a specified
color. Does it draw in dark slate gray when you run it? If so, try
and figure out what is different from your code.
import sys
from gtk import *
import random
import time
pixmap = None
class MyClass:
def __init__(self):
self._count1 = 0
self._count2 = 0
def idle_function(self, widget):
x = int(random.uniform(0,500))
y = int(random.uniform(0,500))
r1 = int(random.uniform(10,100))
r2 = int(random.uniform(10,100))
fill = 1
cmap = widget.get_colormap()
# this is DarkSlateGray on a (255,255,255) color scale. I
# multiply by 255 to scale to the units of alloc, which are
# 0-65535 for each (R,G,B) value
color = cmap.alloc(49*255,79*255,79*255)
gc = widget.get_parent_window().new_gc()
gc.foreground = color
widget.draw_arc(gc,
fill, x, y,
r1, r2,
0,360*64)
time.sleep(.001)
return TRUE
def timer_function(self):
self._count2 = self._count2 + 1
print 'Timer %d' % self._count2
return TRUE
def configure_event(widget, event):
global pixmap
win = widget.get_window()
pixmap = create_pixmap(win, win.width, win.height, -1)
draw_rectangle(pixmap, widget.get_style().white_gc, TRUE,
0, 0, win.width, win.height)
# could also be placed in expose_event
c = MyClass()
idle_add(c.idle_function, widget)
timeout_add(1000,c.timer_function)
return TRUE
def expose_event(widget, event):
area = event.area
gc = widget.get_style().fg_gc[STATE_NORMAL]
widget.draw_pixmap(gc, pixmap, area[0], area[1], area[0], area[1],
area[2], area[3])
widget.draw_arc(widget.get_style().black_gc,
0, 100, 200,
60,60,
0,360*64)
return FALSE
def button_press_event(widget, event):
if event.button == 1 and pixmap != None:
draw_arcs(widget, event.x, event.y)
return TRUE
def motion_notify_event(widget, event):
if event.is_hint:
x, y = event.window.pointer
state = event.window.pointer_state
else:
x = event.x; y = event.y
state = event.state
if state & GDK.BUTTON1_MASK and pixmap != None:
draw_arcs(widget, x, y)
return TRUE
def draw_arcs(widget, x, y):
fill = 0
color = GdkColor(0.1,0.3,0.8)
widget.draw_arc(widget.get_style().black_gc, fill, x, y,
60,60,
0,360*64)
return TRUE
def main():
win = GtkWindow()
win.set_name("Test Input")
win.connect("destroy", mainquit)
win.set_border_width(5)
vbox = GtkVBox(spacing=3)
win.add(vbox)
vbox.show()
drawing_area = GtkDrawingArea()
drawing_area.size(500, 500)
vbox.pack_start(drawing_area)
drawing_area.show()
drawing_area.connect("expose_event", expose_event)
drawing_area.connect("configure_event", configure_event)
drawing_area.connect("motion_notify_event", motion_notify_event)
drawing_area.connect("button_press_event", button_press_event)
drawing_area.set_events(GDK.EXPOSURE_MASK |
GDK.LEAVE_NOTIFY_MASK |
GDK.BUTTON_PRESS_MASK |
GDK.POINTER_MOTION_MASK |
GDK.POINTER_MOTION_HINT_MASK)
button = GtkButton("Quit")
vbox.pack_start(button, expand=FALSE, fill=FALSE)
button.connect("clicked", win.destroy)
button.show()
win.show()
mainloop()
if __name__ == '__main__':
main()
___
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] Problem with GtkDrawingArea
On Fri, 2003-04-04 at 07:12, John Hunter wrote: > > "Steve" == Steve McClure <[EMAIL PROTECTED]> writes: > > Steve> I can draw no problem but obviously only in the original > Steve> color and blue. > > I generally just set the foreground attribute, and draw away > > gc.foreground = newC > da.draw_lines(newgc, zip(xt,yt)) > > What is your drawing command? I assume you are passing the newgc into > the draw command. It might help to post a complete script which > replicates your problem. That's probably not practical, but I am using the new gc in the draw_line and draw_point commands. Note the print output of the gc indicates the new color is blue and indeed it is. You can see from the print output that the gc creation isn't working as I expected even though the color allocation does. Or am I misreading the output from the print statements? >gc = graph.get_style().fg_gc[gtk.STATE_NORMAL] # the graph widget > #foreground is what is specified in the rc file > prevC = gc.foreground > #r = prevC.red + 1000 > #g = prevC.green + 1000 > b = prevC.blue + 1000 > newC = graph.get_colormap().alloc(r, g, b) > newgc = graph.get_window().new_gc(background = > gc.background, foreground = newC) > > some debug prints show: > print prevC.foreground: > print newC: > print newgc.foreground: > > John Hunter > ___ > 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]> Racemi, Inc. signature.asc Description: This is a digitally signed message part ___ 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] Problem with GtkDrawingArea
> "Steve" == Steve McClure <[EMAIL PROTECTED]> writes: Steve> I can draw no problem but obviously only in the original Steve> color and blue. I generally just set the foreground attribute, and draw away gc.foreground = newC da.draw_lines(newgc, zip(xt,yt)) What is your drawing command? I assume you are passing the newgc into the draw command. It might help to post a complete script which replicates your problem. John Hunter ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
