Next: , Previous: Help wanted!, Up: Top

Appendix A Frequently asked questions

Last update: 30 March 2006

A.1 Compiling adesklets

The adesklets configure script says my Python install is too old, but it's not. What's the problem?

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.

A.2 Installing desklets

I find the default desklets installation method tedious: it there a simpler way to install them?

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.

Well, that's kinda better, but it is still not fully automated (I hate reading and understanding new things, you know)...

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.).

A.3 Starting and stopping desklets

When I try to start a new desklet, I get an ImportError: No module named adesklets error 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.

When I try to start a new desklet, I get an ADESKLETSError: adesklets process exited error 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 the 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:

     ./configure --prefix=/usr

I cannot run any Python-based desklet: I get garbage collection errors!

If you get errors similar to:

     python: Modules/gcmodule.c:275: visit_decref: Assertion `gc->gc.gc_refs != 0' failed.

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 usually solves this.

Desklets start fine as root, or as local user account, but just freeze or exit on NFS-mounted accounts

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/ 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.

Everything worked fine but then I tried upgrading a desklet, and I couldn't ever see the new one. What is wrong?

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.

Gosh! The desklet X is working, but does not remember its settings, or it always starts on the top left corner of screen 0 on a new X session. What is that? It sucks!

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.

This is exactly what I did, but the darn thing wouldn't restart anyway.

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).

Starting the desklets works fine, but they continue running when I terminate the X session.

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

     adesklets --killall

command somewhere from the session exit.

A.4 Displaying desklets

Where are my desklets? adesklets interpreters seem to be running fine, but I just cannot see anything on my desktop (the so-called flickering problem)!

Try the command:

     python test/

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:

     adesklets --help

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.

What about enlightenment?

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 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.

Now I see the desklets, but the transparency is screwed!

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.

I cannot see smaller desklets such as xmms_bar or asimpleclock, while others work. What gives?

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.

I am running Fvwm as my window manager. Why can't I keep the desklets below all my other windows? They keep popping on top!

Go see the Fvwm faq: This BugOpts RaiseOverUnmanaged on option was reported to work for many Fvwm users.

I am so tired of hitting the desklets context menu when all I want is my windows manager's! Can I do something about it?

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.

A.5 Running desklets

The 'Configure' item from the context menu of many desklets doesn't work!

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.

Can the 'Configure' item from the context menu invoke a non console-based editor?

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.

Do you plan including SVG support? I would like to use a SVG image in one of my desklets.

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.

I would like to use some of my system's fonts with adesklets, but I cannot get my desklets to find them. What should I do?

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: => /usr/lib/ (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, man 5 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' ... above.


[1] Thanks to Stefan Jungcurt for the hint.

[2] Although you can get back the old behavior if you wish by using --enable-legacy-fake-root-window-detection at configuration time. See Installing adesklets.