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 youI 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]
