travis,
I do not know what you have under
/usr/share/adesklets, so it is hard for
me to pinpoint why you move things around in this fashion
(there is normally no need to): from what I read, it seems
yab was initially placed under this directory, which is
possible, yet undoubtedly unusual.
One thing is certain: you never, ever want to have any
directory named
$HOME/.adesklets (see A.2.6 from the
FAQ). Purge your home directory from everything
adesklets-related, and just install yab anew somewhere in it.
In a pseudo-terminal under X, being a normal user, this shell
snippet should do the trick on about any GNU-based machine,
provided adesklets is already properly installed
system-wide:
killall -9 adesklets python ; \
cd $HOME && rm -rf .adesklets ; \
wget http://dl.sourceforge.net/sourceforge/adesklets/yab-0.0.2.tar.bz2 -O - | bzcat | tar xv && \
yab-0.0.2/yab.py &
Yours,
_________________
Sylvain
Potential problem
this answer does not address:
I open a terminal, cd to the yab dir run ./yab.py and
because the process is spawned by a terminal, i just kill X
and go to init 3.
This puzzles me; I do not see how or why invoking an X client
(or any program, in fact) from a pseudo-terminal would cause
a system-V based system to change runlevel or cause the death
of X, unless the executable is explicitly written for this
purpose and have been given proper privileges, which is
certainly not the case with adesklets-based desklets such as
yab. When this happens anyway, it points out there is some
misconfiguration, bug or vulnerability lurking in the core
system that the offending program triggers.
At this point, I do not imply adesklets is not misbehaving,
but the system is clearly at stake, and not coping right
anyway under a given, unspecified condition, regardless of
adesklets. This said, I have successfully used adesklets
0.4.10 on a wide variety of platforms too, without ever
experiencing anything similar.