Eric Gillespie wrote:

>This is the second time i've had to deal with this broken
>interface, this time broken in a different way.  See
><http://www.daa.com.au/pipermail/pygtk/2000-October/000425.html>
>for the first time.
>
>What i ended up doing to work around that bug was this:
>
>from gnome.zvt import *
>from gtk       import *
>
>colors = [ (0, 0, 0),
>           (43690, 0, 0),
>           (0, 43690, 0),
>           (43690, 21845, 0),
>           (0, 0, 43690),
>           (43690, 0, 43690),
>           (0, 43690, 43690),
>           (43690, 43690, 43690),
>           (21845, 21845, 21845),
>           (65535, 21845, 21845),
>           (21845, 65535, 21845),
>           (65535, 65535, 21845),
>           (21845, 21845, 65535),
>           (65535, 21845, 65535),
>           (21845, 65535, 65535),
>           (65535, 65535, 65535),
>           (43690, 43690, 43690),
>           (0, 0, 0)
>           ]
>
>for i in range(len(colors)):
>    colors[i] = (colors[i],)
>
>win = GtkWindow(WINDOW_DIALOG)
>term = ZvtTerm(80, 25)
>term.set_color_scheme(colors)
>term.show()
>win.add(term)        
>
>win.show()
>
>mainloop()
>
>Ugly, but it worked.  Now i'm having to do this again and
>i discover that the interface has changed yet again.  Running
>that program merely gives me this error:
>
>Traceback (most recent call last):
>  File "fuck.py", line 29, in ?
>    term.set_color_scheme(colors)
>  File "/usr/pkg/lib/python2.1/site-packages/gnome/zvt.py", line 66, in 
>set_color_scheme
>    _zvt.zvt_term_set_color_scheme(self._o, color_list)
>TypeError: list items must be like (int,int,int)
>
>Strangely, eliminating the for loop doesn't change the error
>message!  I'm very confused.
>
>1) How can i work around this?
>
>2) Will this interface ever be repaired properly?
>
>Thanks in advance.
>
There is a fix for this in CVS now (I checked it in a few days ago). 
 The colour components are meant to be unsigned shorts, and I was using 
PyArg_ParseTuple's "h" format character to read the tuples. 
 Unfortunately this is for reading signed shorts, so any number greater 
than 0x7fff (32767) would cause the above exception.

Until the next release, you can work around the bug by subtracting 
0xffff from the larger numbers (the negative ints will be treated as 
ints > 0x7fff).

James.

-- 
Email: [EMAIL PROTECTED]
WWW:   http://www.daa.com.au/~james/



_______________________________________________
pygtk mailing list   [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/

Reply via email to