Last update: 30 March 2006
Some platforms (NetBSD, Ubuntu Linux, probably others too)
sometimes alter the Python version, appending letters, prefixing
minor numbers, etc., thus preventing the configuration script
from detecting it properly. If you know for sure
that what you have installed is at least 2.3.0, you can pass the
--with-python-force-detection switch to
configure; this will make the configuration script
skip the version detection.
From adesklets 0.5.0, you have a new adesklets_installer script (See Using adesklets.). It can help you download and unpack new or updated desklets.
True. adesklets_installer just notify you of updates, download, check and unpack desklets, but it is still your duty to see their README, fulfill their requirements, start, stop and configure them.
But frankly, it is that difficult? Most people does not change their desklets settings very often anyway. This is was deliberate choice from our part: the goal of adesklets has always been to minimize overall code complexity, leading to a leaner, tighter, more consistent package. Why solving in a long, tedious, hard to write and maintain software all the corner cases a smart user can figure out in minutes with proper documentation?
If full automation is what you crave, have a look at the alternatives to adesklets (See About adesklets.).
ImportError: No module named adeskletserror from the Python interpreter. What's happening?
It means what is written: python cannot find the
adesklets package; maybe it did not get installed,
or it did get installed in the wrong place.
sed -n '/PYTHON_SITE_PKG/p' Makefile
is included in :
echo 'import sys; print sys.path' | python
If not, you can still manually move the
adesklets directory from
PYTHON_SITE_PKG to any
path displayed by this last command.
ADESKLETSError: adesklets process exitederror from the Python interpreter. What is this?
This is a generic error telling you something is off with the low-level interpreter, critical enough to cause it to exit. If you are lucky, you will have at the end of the line a dash, followed by a descriptive message telling you what went wrong. In that case, if you have difficulty understanding it, just seek help online. If no clue is given to you regarding the error origin, try this from a pseudo-terminal under X:
echo x_status | adesklets :
You should normally get something similar to:
event: ready! command 0 ok: x_status 1 (connected to ':0.0')
If you do, you are probably using a system (archlinux for instance), on which
PATH variable for the Python interpreter differs
from what is inherited from standard environment, which causes
the Python package to fail to launch adesklets as a child
process. On such systems, make sure to install adesklets using an appropriate
--prefix switch at the configuration stage. For
instance, on most recent Linux platforms, you should use:
If you get errors similar to:
python: Modules/gcmodule.c:275: visit_decref: Assertion `gc->gc.gc_refs != 0' failed. Aborted
It means your installment of Python has a corrupted garbage collector; it is often caused by incorrect or aggressive optimization during the compilation. Just recompiling a stock python environment from http://python.org/ usually solves this.
adesklets needs to be able to lock some files under
$HOME for working reliably: most problems with
network file systems are due to semi-functionning installment
failing to honour such locks. You have a short script under
test/flock.py in adesklets source tarball that
provides a simple test of fcntl locks; its normal behavior is to
acquire a lock in the current working directory, wait for the
user to press a key, then release it and exit. You can launch
multiple instances of the script from the same directory to
verify that the locking is indeed working. If not, making it work
will very likely make adesklets work too.
There is a built-in lock mechanism in the interpreter that
prevents a user from simultaneously running more than one desklet
with the same
ID and name, regardless of version.
Whenever you upgrade a given desklet, you should first cleanly
quit the desklet (by using
Quit from the context
menu), then install the updated desklet by following the
instructions provided in the README file.
This is most probably related to the way you started the desklet (Please see Using adesklets.). You need to invoke the desklet script only once. Afterwards you just need to run the command:
and it will remember where you placed your desklets and which desklets you had running. Do not forget the pass flags to adesklets, as appropriate.
Did you store the desklets under a $HOME/.adesklets directory? Please don't. adesklets need a $HOME/.adesklets file to store the various user settings on running desklets; setting up a directory of the same name prevents it from doing its job right, so just move your directory some place else ($HOME/.desklets, for instance).
Normally, the desklets are supposed to be automatically terminated on the dead of the session. If you have the frontend shell server installed (the default), you can also kill them manually by invoking the
command somewhere from the session exit.
Try the command:
from the base source directory. If a 100x100 window appears when testing the desklet, it most probably means you are using a window manager that draws a big window (so called “fake” root window) over the root window; your desklets are just drawn below it. Such window managers include Nautilus, KDE, Xfce4, CDE, e16 version 0.16.8 and later, or e17. As on adesklets 0.6.1, supported window managers in that category are:
From adesklets 0.4.11 and onward, the fake root window detection method had changed: it is no longer part of the C code by default2. The interpreter now expects the ADESKLETS_ROOT environment variable to contain the correct fake root window hexadecimal ID, if any. You can of course set it manually, but a shell frontend will be handling most common window managers for you (see list above), as long as you instruct it to. Try invoking:
If the shell frontend is installed, you will get many options, including how to trigger window managers specific fake root window detection routines. You also have a “generic” fake root window detection under the switch --user: it could work (or not) for you, depending on the structure of your window manager. Finally, please note the frontend is a simple sh-compatible script, installed by default under $prefix/share/adesklets – it should be pretty straighforward to modify by anyone wishing to implement other detection schemes.
It is also good to remember that fake root window detection obviously requires such windows to exist. It is therefore important to invoke adesklets after the window manager is reasonably initialized. To help you do this, you have at your disposal a -w progname switch in the shell frontend.
adesklets works as expected with e16 as long as you do not enable features causing the use of fake root windows (see previous question – you need to use the –e16 switch for e16 version 0.16.8 and later), hiding in some circumstances the desklets behind the Window Manager structure. In the author experimentation with versions 0.16.7.2 and 0.16.8, it is only possible to see the desklets in the first virtual desktop. This said, in enlightenment lingo, virtual desktops can span on many “screens” (four, horizontally aligned by default), making perfectly possible multiple workspaces usage while keeping adesklets' desklets in sight.
As for e17, it is unsupported. If you insist, you can find more hints on this in enlightenment FAQ . This said, e17 comes with something called “e17 modules” (engage, etc.), that work great under this WM and fill the same niche.
Proper pseudo-transparency relies on the capacity to grab the background image as well as getting notified when it changes. There is no entirely reliable or even well established method to do this on anything but the real root window using the core X11 protocol (please read from the beginning of this “Displaying desklets” section to full understand what follows).
Hence, even when using a fake root window, adesklets always grabs the background from the real root window, no matter what: some windows managers are careful enough to ensure the synchronisation of the fake root window and the real root window at all time, but not too many. adesklets does its best, when portably possible, to synchronize on initial load the background of the real root window with the one of the fake root window, but in some supported cases (ROX-Filer, xffm-desktop), this is not even possible. Therefore, if you experience screwed-up backgrounds (no background at all, incorrect backgroud or background not reflecting the latest change you made, while you effectively see the new wallpaper in a fake root window), all you need to do is to duplicate the wallpaper set on the real root window, preferably using a wallpaper setter supporting the ad-hoc, widely supported enlightenment mechanism for wallpaper change notification – any of Esetroot, wmsetbg, feh, hsetroot, chbg or xsri should work fine. In fact, you can even use any wallpaper setter to change the real root, but then you could have to rerun the adesklets launcher afterwards to take advantage of a correct initial background grab if no notification was sent.
New desklets are always started in the leftmost, upper corner of the screen, at the very bottom of the windows stack. Make sure you do not have some elements (gnomebar, engage, etc) already masking this zone of the screen. Beware! Some applications use pseudo-transparency, and can mask the root window seamlessly.
Go see the Fvwm faq: http://www.fvwm.org/documentation/faq/#5.11.
BugOpts RaiseOverUnmanaged on option was
reported to work for many Fvwm users.
Invoke the --enable-control-on-context-menu switch at configuration time. This way, normal left click on a desklet should trigger your windows manager menu in most cases (tested on Xfce4 and *box derivatives). In all cases, you will need to press control at the same time to trigger the desklet context menu.
For this to work–at least for all the demo
desklets–you need to have xterm installed, and the
EDITOR variable properly set in your environment, as
it is customary in UNIX. Please note this only launches a text
editor in a terminal. Editing the desklet's configuration file
(usually config.txt from
base desklet directory) has the same effect.
Yes, why not? Since adesklets 0.5.0, there is a facilitating wrapper to automate this in the shell frontend: see the adesklets -e (editor) switch.
No we do not, sorry. It is not that SVG is a bad format; in fact it is quite good. But it is also a vector-oriented one (and rather complex), while Imlib2, on which adesklets relies heavily, is completely raster-oriented, and using Imlib2 is the main reason for adesklets' simplicity, relatively good speed and low resource usage.
That said, there is no reason for you not using SVG's with desklets, since it is quite easy to convert images in SVG to high quality PNG's, using programs such as sodipodi , inkscape or xsvg . In a directory full of SVG's, on a GNU system you can use a command such as:
ls *.svg | sed 's/\(.*\).svg/-z --file=& --export-png=\1.png --export-width=128 --export-height=128/' | xargs --max-lines=1 sodipodi
to convert them all to 128x128 semi-transparent PNG's.
First, you need to have fontconfig support enabled in adesklets. See the config.log from the configuration phase to verify it. If you did not keep the log, you can also look at the dynamic libraries linked against the interpreter. On a system with GNU binutils, you can do something like:
ldd `which adesklets` | grep fontconfig
If you get output similar to:
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x45c75000)
it means everything is fine. Otherwise, you should recompile adesklets from source. From there, you can use the line:
echo 'list_font_path' | adesklets :
to see all the font directories that adesklets will into look
for TrueType fonts. Consult your fontconfig documentation to
learn how to change this (on up-to-date systems,
fonts-conf is a good starting point). Similarily:
echo 'list_fonts' | adesklets :
Will give you all the fonts that are currently found... Keep in mind when typing them that font names are case-sensitive.
Alternatively, if you just cannot get fontconfig to work, a
way to get around the problem would be to create symbolic links
to the fonts you want to use inside any absolute font paths
listed by the command
echo 'list_font_path' ...