Re: [pygtk] trouble moving treeView selection
John Finlay wrote: Doug Quale wrote: Thomas Mills Hinkle <[EMAIL PROTECTED]> writes: I'm having trouble moving the treeView selection. Specifically, when I use move_up and move_down, the selection occasionally stops working. When it breaks, the widget continues to show my selection, but future calls that ask for it get no selection at all and I can't change the selection by clicking. I'd like to know if anyone else gets the same behavior or has any insight into what's going on. It seems to work for me with PyGTK CVS and GTK+ 2.4. What versions are you using? Unfortunately I can't tell you why your code doesn't work. When I try it, I get gtk+ critical errors like this: $ python treeviewexample.py path_next called w/ path=(5,), inc=-1 path_next returning (4,) to be selected (treeviewexample.py:15221): Gtk-CRITICAL **: file gtkrbtree.c: line 1000 (_gtk_rbtree_reorder): assertion `tree->root->count == length' failed This is a GTK+ bug. I filed a bug report. It doesn't seem to prevent the rows from being moved. John I'm wrong. I didn't get the above GTK error I got a different one: (treeviewexample.py:11504): Gtk-CRITICAL **: file gtktreestore.c: line 721 (gtk_tree_store_iter_n_children): assertion `iter == NULL || iter->user_data != NULL' failed I filed a bug report on this one. John ___ 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] trouble moving treeView selection
Doug Quale wrote: Thomas Mills Hinkle <[EMAIL PROTECTED]> writes: I'm having trouble moving the treeView selection. Specifically, when I use move_up and move_down, the selection occasionally stops working. When it breaks, the widget continues to show my selection, but future calls that ask for it get no selection at all and I can't change the selection by clicking. I'd like to know if anyone else gets the same behavior or has any insight into what's going on. It seems to work for me with PyGTK CVS and GTK+ 2.4. What versions are you using? Unfortunately I can't tell you why your code doesn't work. When I try it, I get gtk+ critical errors like this: $ python treeviewexample.py path_next called w/ path=(5,), inc=-1 path_next returning (4,) to be selected (treeviewexample.py:15221): Gtk-CRITICAL **: file gtkrbtree.c: line 1000 (_gtk_rbtree_reorder): assertion `tree->root->count == length' failed This is a GTK+ bug. I filed a bug report. It doesn't seem to prevent the rows from being moved. John ___ 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] trouble moving treeView selection
Thomas Mills Hinkle <[EMAIL PROTECTED]> writes: > I'm having trouble moving the treeView selection. Specifically, when I > use move_up and move_down, the selection occasionally stops working. > When it breaks, the widget continues to show my selection, but future > calls that ask for it get no selection at all and I can't change the > selection by clicking. > > I'd like to know if anyone else gets the same behavior or has any > insight into what's going on. Unfortunately I can't tell you why your code doesn't work. When I try it, I get gtk+ critical errors like this: $ python treeviewexample.py path_next called w/ path=(5,), inc=-1 path_next returning (4,) to be selected (treeviewexample.py:15221): Gtk-CRITICAL **: file gtkrbtree.c: line 1000 (_gtk_rbtree_reorder): assertion `tree->root->count == length' failed The TreeStore.move_before() and move_after() methods were introduced in gtk+ 2.2 and are fairly new to pygtk. Since your code looks fine to me this may be a pygtk bug. If not, someone else on this list may be sharp enough to spot the problem. This isn't the root of the problem, but it is something to watch out for. The TreeStore.move_before() and move_after() methods are documented as working only on unsorted stores. Your sample code sets the sort column, so you have to be careful that you don't run into trouble with that. If you look at the pygtk FAQ, entry 13.30 shows one way to move treemodel rows that was used before the gtk+ 2.2 api was available. http://www.async.com.br/faq/pygtk/index.py?req=show&file=faq13.030.htp There is a caveat on the old method demonstrated in the FAQ. If you're tracking model changes swapping rows by hand instead of using move_before() may be undesirable. Not only will it emit two 'row-changed' signals, but worse the model will be in a somewhat inconsistent state (data for one row duplicated and the other row missing) in the interval between the signals. For my application this wasn't a problem. ___ 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] Progress Cell Renderer
Lorenzo Gil Sanchez wrote: You are right that bug is related with the problem we are discussing here but please note that even if that bug is solved we still can't override GTK+ C methods in Python which is what I understand stop us from having *full* support to subclass Widgets. You're correct that this bug is related to something a bit different -- GInterface support. The bug for this is http://bugzilla.gnome.org/show_bug.cgi?id=129032 There is some support for interface support in CVS, but it still needs work before it can be used to override methods defined in a superclass. Cheers, John ___ 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] Progress Cell Renderer
El vie, 25-06-2004 a las 20:03, Christian Robottom Reis escribió: > So I understand, is the problem that we can't override it (the class > parsing or instantiation fails) or that GTK+ never calls out methods? If > the latter, I guess I understand why, and we'd need to look at another > strategy for clobbering them. > Let me say I'm not an expert of how pygtk internally works but I think the problem is GTK+ never call our methods. Please, some pygtk masters (gjc, jdahlin, ...) confirm this > > For example, here we have a GTK+ C Object: GtkCellRendererText and if I > > subclass it from Python like > > > > class CellRendererCombo(gtk.CellRendererText): > > pass > > > > there is no way I can override the start_editing method of > > GtkCellRendererText, which is all we need to have a combo box inside a > > TreeView. > > We could of course try and add a hack that allowed this -- perhaps > something that did evil TreeView hacking. What do you think? > Don't even put those two words together (TreeView + hacking). It makes me have nightmares during daylight > > A possible work around would be to define each and every method that is > > a good candidate to be overriden to be a signal (since we can override > > signals in pygtk) but this means changing a lot of code in GTK+ which I > > see undoable for practical reasons. > > It depends on what you want. If this is blocking us from implementing a > Combo renderer, then I think we could very well push to get at least > this specific one changed. What do you say? > I would say let's make the GTK+ guys apply my patch to have a comborender in GTK+ and then we just need to wrap it :) This way everybody is happy. If all we want is a ComboRenderer this can work, but I just put that example. We have a much more general problem in hands. > Take care, You too Lorenzo ___ 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] trouble moving treeView selection
I'm having trouble moving the treeView selection. Specifically, when I
use move_up and move_down, the selection occasionally stops working.
When it breaks, the widget continues to show my selection, but future
calls that ask for it get no selection at all and I can't change the
selection by clicking.
The most basic code that will get me this behavior is the following:
ts, itera = self.treeview.get_selection().get_selected()
if itera:
next = ts.iter_next(itera)
ts.move_after(itera, next)
I've attached a full piece of sample code to illustrate my problem --
the code shows a simplified version of what I'd like to implement --
namely, convenient up and down buttons to move the selection (in
addition to using dnd for this).
With the attached code, I get erratic behavior. If I scroll to the
bottom and select a row, for example, I can move up and then down
(using only the buttons) without any trouble. However, if I do the
same thing with one of the top rows, it breaks immediately. In either
case, if I move a row up with my button, then select a row with the
mouse and try to move a row with a button again, it fails.
I'd like to know if anyone else gets the same behavior or has any
insight into what's going on.
Thanks,
Tom
#!/usr/bin/env python
import pygtk
#pygtk.require('2.0')
import gtk
class TreeViewExample:
# close the window and quit
def delete_event(self, widget, event, data=None):
gtk.main_quit()
return gtk.FALSE
def __init__(self):
# Create a new window
self.window = gtk.Window(gtk.WINDOW_TOPLEVEL)
self.window.set_title("Treeview Example")
self.window.set_size_request(200, 200)
self.window.connect("delete_event", self.delete_event)
self.scrolledwindow = gtk.ScrolledWindow()
self.vbox = gtk.VBox()
self.hbox = gtk.HButtonBox()
self.vbox.pack_start(self.scrolledwindow, True)
self.vbox.pack_start(self.hbox, False)
self.b0 = gtk.Button(None,stock=gtk.STOCK_GO_UP)
self.b0.connect('clicked',self.upCB)
self.b1 = gtk.Button(None,stock=gtk.STOCK_GO_DOWN)
self.b1.connect('clicked',self.downCB)
self.hbox.pack_start(self.b0)
self.hbox.pack_start(self.b1)
# create a treestore with one string column to use as the model
self.treestore = gtk.TreeStore(str)
self.populate_treestore()
# create the TreeView using treestore
self.treeview = gtk.TreeView(self.treestore)
# set selection mode
self.treeview.get_selection().set_mode(gtk.SELECTION_SINGLE)
# create a CellRenderer to render the data
self.cell = gtk.CellRendererText()
# create the TreeViewColumns to display the data
self.tvcolumn = gtk.TreeViewColumn('URL', self.cell, text=0)
# add columns to treeview
self.treeview.append_column(self.tvcolumn)
# make treeview searchable
self.treeview.set_search_column(0)
# Allow sorting on the column
self.tvcolumn.set_sort_column_id(0)
self.scrolledwindow.add(self.treeview)
self.window.add(self.vbox)
self.window.show_all()
def populate_treestore (self):
for n in range(20):
iter=self.treestore.append(None)
self.treestore.set_value(iter,0,"Row %s"%n)
def upCB (self, *args):
ts, itera = self.treeview.get_selection().get_selected()
if itera:
path=ts.get_path(itera)
prev=self.path_next(path,-1)
prev_iter=ts.get_iter(prev)
ts.move_before(itera,prev_iter)
self.treeview.get_selection().select_path(prev)
else: print "No selection!"
def downCB (self, *args):
ts, itera = self.treeview.get_selection().get_selected()
if itera:
next = ts.iter_next(itera)
ts.move_after(itera,next)
next_path=ts.get_path(next)
self.treeview.get_selection().select_path(self.path_next(next_path,1))
else: print "No selection!"
def path_next (self, path, inc=1):
"""Return the path NEXT rows after PATH. Next can be negative, in
which case we get previous paths."""
print "path_next called w/ path=%s, inc=%s"%(path,inc)
next=list(path[0:-1])
last=path[-1]
last += inc
if last < 0:
last=0
next.append(last)
next=tuple(next)
print "path_next returning ",next," to be selected"
return next
def main():
gtk.main()
if __name__ == "__main__":
treeviewex = TreeViewExample()
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] Progress Cell Renderer
On Fri, Jun 25, 2004 at 06:43:09PM +0200, Lorenzo Gil Sanchez wrote: > > There are various bug reports scattered around relating to this, but I think > > this is the mother of them all: > > > > http://bugzilla.gnome.org/show_bug.cgi?id=129843 > > You are right that bug is related with the problem we are discussing > here but please note that even if that bug is solved we still can't > override GTK+ C methods in Python which is what I understand stop us > from having *full* support to subclass Widgets. So I understand, is the problem that we can't override it (the class parsing or instantiation fails) or that GTK+ never calls out methods? If the latter, I guess I understand why, and we'd need to look at another strategy for clobbering them. > For example, here we have a GTK+ C Object: GtkCellRendererText and if I > subclass it from Python like > > class CellRendererCombo(gtk.CellRendererText): > pass > > there is no way I can override the start_editing method of > GtkCellRendererText, which is all we need to have a combo box inside a > TreeView. We could of course try and add a hack that allowed this -- perhaps something that did evil TreeView hacking. What do you think? > A possible work around would be to define each and every method that is > a good candidate to be overriden to be a signal (since we can override > signals in pygtk) but this means changing a lot of code in GTK+ which I > see undoable for practical reasons. It depends on what you want. If this is blocking us from implementing a Combo renderer, then I think we could very well push to get at least this specific one changed. What do you say? 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] Progress Cell Renderer
> There are various bug reports scattered around relating to this, but I think > this is the mother of them all: > > http://bugzilla.gnome.org/show_bug.cgi?id=129843 > You are right that bug is related with the problem we are discussing here but please note that even if that bug is solved we still can't override GTK+ C methods in Python which is what I understand stop us from having *full* support to subclass Widgets. For example, here we have a GTK+ C Object: GtkCellRendererText and if I subclass it from Python like class CellRendererCombo(gtk.CellRendererText): pass there is no way I can override the start_editing method of GtkCellRendererText, which is all we need to have a combo box inside a TreeView. I may feel pesimistic today, but I really don't see the way we ever can achieve this in pygtk :( A possible work around would be to define each and every method that is a good candidate to be overriden to be a signal (since we can override signals in pygtk) but this means changing a lot of code in GTK+ which I see undoable for practical reasons. Lorenzo ___ 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] Progress Cell Renderer
On Fri, Jun 25, 2004 at 04:32:30PM +0200, Lorenzo Gil Sanchez wrote: > I'm not sure what do you mean. There is a bug in GTK+ about having a > CellRendererCombo: > > http://bugzilla.gnome.org/show_bug.cgi?id=139347 > > Wrapping it in pygtk after that would be pretty easy. > > If you mean if we have a bug about full support to subclass gobjects in > pygtk I think there is no such a bug but I may be wrong. There are various bug reports scattered around relating to this, but I think this is the mother of them all: http://bugzilla.gnome.org/show_bug.cgi?id=129843 Dave Cook ___ 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] Progress Cell Renderer
On Fri, Jun 25, 2004 at 04:32:30PM +0200, Lorenzo Gil Sanchez wrote: > If you mean if we have a bug about full support to subclass gobjects in > pygtk I think there is no such a bug but I may be wrong. That's what I meant. I still wonder why you can't, and we *should* have a bug open for it in any case since it's bothered you for a long while. I'm sure anybody subclassing a GObject class will run into this sooner or later. 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] Progress Cell Renderer
El vie, 25-06-2004 a las 14:39, Christian Robottom Reis escribió: > On Fri, Jun 25, 2004 at 11:14:16AM +0200, Lorenzo Gil Sanchez wrote: > > I thought that porting it to pygtk would be straightforward but problem > > is that my CellRendererCombo is a subclasss of CellRendererText and you > > can not subclass CellRendererText in pygtk and override the render and > > get_size methods. :( > > Lgs, do we have a bug open for this? I'm interested in finding out > what's so depressing about this problem that everybody that talks about > it walks off crying mid-sentence . I'm not sure what do you mean. There is a bug in GTK+ about having a CellRendererCombo: http://bugzilla.gnome.org/show_bug.cgi?id=139347 Wrapping it in pygtk after that would be pretty easy. If you mean if we have a bug about full support to subclass gobjects in pygtk I think there is no such a bug but I may be wrong. Lorenzo ___ 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] Progress Cell Renderer
On Fri, Jun 25, 2004 at 11:14:16AM +0200, Lorenzo Gil Sanchez wrote: > I thought that porting it to pygtk would be straightforward but problem > is that my CellRendererCombo is a subclasss of CellRendererText and you > can not subclass CellRendererText in pygtk and override the render and > get_size methods. :( Lgs, do we have a bug open for this? I'm interested in finding out what's so depressing about this problem that everybody that talks about it walks off crying mid-sentence . 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
On Wed, Jun 23, 2004 at 11:05:03AM +, Tiago Cogumbreiro wrote:
> I for one would like to see them :) A threading tutorial is always nice.
> Making demos out of the most common concurrent patterns would also be
> interesting.
This is the method I finally settled on for handling threads in
pygtk programs. I have written a class that controls the rate
at which add_idle calls can be executed. The more calls that
are pending, the longer a thread has to sleep before it can
add its own. This way we can assure a reasonable time between
the registration and the execution.
I also defined a new signal that will be used to let the widget
know it should be updated. All subthreads then use the above
class to emit the proper signal.
As far as I have understood things, this should work on linux as well
as on window systems. However I have no window machine available,
so I would be gratefulll if those who have, could test this for
me. I have python 2.3.4 here and haven't thought much about
compatibility with previous versions.
-- demo2.py -
import gtk
import gtk.gdk as gdk
import pango
from threading import Thread, Lock
from random import Random, randint, shuffle
from time import sleep
from gobject import signal_new, SIGNAL_RUN_LAST, TYPE_BOOLEAN, TYPE_INT,
SIGNAL_ACTION, \
TYPE_NONE, TYPE_PYOBJECT
signal_new("update", gtk.DrawingArea, SIGNAL_RUN_LAST | SIGNAL_ACTION, TYPE_NONE,
(TYPE_PYOBJECT,TYPE_PYOBJECT,TYPE_PYOBJECT))
class Emittor:
def __init__(self, Expected_Entries):
self.Expect = 1.0 * Expected_Entries
self.Entries = 0
self.sleeptime = 0.01
self.entrylck = Lock()
# __init__
def __call__(self, sig, obj, *args):
self.entrylck.acquire()
self.Entries += 1
self.entrylck.release()
sleeptime = self.sleeptime
Entries = self.Entries
if 2 * Entries >= self.Expect:
sleeptime = sleeptime * (1.2 ** (Entries / self.Expect))
sleep(sleeptime)
# if
gtk.idle_add(self.apply, sig, obj, *args)
# __call__
def apply(self, sig, obj, *args):
obj.emit(sig, *args)
self.entrylck.acquire()
self.Entries -= 1
self.entrylck.release()
# apply
#Emittor
Emit = Emittor(14)
rndfl=file('/dev/random')
class Counting (Thread):
def __init__(self, Id):
self.Id = Id
self.ctrl = True
self.Running = False
self.ShowMode = 0
self.Time = 0
self.Value = 250
self.lock = Lock()
self.lock.acquire()
self.PRG = Random()
self.PRG.seed(rndfl.read(8))
Thread.__init__(self)
# __init__
def run(self):
def limit(x, sub, sup):
if x < sub:
return sub
elif x > sup:
return sup
else:
return x
# if
# limit
if not self.Running:
self.lock.acquire()
# if
while self.ctrl:
OldTime = self.Time
self.Time = OldTime + self.PRG.randint(1,20)
while OldTime < self.Time:
OldTime += 1
# while
#sleep(self.PRG.uniform(0.01, 0.03))
self.Value = limit(self.Value + self.PRG.randint(-5,5) , 0 , 500)
if self.ShowMode != 3:
if self.ShowMode % 2 == 0:
self.ShowValue = self.Value
# if
if self.ShowMode / 2 == 0:
self.ShowTime = self.Time
# if
#gtk.idle_add(canvas.emit , "update" , (self.Id, self.ShowTime,
self.ShowValue))
Emit("update" , canvas , self.Id, self.ShowTime, self.ShowValue)
# if
if not self.Running:
self.lock.acquire()
# if
# while
# run
def Start_Stop(self,ignore):
if self.Running:
self.Running = False
else:
self.Running = True
self.lock.release()
# if
# Start_Stop
def Modus(self,ignore):
if self.Running:
self.ShowMode = (self.ShowMode + 1) % 4
else:
if self.ShowMode == 0:
self.Time = 0
self.Value = 250
else:
self.ShowMode = 0
# if
#gtk.idle_add(canvas.emit , "update" , (self.Id, self.Time, self.Value))
Emit("update" , canvas , self.Id, self.Time, self.Value)
# if
# Modus
def Quit(self):
self.ctrl = False
if not self.Running:
self.Running = True
self.lock.release()
# if
# Quit
# Counting
Worker = [ Counting(i) for i in xrange(7) ]
S = range(7)
shuffle(S)
for i in S:
Worker[i].start()
# for
Rnd = Random()
Rnd.seed()
RowHght = 25
BtnSize = (75, RowHght)
#ColorScale = 65535
ColorScale = 3 * 65535 / 5
class Canvas(gtk.DrawingArea):
def __init__(self):
def On_Expose(canvas, evt):
gc = canvas.window.new_gc()
lb = canvas.window.new_gc()
cm = gc.get_colormap()
for i in xrange(7):
r = (i & 4) >> 2
g = (i & 2) >> 1
b = (i & 1) >> 0
color = cm.alloc_color(r * ColorScale, g * ColorScale, b * ColorScale )
gc.set_foreground(color)
canvas.window.draw_rectangle(gc, True , 75, (2
[pygtk] Re: yelp problem
> > The problem is that these two calls are not the same thing:
> >
> > gnome_help_display ("foo", NULL)
> > gnome_help_display ("foo", "")
[...]
> > > gnome.help_display ('pybliographer', '')
The correct way is to use None instead of '' and make None map to NULL.
We should also specify None as a default argument so you can simply
call:
gnome.help_display('pybliographer')
and everything should just work.
If None cannot be specified, it's a gnome-python bug that needs to be
fixed.
Could you please file a bug report?
--
Johan Dahlin <[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] Threading
On Wed, Jun 23, 2004 at 11:05:03AM +, Tiago Cogumbreiro wrote:
> I for one would like to see them :) A threading tutorial is always nice.
> Making demos out of the most common concurrent patterns would also be
> interesting.
All rigt here below is my first version of a multi-threaded pygtk
program. In this version I use gtk.threads_enter()/gtk.threads_leave
pairs when I want to draw something to the screen from within
a subthread.
Personnaly I would recommed against this method except if
your subthreads are very intensive in updating the screen,
the logic of your subthread is not to complcated and you
really need the speed.
The reason is the pygtk really can get in your way with
how it handles things. Look for instance to the Counting
class. There are two methods that will adjust the screen,
run and Modus. Now in run we use the threads_enter/threads_leave
pair but we don't in Modus. Why? Well because although Modus
belongs to the Thread object it really gets called by the
main thread through a signal handler and callback that are
connected are implicitly squeezed between a threads_enter/threads_leave
pair when called.
That is also the reason why the On_Delete method of Frame starts
with a threads_leave() call. Your sunthreads are likely to be
blocked by the threads_enter() call in run. So just Quitting
and joining the subthreads in On_Delete will very likely cause
a deadlock if you didn't call threads_leave() first.
So lots of things to look out for if you try it this way.
- demo1.py --
import gtk
import gtk.gdk as gdk
import pango
from threading import Thread, Lock
from random import Random, randint, shuffle
from time import sleep
rndfl=file('/dev/random')
class Counting (Thread):
def __init__(self, Id):
self.Id = Id
self.ctrl = True
self.Running = False
self.ShowMode = 0
self.Time = 0
self.Value = 250
self.lock = Lock()
self.lock.acquire()
self.PRG = Random()
self.PRG.seed(rndfl.read(8))
Thread.__init__(self)
# __init__
def run(self):
def limit(x, sub, sup):
if x < sub:
return sub
elif x > sup:
return sup
else:
return x
# if
# limit
if not self.Running:
self.lock.acquire()
# if
while self.ctrl:
OldTime = self.Time
self.Time = OldTime + self.PRG.randint(1,20)
while OldTime < self.Time:
OldTime += 1
# while
#sleep(self.PRG.uniform(0.01, 0.03))
self.Value = limit(self.Value + self.PRG.randint(-5,5) , 0 , 500)
if self.ShowMode != 3:
if self.ShowMode % 2 == 0:
self.ShowValue = self.Value
# if
if self.ShowMode / 2 == 0:
self.ShowTime = self.Time
# if
gtk.threads_enter()
canvas.Adjust (self.Id, self.ShowTime , self.ShowValue)
gdk.flush()
gtk.threads_leave()
# if
if not self.Running:
self.lock.acquire()
# if
# while
# run
def Start_Stop(self,ignore):
if self.Running:
self.Running = False
else:
self.Running = True
self.lock.release()
# if
# Start_Stop
def Modus(self,ignore):
if self.Running:
self.ShowMode = (self.ShowMode + 1) % 4
else:
if self.ShowMode == 0:
self.Time = 0
self.Value = 250
else:
self.ShowMode = 0
# if
canvas.Adjust(self.Id, self.Time, self.Value)
# if
# Modus
def Quit(self):
self.ctrl = False
if not self.Running:
self.Running = True
self.lock.release()
# if
# Quit
# Counting
Worker = [ Counting(i) for i in xrange(7) ]
S = range(7)
shuffle(S)
for i in S:
Worker[i].start()
# for
Rnd = Random()
Rnd.seed()
RowHght = 25
BtnSize = (75, RowHght)
#ColorScale = 65535
ColorScale = 3 * 65535 / 5
class Canvas(gtk.DrawingArea):
def __init__(self):
def On_Expose(canvas, evt):
gc = canvas.window.new_gc()
lb = canvas.window.new_gc()
cm = gc.get_colormap()
for i in xrange(7):
r = (i & 4) >> 2
g = (i & 2) >> 1
b = (i & 1) >> 0
color = cm.alloc_color(r * ColorScale, g * ColorScale, b * ColorScale )
gc.set_foreground(color)
canvas.window.draw_rectangle(gc, True , 75, (2 * i + 1) * RowHght ,
canvas.ThrdInfo[i][1] , RowHght )
canvas.layout.set_text("%8d" % (canvas.ThrdInfo[i][0],))
canvas.window.draw_layout(lb, 5 , (2 * i + 1) * RowHght + canvas.TxtPad ,
canvas.layout)
# for
# On_Expose
def On_Update(canvas, Results):
pass
# On_Update
gtk.DrawingArea.__init__(self)
self.add_events(gdk.BUTTON_PRESS_MASK)
self.set_size_request(600, 15 * RowHght)
self.layout = self.create_pango_layout("")
desc = self.layout.get_context().get_font_description()
desc.set_family("Monospace")
self.TxtPad = desc.get_size() / (2 * pango.SCALE)
self.ThrdInfo = [ [0 , 250
Re: [pygtk] Progress Cell Renderer
El vie, 25-06-2004 a las 02:20, David M. Cook escribió: > On Wed, Jun 23, 2004 at 11:39:21AM -0300, Gustavo Niemeyer wrote: > > > I haven't found this anywhere, so I thought someone else might > > be interested as well. Here is a cell renderer which mimicks > > progress bars, based on current gtk+ code. > > Has anybody done a cell renderer for combo boxes? > I did one of those... in C :) I thought that porting it to pygtk would be straightforward but problem is that my CellRendererCombo is a subclasss of CellRendererText and you can not subclass CellRendererText in pygtk and override the render and get_size methods. :( Lorenzo ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
