To my best knowledge, adesklets 0.4.10 is working right with any KDE >= 2.1... (I mean that this is the first report I have stating the opposite, and that I saw a screenshot on lynux.org featuring adesklets under KDE recently).

This said, I must admit I integrated the patch "blindly" (without having a chance to test it for myself) from the initial work by forum member yogi77 -- It has been reported from him to work right on KDE 3.3.2, and I do not believe the overall structure of KDE did change since then regarding this.

What happens if you relaunch adesklets from a pseudo-terminal in KDE once the initialization if completely over? Is the situation still the same (no desklets shown on the desktop)?

Mmh... By what you say your diagnostic is good. You are right about Gnome and XFCE doing something similar to KDE (in fact they both use the same "nautilus detection code") -- to bad KDE is just different enough not to be detected right this time. I will try to find the time to install KDE 3.4.1 on a test machine somewhere to try this -- maybe would we have some luck asking yogi77 about it.

But maybe can you give me the indications I need? Could you post both the result of xprop and xwininfo when you click on your desktop, as well as the result of xwininfo -root -tree ? Yours,

As mentionned, I also need the matching interactive output of xwininfo when you click on the desktop. Pleae regenerathe the three input at the same time. In bash:



Just click twice on your desktop, then email me again the content of wininfo.txt... Thanks,

Thanks for your help. I am really amazed at the support that you provide!!

I will be sure to promote this fantastic program whenever possible!

-Colin

I haven't fixed it yet... It is pretty trivial but it takes time do do better than a hack, and I lack it; I will try my best to find it soon.

window.c is in the src/ directory of the adesklets bzip'ed tarball.

yogi77, talking with colinnc, we determined a while ago that the window manager background structure changed somewhere around KDE 3.4.1, causing the fake root window detection routine for KDE to stop working out of the box. By your last message, I learn that the current structure of kwin is even slightly more complex, as it can apparently support an alternate, unspecified structure (no fake root window or previous KDE model, It would need to be investigated).

The fact that playing with the "show icons on desktop" makes adesklets grabbing behavior changes is unluckily a good indication something is fishy in the usage kwin does of the enlightment _XROOTMAP_ID ad-hoc specification in the "allow programs in desktop window" mode that adesklets rely on.

Thanks for the info. My initial plan to let the user specify the window id to be used as a root window from the command line still stands (see above), but I need to take the time to code it.

collinnc,

you still have to toggle off/on manually a seemingly unrelated KDE setting on every new X session to get the pseudo-transparency right, or did I get yogi77's explanation wrong? Yours,

Well, this is clearly a typo (corrected in repository, thanks). The function xwindow_updated_background() was initially made to be called from another context; this went unnoticed because the correct atom name is encoded in the unique calling function from adesklets.c.

I have KDE 3.4.1 and everything works if I do: but not if I do: but there again, perhaps it supossed to only work with the --kde flag.

Thanks for the update!

/Jaspal.

Works perfectly!

Thanks for the great work!!