Johan, Gustavo: would this be breaking the API in subtle ways, or is it
a nice addition to PyGTK? Let's get a bug on it if the former.
In either case I don't like very much making the PyGTK API different
from the GTK+ one. Maybe there's a reason why only the pixel value is
returned. Perhaps GTK+ doesn't have RGB values at hand, and so looking
them up involves an extra X server roundtrip.
Can still be done lazily, if that turns out to be an issue.
In any case, if such change made sense to PyGTK, it would also make
sense to GTK+. Therefore, we shouldn't try to bypass GTK+ policy to
make this PyGTK-only; instead, we should just fix GTK+.
Now you're just boring. PyGTK provides a lot of things which GTK+
doesn't, and never will.
PS: for the same reason I don't like PyGTK treating string constants as
valid atoms, as it encourages people not to intern atoms, thus
introducing extra X server roundtrips; it makes no difference in win32,
but try running X11 apps through a modem and you'll know what I mean.
Well, one could argue that in most cases it doesn't matter. And when it
actually does it can easily be changed into an atom instead of a string.
Johan Dahlin
_______________________________________________
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/
