unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: martin rudalics <rudalics@gmx.at>
To: david@ngdr.net
Cc: "25943@debbugs.gnu.org" <25943@debbugs.gnu.org>
Subject: bug#25943: 21.5  Frame Display Difficulties
Date: Thu, 23 Mar 2017 08:59:49 +0100	[thread overview]
Message-ID: <58D38075.2030409@gmx.at> (raw)
In-Reply-To: <58C3CF94.3080604@gmx.at>

[-- Attachment #1: Type: text/plain, Size: 2164 bytes --]

 > I'll eventually push a "fix" to the repository but this
 > will certainly not become part of the Emacs 25 series.

I've pushed a fix to master now.  So if you can work with master please
update your copy and set, in your init file, the variable
`x-gtk-use-window-move' to t and see whether your problem one is fixed
now.

To everyone who sets negative frame positions in her programs or init
file: Please try loading the attached file frame-position.el, evaluate
it, call `frame-position-make' which will create twelve frames evenly
distributed among the corners of your screen and finally run the
function `frame-position-list' whose return value lists position and
size information about these frames.  Here this gets me a list like

((display-pixel-width . 1680)
  (display-pixel-height . 1050)
  (arg
   (p-left . 40)
   (p-top . 40)
   (left . 40)
   (top . 40)
   (width . 750)
   (height . 360))
   ...
(arg
   (p-left . -40)
   (p-top . -40)
   (left . 904)
   (top . 564)
   (width . 750)
   (height . 360)
   (r-left . -26)
   (r-top . -126))
   ...
  (fun
   (p-left . -40)
   (p-top . -40)
   (left . 890)
   (top . 564)
   (width . 750)
   (height . 360)
   (r-left . -40)
   (r-top . -126)))

The "arg" frames were produced by supplying sizes and positions via the
argument list of `make-frame'.  The "par" frames were produced by
calling `modify-frame-parameters' with the sizes and positions after the
frame was made and making the frame visible after that.  The "fun"
frames were produced by setting frame sizes and positions after the
frame was made and making the frame visible after that.

p-left stands for the programmed and r-left for the realized left
position.  p-top and r-top do that for the top position.  Ideally, these
values are the same, often they aren't.  Here, the difference between
the "arg" and the "fun" values is that the latter apparently already
counts in 14 pixels for the scroll bar.

Besides that, the values are still far from correct on GNU/Linux since
they do not account for the window manager decorations.  I would be
interested if people get results that differ from the examples I gave
above.

Thanks, martin

[-- Attachment #2: frame-position.el --]
[-- Type: application/emacs-lisp, Size: 2748 bytes --]

  reply	other threads:[~2017-03-23  7:59 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-03  3:51 bug#25943: 21.5 Frame Display Difficulties david
2017-03-03  8:13 ` martin rudalics
     [not found]   ` <af552a322a8a630796cbddf1133b6dbe@127.0.0.1>
2017-03-04  9:59     ` martin rudalics
2017-03-07  1:51       ` david
2017-03-07  9:45         ` martin rudalics
2017-03-08 22:58           ` david
2017-03-09  8:56             ` martin rudalics
2017-03-10 18:44               ` david
2017-03-11 10:21                 ` martin rudalics
2017-03-23  7:59                   ` martin rudalics [this message]
2017-03-28 22:43                     ` david
2017-03-29  7:36                       ` martin rudalics
2017-03-29 19:53                         ` david
2017-03-30  7:29                           ` martin rudalics
2017-04-01  4:35                             ` david
2017-04-01  7:36                               ` martin rudalics
     [not found]                                 ` <7ee8200b866d8067514fb8b0bb9e814b@127.0.0.1>
2017-04-02  7:55                                   ` martin rudalics
2017-04-04  0:35                                     ` david
2017-04-04  7:25                                       ` martin rudalics
2017-04-07  0:12                                         ` david
2017-04-07  5:56                                           ` martin rudalics
2017-04-07 21:16                                             ` david
2022-04-25 14:48                                               ` Lars Ingebrigtsen
2022-05-24 12:50                                                 ` Lars Ingebrigtsen
2017-04-07 21:19                                             ` david
2017-04-08  9:00                                               ` martin rudalics
2017-04-11  6:49                     ` martin rudalics

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=58D38075.2030409@gmx.at \
    --to=rudalics@gmx.at \
    --cc=25943@debbugs.gnu.org \
    --cc=david@ngdr.net \
    /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).