On Tue, 2008-08-05 at 16:15 +0100, Emmanuele Bassi wrote:
using python on win32 to call the x11 API - and vice versa. I can
prevent people to compile it on different platforms, by #ifdef'ing
everything out using the defines Clutter provides, or using the
clutter-${platform} pkg-config file. but depending on the platform you
I think so long as it compiles properly on the platform, and there is a
way to detect what platform you're running on (which is trivial), that's
sufficient. I don't see it as necessary to hide functions in clutter
that aren't available on the platform if that's not an easy thing to do.
might have the X11 texture-from-pixmap or the GLX texture-from-pixmap,
and that is going to be a pain to differentiate.
Doesn't the GLX tfp fallback to X11 if there is no GLX support for it?
and this is the other issue: I don't want to start maintaining Xlibs
bindings for python. if you start adding X11 types people will start
requesting weird functions - like changing the X cursor, or other crap.
I barely have time as it is to maintain pyclutter - maintaining
python-cxlibs is completely out of the question.
I'm quite sympathetic to this. For Freevo, we maintain our own X11
Python bindings called kaa.display.
Where the X objects you want to pass between kaa.display and clutter are
simple X ids, like Windows, I see this very easy to support. X ids are
just uint32 values. I also made a mistake about Pixmap: I thought it
was an opaque structure, but it's an XID like Window, which simplifies
things considerably. (I can therefore rework the patch and remove this
complexity, if I can first convince you that it's useful to have this
support in pyclutter.)
For opaque X11 types I fully understand your resistance. But if the X
object can be represented trivially by a Python object (a long object),
I think the argument against support it is ought to be much more muted.
the third and final issue is: are you really going to use Python for
something that relies on texture-from-pixmap? the only applications I've
seen using this extension are window managers.
We are indeed. The first use-case is getting external video players
(such as MPlayer) onto a clutter stage. I have tested the patch with
this use-case and it works. I've done quite a bit of PoC work and I'm
satisfied that this is a viable approach.
Future use-cases will involve, for example, supporting xmame or a web
browser, which has obvious value on an HTPC platform.
The immediate appeal of TFP for us is that it doesn't require patching
these applications (like MPlayer, which I desperately want to avoid if
possible).
this is not to say I won't accept a patch that implements
platform-specific API; if anyone comes up with the patch addressing the
first two concerns
The first concern seems primarily technical, which can be resolved with
appropriate configure-time checks and ifdefs, as you suggested. This
seems sensible to me.
As for the second concern, which is more philosophical, I think I
addressed it above. If we limit the scope of the platform-specific
approach to be anything that is easily representable by a python
object, such as XIDs (which both Window and Pixmap are), would that be
acceptable?
Even opaque structures can be represented easily by PyCObjects, but if
that starts you down a direction you're not comfortable with, I won't
object given that I apparently don't really need it for this patch. :)
and a use case for the third that is not implementable using some C
and a python wrapper, then I'll gladly apply said patch.
It seems to me that this requirement automatically disqualifies, well,
anything. Obviously any functionality is implementable using some C and
a python wrapper. The entire point of having the tfp support in
pyclutter is so that I won't have to do this.
I will of course go that route if I have no choice. I understand that
not supporting the platform-specific features of clutter makes pyclutter
easier to maintain, but it also reduces its utility.
Cheers,
Jason.
--
To unsubscribe send a mail to [EMAIL PROTECTED]
