Read this article here

I sure hope this is true, since I know python quite well but shiver when I look at Compiz Fusion plugins' codes, despite the fact that I would LOVE to write my own.

In addition, I think that knowing how to code in Python would help introduce C(++) newbies like me into the world of (faster?) C and C++ programming for Compiz. I don't think I could start on a C app for compiz, but a Python app would be good because I wouldn't have to worry too much about syntax (knowing Python already).

I had thought someone had already started on that, but that it no longer works with the current code? Was I wrong?

--Gavin L. (gavintlgold, the FusionCast guy)

Smileys:
Bold	Underline	Italic	Strike Out	Color	Image	Link	\/	/\	Go Advanced	MCE

I sure hope this is true, since I know python quite well but shiver when I look at Compiz Fusion plugins' codes, despite the fact that I would LOVE to write my own. In addition, I think that knowing how to code in Python would help introduce C(++) newbies like me into the world of (faster?) C and C++ programming for Compiz. I don't think I could start on a C app for compiz, but a Python app would be good because I wouldn't have to worry too much about syntax (knowing Python already). I had thought someone had already started on that, but that it no longer works with the current code? Was I wrong? --Gavin L. (gavintlgold, the FusionCast guy)

@Gavin: There's an empty project in git from the Beryl days, so I think someone thought about it but dropped out before getting anywhere.

mikedee worked in python plugins long time ago. dont know where is he.

Smileys:
Bold	Underline	Italic	Strike Out	Color	Image	Link	\/	/\	Go Advanced	MCE

mikedee worked in python plugins long time ago. dont know where is he.

Hmm, interesting timing. I came across the existing compiz-python code in freedesktop git a while ago and decided to update it to work with current Compiz (and generally fix it up while I was at it). This got slightly out of hand, according to git:

Your branch is ahead of 'origin/master' by 323 commits.

and an equally huge diffstat (changing most of src/, some of it for no good reason).

The result does sort of work though (I updated the example plugins that came with it, and those mostly work). And the resulting plugins look a lot less intimidating than c plugins, partially because of the language difference, partially because a lot of boilerplate is pushed off to the C code. You can just define "class Screen(compiz.PythonScreen): ..." with a paintOutput method and the bindings create one instance per compiz screen for you and wrap paintOutput.

Running Python code every frame should work just fine performance-wise, as long as that code does not do much. One of the working example plugins lets you rotate the cube with the mouse (yes, duplicating a feature of the builtin "rotate" plugin). This is quite smooth (and involves wrapping screen painting). The trick is that you do not want to run Python code per (say) pixel of the screen per frame. As long as the work done by actual python code is minimal the performance impact is quite acceptable.

A bigger problem than performance is memory and error handling.

Most of the stuff compiz passes around is not refcounted, and currently the bindings do not try to figure out when python wrapper objects should be invalidated because the underlying compiz object went away (I'm talking about things like the CompTransform passed to paintOutput here). So currently Python code storing objects longer than they should crashes. This is actually not a problem in practice so far, but that may be because I know what I can and cannot get away with without crashing...

I think I need to rework the way some of my wrappers work. For some of them (like paintOutput) it is rather important that the next method in the chain gets called once. Currently a malfunctioning python wrapper can cause compiz to stop drawing while spewing tracebacks to the terminal (for bugs where c plugins would just crash). This is surprisingly annoying (I have started running "sleep 10s && killall compiz" before trying some new python plugin code, just to reduce the chance I get stuck with no drawing and/or the keyboard grabbed). And I cannot just have my c code call the next method in the chain when the python function fails, because python might have failed after it already called the next method in the chain, and calling it twice might not be sane. I do not know enough about the c api to know what solutions could work here. I could have one function running before the next one in the chain and one after, but I do not want to limit python code here, so that only works for functions where the next one in the chain absolutely always gets called exactly once.

I'm not quite ready to release this thing, but expect a working (something between alpha and beta) version soon now. Most of the code looks good to me, I need to clean up and fix a few more (small) things, perhaps add a few more small demo plugins (to test more of the code) and update the documentation (this will take some time). Then I'll do a release because I get the feeling I'm not the only one who wants to experiment with this.

Smileys:
Bold	Underline	Italic	Strike Out	Color	Image	Link	\/	/\	Go Advanced	MCE

Hmm, interesting timing. I came across the existing compiz-python code in freedesktop git a while ago and decided to update it to work with current Compiz (and generally fix it up while I was at it). This got slightly out of hand, according to git: Your branch is ahead of 'origin/master' by 323 commits. and an equally huge diffstat (changing most of src/, some of it for no good reason). The result does sort of work though (I updated the example plugins that came with it, and those mostly work). And the resulting plugins look a lot less intimidating than c plugins, partially because of the language difference, partially because a lot of boilerplate is pushed off to the C code. You can just define "class Screen(compiz.PythonScreen): ..." with a paintOutput method and the bindings create one instance per compiz screen for you and wrap paintOutput. Running Python code every frame should work just fine performance-wise, as long as that code does not do much. One of the working example plugins lets you rotate the cube with the mouse (yes, duplicating a feature of the builtin "rotate" plugin). This is quite smooth (and involves wrapping screen painting). The trick is that you do not want to run Python code per (say) pixel of the screen per frame. As long as the work done by actual python code is minimal the performance impact is quite acceptable. A bigger problem than performance is memory and error handling. Most of the stuff compiz passes around is not refcounted, and currently the bindings do not try to figure out when python wrapper objects should be invalidated because the underlying compiz object went away (I'm talking about things like the CompTransform passed to paintOutput here). So currently Python code storing objects longer than they should crashes. This is actually not a problem in practice so far, but that may be because I know what I can and cannot get away with without crashing... I think I need to rework the way some of my wrappers work. For some of them (like paintOutput) it is rather important that the next method in the chain gets called once. Currently a malfunctioning python wrapper can cause compiz to stop drawing while spewing tracebacks to the terminal (for bugs where c plugins would just crash). This is surprisingly annoying (I have started running "sleep 10s && killall compiz" before trying some new python plugin code, just to reduce the chance I get stuck with no drawing and/or the keyboard grabbed). And I cannot just have my c code call the next method in the chain when the python function fails, because python might have failed after it already called the next method in the chain, and calling it twice might not be sane. I do not know enough about the c api to know what solutions could work here. I could have one function running before the next one in the chain and one after, but I do not want to limit python code here, so that only works for functions where the next one in the chain absolutely always gets called exactly once. I'm not quite ready to release this thing, but expect a working (something between alpha and beta) version soon now. Most of the code looks good to me, I need to clean up and fix a few more (small) things, perhaps add a few more small demo plugins (to test more of the code) and update the documentation (this will take some time). Then I'll do a release because I get the feeling I'm not the only one who wants to experiment with this.

See http://forum.compiz-fusion.org/showthread.php?t=10277 for a snapshot of the fixed up bindings mentioned earlier.

Smileys:
Bold	Underline	Italic	Strike Out	Color	Image	Link	\/	/\	Go Advanced	MCE

See [urls]http://forum.compiz-fusion.org/showthread.php?t=10277[/urls] for a snapshot of the fixed up bindings mentioned earlier.