unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Oleksandr Gavenko <gavenkoa@gmail.com>
To: martin rudalics <rudalics@gmx.at>
Cc: 19413@debbugs.gnu.org
Subject: bug#19413: 24.4; (desktop-save-mode 1) save frame as page and desktop sticky (_NET_WM_STATE_STICKY) when close Emacs shaded, (setq desktop-restore-frames nil) fix issue.
Date: Sat, 20 Dec 2014 19:33:40 +0200	[thread overview]
Message-ID: <87k31m5iq3.fsf@gavenkoa.example.com> (raw)
In-Reply-To: <54958CA6.9020201@gmx.at> (martin rudalics's message of "Sat, 20 Dec 2014 15:50:14 +0100")

On 2014-12-20, martin rudalics wrote:

>> When frame sticky (Fvwm decorate it especially) I get "t". For non-sticky I
>> get "nil".
>
> So the value of sticky corresponds to what you see on screen.  Correct?

Yes.

> To get it right: You first close Emacs with a shaded frame and if you
> afterwards look at the desktop file it has (sticky) in it.  If you now
> restart Emacs and close it again, the desktop file has (sticky . t).

Yes.

>> So there are two problems:
>>
>>   1) Emacs instead saving shaded window attribute add "(sticky)" to ~/.emacs.desktop
>
> So if you do not have a desktop file initially but enable
> `desktop-save-mode' and then
>
> (1) close Emacs with a shaded frame, and
>
> (2) close Emacs with an unshaded frame
>
> the difference is a (sticky) entry for (1) and no such entry for (2).
> Is that correct?

Yes.

>>   2) (desktop-read) wrongly apply (sticky), and (sticky . t) and (sticky . nil)
>>   - as always sticky.
>
> This sounds like a reasonable explanation.  x_net_wm_state has
>
> /**   store_frame_param (f, Qsticky, sticky ? Qt : Qnil); **/
>
> without any further comment, maybe it's related.  Does Emacs process
>
> (set-frame-parameter nil 'sticky ...)
>
> correctly on your system without desktop saving involved?

Any of:

  (set-frame-parameter nil 'sticky t)
  (set-frame-parameter nil 'sticky nil)
  (set-frame-parameter nil 'sticky 1)
  (set-frame-parameter nil 'sticky -1)

make clean "emacs -Q" sticky. Seems that issue here.

It is possible Fvwm bug but I don't know how to distinct. In FvwmConsole I
run:

  WindowId 0x2400013 Stick false
  WindowId 0x2400013 Stick true

and Emacs window change stickness exactly to command.

>> I check /src/xterm.h:
>>
>>    /* Atoms dealing with EWMH (i.e. _NET_...) */
>>    Atom Xatom_net_wm_state, Xatom_net_wm_state_fullscreen,
>>      Xatom_net_wm_state_maximized_horz, Xatom_net_wm_state_maximized_vert,
>>      Xatom_net_wm_state_sticky, Xatom_net_wm_state_hidden,
>>      Xatom_net_frame_extents,
>>      Xatom_net_current_desktop, Xatom_net_workarea;
>>
>> There are no _NET_WM_STATE_SHADED that defined in:
>>
>>    http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#idm140130317598336
>>      _NET_WM_STATE
>>
>> which say:
>>
>>    Possible atoms are:
>>
>>    _NET_WM_STATE_MODAL, ATOM
>>    _NET_WM_STATE_STICKY, ATOM
>>    _NET_WM_STATE_MAXIMIZED_VERT, ATOM
>>    _NET_WM_STATE_MAXIMIZED_HORZ, ATOM
>>    _NET_WM_STATE_SHADED, ATOM
>>    _NET_WM_STATE_SKIP_TASKBAR, ATOM
>>    _NET_WM_STATE_SKIP_PAGER, ATOM
>>    _NET_WM_STATE_HIDDEN, ATOM
>>    _NET_WM_STATE_FULLSCREEN, ATOM
>>    _NET_WM_STATE_ABOVE, ATOM
>>    _NET_WM_STATE_BELOW, ATOM
>>    _NET_WM_STATE_DEMANDS_ATTENTION, ATOM
>
> We have to possibilities to deal with these: Either we wait for Jan to
> return from his voyage or you fix these issues yourself.  Given your
> findings above I'm quite confident that you could do it.

xterm.c and elisp frame handling code are complicate to me.

I just can summarise investigation: 

 * (set-frame-parameter nil 'sticky ...) doesn't work, it always set
   _NET_WM_STATE(ATOM) to _NET_WM_STATE_STICKY regardless passed value.

 * Emacs code base know nothing about _NET_WM_STATE_SHADED value of
   _NET_WM_STATE(ATOM).

 * There are no "shaded" (info "(elisp)Window Frame Parameters"). I see:
   ‘sticky’, ‘visibility’, ‘fullscreen’ (maximized, fullboth, fullwidth,
   fullheight).

 * Closing shaded Emacs with "(desktop-save-mode 1)" add (stick) parameter to
   ~/.emacs.desktop

-- 
Best regards!





  reply	other threads:[~2014-12-20 17:33 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-19 21:46 bug#19413: 24.4; (desktop-save-mode 1) save frame as page and desktop sticky (_NET_WM_STATE_STICKY) when close Emacs shaded, (setq desktop-restore-frames nil) fix issue Oleksandr Gavenko
2014-12-19 21:52 ` Eli Zaretskii
2014-12-19 22:35   ` Oleksandr Gavenko
2014-12-20 10:10 ` martin rudalics
2014-12-20 12:33   ` Oleksandr Gavenko
2014-12-20 14:50     ` martin rudalics
2014-12-20 17:33       ` Oleksandr Gavenko [this message]
2014-12-22  8:52         ` Jan Djärv
2022-01-30 21:16           ` Lars Ingebrigtsen
2022-02-05  6:13             ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-03-06  2:35               ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87k31m5iq3.fsf@gavenkoa.example.com \
    --to=gavenkoa@gmail.com \
    --cc=19413@debbugs.gnu.org \
    --cc=rudalics@gmx.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).