bug#31650: 26.1; Desktop mode adds wm stickiness to emacs windows.

[Rolf Ade]

martin rudalics <rudalics@gmx.at> writes:
> Sorry.  I initially meant you to try with
>
> (let (sticky-frames)
>   (dolist (frame (frame-list))
>     (when (frame-parameter frame 'sticky)
>       (setq sticky-frames (cons frame sticky-frames))
>       (set-frame-parameter frame 'sticky nil)))
>
>   (when sticky-frames
>     (message "The following frames were found sticky: %s" sticky-frames)))
>
> which should _avoid_ making a frame inadvertently sticky during
> checking

Yes, this avoids making the frame (I start with -Q) sticky.

> but then I decided that it would be better to evaluate just
>
> (set-frame-parameter nil 'sticky nil)
>
> in order to _provoke_ making a frame sticky

Yes, this makes the frame sticky; I tried this already.

> (this should explain where
> the two extraneous right parentheses come from).  Evaluating the
> latter does no change the stickyness of the emacs -Q frame here
> (Debian with Xfce 4.8 and xfwm4).  Since with a single frame doing
>
>> If I start emacs -Q and evalute just
>>
>> (dolist (frame (frame-list))
>>    (set-frame-parameter frame 'sticky nil))
>>
>> in the scratch buffer then, yes, this also puts the frame into sticky
>> mode.
>
> is equivalent to my single-line form you already confirmed that
> setting the paramter to nil makes your frame sticky.  Hence our
> systems apparently behave differently.  I suppose that evaluating
>
> (set-frame-parameter nil 'sticky nil)
>
> repeatedly makes your frame sticky the first time and does not change
> ("toggle") its stickyness afterwards.  Right?

Yes. This makes the frame sticky and doesn't change it afterwards.

> And I also suppose that
>
> (set-frame-parameter nil 'sticky t)
>
> behaves just the same as with nil.  Right?

Yes.

>> But I'm unsure what information could help to understand the problem (I
>> guess, the values of the function parameters?) and how to gather them in
>> a way that provide insight.
>>
>> I'd appreciate more detailed hints what (and how) I should look for.
>
> I'm unsure as well.  If I set a breakpoint in set_wm_state and
> evaluate
>
> (set-frame-parameter nil 'sticky nil)
>
> in the debugged emacs, then doing
>
> p add
>
> in the debugging emacs prints false

Yes, it does.

> while doing
>
> (set-frame-parameter nil 'sticky t)
>
> in the debugged emacs has
>
> p add
>
> print true instead.

Yes, it does.

> I suppose you see the same.  The next thing we
> could check is whether setting a breakpoint at cons_to_x_long in
> x_fill_property_data does produce a val of 0 for setting the parameter
> to nil and 1 for setting the parameter to true (it does so here).

Hopefully I've done this right ... If I did then: yes, I see the same.

> And one other thing to check is: When you set stickyness via the
> window manager, does the 'sticky' parameter of your frame reflect the
> actual state correctly?

Yes, it does. After starting emacs -Q (and frame is non-sticky)

(frame-parameter nil 'sticky)

returns nil. After I've made the frame sticky with wm command the same
code returns t. If I made un-sticky with wm command again it returns
nil.


Learned so far:

- It's not about desktop-mode, it's about set-frame-parameter, which
  doesn't seem to work correctly at least with some windows managers.

- Seems to be windows manager specific (you don't see it with xfwm4, I
  do with fvwm2 2.6.4).


I'll try to build fvwm2 2.6.7 (which seems to be the latest) and check
if it shows the same (mis-)behaviour. Though, that has to wait for
tomorrow.

If there is anything else I could to do help analyzing the problem just
let me know.

Thanks,
rolf