Some sensors (e.g. the LTVCpu sensor from the LTCandy package) access
the GUI from within a thread. That is a very _bad_ thing and gDesklets
crashes.
It worked on most systems in earlier versions because gDesklets didn't
initialize threads properly before 0.25.

It is now up to the sensor authors to fix their sensors.

*** Bug 130156 has been marked as a duplicate of this bug. ***

Seems like all desklets using the LTVBorder sensor (from LTVariations
package) are affected too.

As I have *zilch* experience in Python, I was wondering how cumbersome
it would be to fix the LTVBorder code : I compared it with valid code
(e.g. from the CPU sensor), but as this is a (probably non-updating)
border, I do not know whether I should specify intervals or not.

Another option would be to recode the affected applet (in my specific
case : SpeedfreqMon 0.2) to use the psi theme instead of LT.

I suppose I sound quite clueless.  :)

The point is that _send_output() must not be called from within a
thread. The clean solution would be to use a thread safe queue
(Python has the module Queue for this) and put the output in the
thread into the queue. Using a timer, you can check if the there's
something in the Queue then and send it to the core with _send_output().
It may be wise to delimit the queue to hold at most one element in
order to avoid jamming.
The SysInfo sensor e.g. shows how to do it.