Granted, pipes and signals are certainly the lowest possible form of IPC, which is great for portability, but they are also the most inefficient.

Nevertheless, on my home machines, pipes limit the commands rate around 3KHz though Python, and 3000 commands per seconds is an order of magnitude bigger than the number of non-void commands my CPU can handle (which is between 100 and 500 commands per second in my experience), notwithstanding that there are others reasons for using pipes and signals: debugging simplicity, language neutrality, direct user access to the interpreter, etc (see the "Extending adesklets" chapter of current documentation).

This said, wouldn't a library around adesklets be somewhat pointless? adesklets was built as an interpreter to provide an intertactive, easy interface to imlib2, good enough to build midly interactive desklets; if you need sheer speed in C, and not a commodity interface, I see no compelling reason for using it rather than linking right to imlib2...

I am pretty sure that writing desklets in C has its advantages over Python in term of speed, but I do not think your diagnostic to be accurate. The fact that things are smoother with C is no indication whatsoever that the problem is IO-bound. I put quite a bit on syntatic sugar in my demo Python bindings to give command a pythonic look and feel, and it comes at a cost, as many intermediate values are computed on the fly for every command submitted...


I do not know what you tried animating, but direct mode of execution will never be suited with adesklets for any kind of smooth (i.e. regularily spaced in time) animation, the reason being that the interpreter is by nature asynchroneous, and you cannot (should not) rely on it to get precisely timed roundtrip between successive commands.That's why adesklets have an indirect mode of execution, giving the possibility to 'replay' a variation of pre-registered commands in a single invocation (see test/fading.py for instance). You most probably get smoother results because your C desklet does very little work compared to the Python version to issue commands, hence a lower-overhead, and a far decreased possibility to be put to sleep by the scheduler at inappropriate times; that doesn't mean the effect you seek could not be achieved in other ways.



Yes... I guess you are right about that, I overlooked the session management aspect. As for dealing with xlib, it is pretty simple regarless of adesklets.



Almost true. The problem is that we would imperatively need to wrap all calls anyway, because imlib2 provides no automated regitrering of drawable dirty spots; for every call to imlib2, we need to make sure we know what was changed on screen. Refreshing the complete window at each step is simply not an option performance-wise. A lot of the pseudo-transparency management details are also hidden everywhere. So, while it is very straigthforward to use imlib2 from C knowing your specific task, it is not that simple to wrap a generic dynamic console.

Moreover, making a good truely single-process C library would go deeper than the pipe issue, as synchroneous/asynchroneous API are very different beasts, so it would not be a simple matter of wrapping actual calls in a C-level library, tons of small details would need to be reconsidered.


Well, it is your take on it. These things are in my opinion far easier in higher-level languages, but let's not start another war. ;-)


Granted, I am pretty sure you are right about C being able to produce a broader class of desklets, namely those with animations that cannot be precomputed in any reasonnable way (far less frequent than one might think): for the rest, using indirect mode does the trick. As for desklets being easier to write in C, regardless of a library, well, I guess it pretty much depends on your background. ;-)

OK... In some circumstances, nothing prevent you to use indirect mode for mouse-driven effect... Look at yab: this is what happen with the caption drawing. But I totally agree that using MouseMove events from python, for instance, certainly limits the time one has to process a single event, and it is quite probable fewer commands can be processed before the next event gets called than from C, or from python with a more raw wrapper.



No one, you mean. ;-), the delayed event marking being purely a convenience of higher level python module. It has nothing to do with the interpreter.



True. And PyGTK is a space hog I personally avoid at all cost. :-)



Of course. Look at the Calendar desklet.



Wrapping the calls is not a daunting task, as long as we follow the present structuration. All pertinents prototypes are in scripting/prototypes...

I did my experimentation too. Maybe this could help (also in the code repository). Of course, it doesn't make the python module more responsive by itself, but it does provide a way to get finer control over what we choose to discard when we need too. In term of 'smoothness' it should pretty much solves any problem when properly used.



Well, adesklets is using override_redirect (i.e non-modal) windows. This is stricly incompatible with most XWindow toolkits, including GTK, for most focus-related operations (so pretty much everything keyboard and pointer related when we would use widgets)...