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

[martin rudalics]

>> Does it also make the frame sticky when with emacs -Q you simply
>> evaluate
>>
>>        (set-frame-parameter frame 'sticky nil)))
>
> It's not exactly clear to me what code you ask me to evaluate (the code
> above isn't syntactically correct or only a part of the code you want me
> to evalute.

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 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 (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?  And I also suppose that

(set-frame-parameter nil 'sticky t)

behaves just the same as with nil.  Right?

> Hm. From looking around I see that x_set_sticky and set_wm_state are C
> functions in xterm.c and x_send_client_event and x_fill_property_data
> are C functions in xselect.c.
>
> I guess you mean I should run emacs under gdb, set breakpoints to that
> functions and inspect the arguments given to the calls. Unfortunately
> I'm not used to gdb.
>
> With the help of etc/DEBUG (part of the emacs source distribution) I was
> able to start emacs from within emacs with the help of M-x gdb, to set
> break points to this four functions and run the new instance, with
> execution stoping at my breakpoints.

Great.

> 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 while doing

(set-frame-parameter nil 'sticky t)

in the debugged emacs has

p add

print true instead.  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).

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?

martin