I don’t know if this question is on the right place but I try it here cause it is not mentioned to fvwm but trayer is implemented in FVWM-Crystal which is based on FVWM. So I hope someone know something about my problem
Ok here it is:
I have installed trayer 1.0 on my Debian system (Etch). I can start it under my FVWM 2.5.14, but if I open e.g. amarok and ‘close’ it (with the close button), no icon will appear in trayer. But amarok is running, cause music still plays
Not only trayer, but all the rest of dockers fails with most qt based applicatons. Its nothing bad about the docker, it is simply that qt based (and amongst them all the kde programs) uses a different protocol for the tray applications. I dont know if there is any workaround for amarok, I dont use it, but if the problem is the same that with the rest of qt programs, the I doubt. Solution: to live without the try icon, or to live without amarok.
Once KDE apps start adhering to the freedesktop.org trayer specification this problem should go away. I thought xystray did work with kde based apps though, but I’m not certain.
That xfce is freedesktop compliant, does not mean that it is limited to that only. KDE is also freedesktop compliant (or at least aims to), and also support kde system tray icons (not strange!). The problem is that, to deal with the kde system tray it is not sufficient to be freedesktop or ewmh compliant, because the mechanisn is totally different. You could try to use the xfce system tray under fvwm, but for sure that it would not worth the trouble, because you will have to run a lot of xfce stuff to archieve that.
I use stalonetray on fvwm-crystal. It have only X as dependency. It doesn’t have percentage support for the transparency, but stalonetray maintainer said me at it is possible to implement it with a FvwmButton. It is on my TODO list if I can figure out how to make it to work with --grow-gravity.
My bigest problem with stalonetray was at it was loosing most of the tray icons after a recipe change-restart. I get the same problem with trayer. My solution was to keep stalonetray alive during fvwm restart and restart it after. As example, for the Default Crystal recipe:
[code]# Settings of Trayer {{{1
AddToFunc “StartFunction” “I” Module FvwmCommandS
I changed a few things. I add the style in components/styles/FVWM:Style stalonetray UseStyle FvwmPartsHmm, this was easy.
And I use a FvwmButtons:[code]
Trayer width, the first number is the icons number, adjust it to fit yours needs
PipeRead ‘echo SetEnv trayer_width $((8*24))’
AddToFunc StartFunction I Exec exec killall stalonetray
Module FvwmButtons -g 24x$[trayer_width]-1+170 FvwmStalonePanel[/code]This is for the corner recipe. The “killall stalonetray” is maybe not so elegant, but it work. I don’t loose any icon when changing the recipe.
EDIT: I removed the ReSpawn option. It work fine without it. EDIT2: As I cannot figure out how it can be possible to make a FvwmButton with a dynamically variable size (I don’t even think at it is possible in this case), I modified the button with a variable.
(Kill, UseOld) seems to me like the best bet when dealing with applets and the like. Some WMfoo applets have a very weird behaviour sometimes, and I ended always with several instances of them on my htop listing. This way all seems to work ok. There is the little overhead of killing and restarting them, but well, it’s not a bid problem, and anyway in this case it IS the desired effect.
I dont know if there is any workaround for amarok, I dont use it, but if the problem is the same that with the rest of qt programs, the I doubt. ผลบอลวันนี้
