I filed a bugreport to the audacious bugzilla a while ago about a rendering bug. I got a reply that said that “this is because the FVWM maintainers refuse to properly implement NetWM”. I’m just curious why this isn’t implemented, I guess there are some reasons.
And once again, I’m only curious, I’m not trying to start a flame war on implementing vs. not implementing. 
But FVWM does support NET_WM* – can you point me at the bug report in question to further understand what they mean?
– Thomas Adam
Might I suggest you pose this on the fvwm-workers mailing list (see fvwm.org) – I don’t think there’s anything wrong with FVWM’s NET_WM support at all, and it seems that Pitcock is more than reluctant to see reason to the point of being rude; I find his behaviour unacceptable.
– Thomas Adam
Well, I am not a master of anything around here, but I can only think that he just doesn’t have the reason because an informed developer would speak with facts and bits of code, and not with allusions at how bad, evil and arrogant the fvwm people are… Maybe it’s just me, but I don’t like that kind of attitude.
He claims that fvwm refuses to comply with the freedesktop standard. However, freedesktop people don’t think the same, because they list fvwm as one of the compliant wm’s on their own web:
freedesktop.org/wiki/Specificati … %2Fwm-spec
Maybe, only maybe, it could be more productive if both parts sit down and find the true problem. The fact that most wm’s work ok with audacious or xmms, don’t necessarily mean that audacious devs are right. Remember: a few centuries ago most people used to think that the people was flat, and it certainly is not. I am not stating that the problem is in audacious. I am just saying that it’s what it seems looking at the big picture.
I really think the Pitcock behavior is not acceptable, but maybe there’s something that I don’t know. In that case, he should also have provided links and proofs about all the claims he makes, about how bad fvwm devs are, and how compliant about net_wm they (the audacious devs) are.
If you are really interested, we should continue the discussion at the workers mailing list as Thomas Adam suggested in hist post above. That’s the official place that the fvwm developers use for this kind of thing. That would be more productive. Adding “workarounds” have never been the fvwm way. If it’s broken, then it must be fixed, and not worked around. And it must be fixed where the problem is. If the problem is in fvwm, then it should be fixed in fvwm. If the problem is not in fvwm, it should never be worked around in fvwm. If the application is net_wm compliant, and fvwm is net_wm compliant, then there shouldn’t be a problem. I really don’t know how compliant fvwm is in that regard, and any fvwm dev will give us a better insight about that.
Well, if it is just NET_WM* then FVWM is fully supported in that regard. It’s hard to be semi-EWMH compliant anyway. You either support all or nothing.
– Thomas Adam
Thanks for the info. I’ll make just one more quick question: looking at the ewmh.c file I find that there are some notes at the beginning about a few NET_WM* hints that needed to be implemented. I was wondering if that notes are still up to date (not that it’s related to this topic, I just feel curious in case you have some info about that).
Cheers.
_NET_WM_STRUT_PARTIAL – Used for programs which don’t want covering (c.f. EwmhBaseStruts).
The rest in there are self-explanatory – again, I see nothing pertinent there regarding Audacity. It really isn’t FVWM’s problem.
– Thomas Adam
Thank you, Thomas Adam.
Does this mean that it’s “solved” or should I still post it on the mailing list?
It means I see no reason why the audacious devs are bitching, which leads me to conclude that the problem isn’t with any of the NET_WM* at all but something else. I would advise posting to the fvwm-workers mailing list, referencing the bug report in question to see if anyone there has any ideas, although I suspect not – the problem still lies in audacious being buggy. Given Pitcock’s attitude I refuse to even look at the source for audacious to suggest what might be wrong.
– Thomas Adam
The problem is that we don’t know what needs to be solved 
Those posts above by me and Thomas was just me trying to get some info about the completeness about the net_wm stuff in fvwm, slightly off-topic here, and were not related to the problem.
As Thomas Adam suggest, I would still post on the fvwm-workers@fvwm.org mailing list, because the developers reside there. I am not an fvwm developers, and I have only looked at small pieces of the fvwm source code. I have never read anything about the problems with xmms (which is surely the same thing you are seeing in audacious) because I am relatively new as fvwm user. But this problem is not new, and the devs in the list surely knows what the problem is.
I really never bothered… There are way too much players for me to bother about getting xmms or audacious running.
Well I think it’s solved now. I upgraded audacious to v1.5.0 and everything renders just fine. I guess you were right…
Then might I suggest you try and get this piece of information into the Audacious FAQ:
audacious-media-player.org/index … e_laggy.21
And slap Pitcock whilst you’re at it.
– Thomas Adam
I think that’s another bug but I’ll point out that the rendering bug disappeared when I upgraded audacious to the developers.
Thanks. What’s the other bug then?
– Thomas Adam
Ah, right. Well, my own comments still stand in this regard. I wonder if it’s at all related to ConfigureNotify events? Hard to say, and I am not about to install audacious to find out.
– Thomas Adam
Well, that’s not much of a problem, it’s just to move the window with a fvwm function. It’s more of a problem when only half of the playlist is visible.
And besides, I don’t think I’ve moved the audacious windows in a year or so.
OK. Do you have a reference point to your mentioning to the Audacious developers that your upgrade to their latest unstable version fixed your issues?
– Thomas Adam