2009/8/28 Jesús Guerrero <[email protected]>: > On Fri, August 28, 2009 09:52, Viktor Griph wrote: >> 2009/8/28 Jesús Guerrero <[email protected]>: >> >>> News, >>> >>> >>> I compiled fvwm-2.5.27, restarted, and it works without a hitch. >>> So, it seems that, whatever the problem is (and I am not saying >>> it's in fvwm), it only happens with the current cvs. >>> >>> I don't know when did this start, I noticed it a couple or three >>> days ago. >>> >>> I am using pure cvs, no extra patches, not even the menu translucency >>> stuff. >> >> Test to reverse ewmh.c to the previous revision and see if the problem >> goes away. If so, please post the output of xprop for the firefox window >> with and without that commit. > > Eureka. > > With revision 1.77 of ewmh.c it works ok, all the dialogs come in > when invoked and the tab-bug doesn't exist. > > With revision 1.78 of that same file the dialogs doesn't come up, > and the bug exist. > > I attach xprops for both, as well as for 2.5.27, in case you have > some use for it.
I've made some quick look into this, and it is conflicting 64-bit fixes. (Double conversion to long from values assumed to be CARD32.) The change I made was to make ewmh_ChangeProperty operate in reverse of ewmh_AtomGetByName, which seems desirable. However most functions setting properties send long values to ewmh_ChangeProperty, but some don't (the _NET_WM_ICON updater for instance.) I'll look into and see how many properties which are both read (with ewmh_AtomGetByName) and updated (with ewmh_ChangeProperty) in which case conversion is needed before updating the properties. For those properties just set by fvwm the different approaches to the handling of 32 bit properties have no importance. I believe that it should be possible to set a property with ewmh_ChangeProperty to a value retrieved from ewmh_AtomGetByName, which means that either the conversions should stay, or they should be removed and the internal types should be changed to long values instead of CARD32. Just fixing the issue is simple, but doing it right requires some though. Any input on how to best handle this is welcome. I'll implement a fix for the current issue, but I don't want the discussion to end with that.
