Did you use a _XROOTPMAP_ID aware wallpaper setter? Esetroot, wmsetbg, feh, hsetroot, chbg, display (ImageMagick), qiv, xv, xsri, xli or xsetbg are all good.

If this is not the problem, I see from your screenshot you seem running a supplementary indirection layer (some vnc client I believe)... It could eventually interact strangely with adesklets, but I would need to investigate: do you experience the same discrepancy from a "native" X11 display?

fbsetbg is a wrapper script that uses the best program it can find installed on the system to perform the job; if it doesn't complain when you set up a new wallpaper from a pseudo-terminal (something like "program x doesn't set the wallpaper properly. Transparency for fluxbox and apps like aterm and xchat won't work right with it."), you are fine. Anyway, the fact that adesklets works OK from a native X11 server is the best indication everything is fine on this side.


Well, this is very likely where the problem lies; unluckily, I do not have any Windows operating system to test this, nor this specific X11 implementation... So I can only give you general pointers:

• 
  
• Try playing with the screen depth; maybe what you experience is a problem of a bad TrueColor => Colormap mapping. adesklets uses only TrueColor when available; it is possible TrueColor modes (24 or 32 bits depth) is detected on the server side, but just emulated at the end of the day (use xdpyinfo to have the information as detectable by adesklets).
  
• Is exceed only implement the server side of the protocol, or is there a special client to be run on the machine you export the X11 display from? If there is, you could need to adjust the depth there too.
  
• Maybe is the server just rootless; if this is the case, maybe is there an option in Exceed to emulate a root (Try xwininfo -root to have info about this)?

Sorry again for the relative vagueness of this help -- I hope you will find and fix the problem (let us now!). If you don't, maybe is there a way to ask the Exceed team about this? Anyway, It is possible to have a workable remote X11-based desktop from Windows station with adesklets: today you do have very fast, portable implementation for remove X11 access at your disposal as free software -- I know from others adesklets to works fine with many Windows or OS-X based vnc clients; If nothing else work, you can always rely on TightVNC to do the job. Yours,

Are you sure those links were not red in the first place? :wink:

Anyway, at least you found what went wrong with adesklets. and one way you can solve the problem (so I took the liberty to flag this as "SOLVED", even if it is not yet perfectly satisfying for you... It is still solved from adesklets perspective). This said, I find the explanation given in Exceed to be somewhat misleading: 32 bits visuals are no different from 24 bits ones from the application perspective; it will use the very same, internal neutral X11 API for all TrueColor visuals, and the 8 bits in excess are just left unused for everything that is not ARGB (and there is no ARGB visuals in adesklets)... If Exceed uses internal tricks to speed up things a little, overriding the normal mechanism, that's fine, but it has nothing to do with the applications themselves -- it is the duty of such a server to "do it right".

Yet, you could give alternate solutions such as TightVNC a try. How knows if it will not suit your needs as well? Apart from not having GLX, it is pretty good... and cheap too. :-)