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

[martin rudalics <rudalics@gmx.at>]

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