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

From: martin rudalics <[email-masked]>
Date: Thu, 31 May 2018 15:55:42 +0200

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

If worse comes to worst we can avoid setting the parameter when the
stored value alreay equals the requested value by writing something
like:

void
x_set_sticky (struct frame *f, Lisp_Object new_value, Lisp_Object old_value)
{
   Lisp_Object frame;
   struct x_display_info *dpyinfo = FRAME_DISPLAY_INFO (f);

   if (!EQ (new_value, old_value))
     {
       XSETFRAME (frame, f);

       set_wm_state (frame, !NILP (new_value),
		    dpyinfo->Xatom_net_wm_state_sticky, None);
     }
}

This might be even the right thing to do if, for example, the WM
decides that making a non-sticky frame non-sticky is a silly request
and the application probably wants a sticky frame instead.

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

We would have to hear from others.  Anyone?  With emacs -Q evaluate

(set-frame-parameter nil 'sticky nil)

and look whether your frame starts to appear on all your desktops.

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

You have done a lot already.  But there are two things that might be
interesting to get the full picture: Put a brakpoint in xterm.c in
get_current_wm_state at the line

       else if (a == dpyinfo->Xatom_net_wm_state_sticky)

and look what value gets assigned here after you set stickyness on/off
via the window manager or via ‘set-frame-parameter’ - that means four
cases to check.

The second is to not use USE_XCB (_if you do_) by simply replacing
USE_XCB by 0 (zero) in all occurrences of this symbol in
get_current_wm_state - only if you can recompile, obviously.

I expect both of these not to change a thing in the actual behavior
since these are just the values reported to us by the WM but I'd like
to be sure that the WM behaves consistently in this regard.

And you could try to build Emacs without toolkit support (Lucid or
Motif would be better but may require to download some development
libraries) and look whether the problem persists.  Then we would know
that the problem is or is not toolkit dependent, where the former
would consitute a step forward.

Many thanks, martin