emacs-pretest-bug
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Patch to fix frame positioning bug on Windows with (make-frame '((le


From: Drew Adams
Subject: RE: Patch to fix frame positioning bug on Windows with (make-frame '((left . -1)))
Date: Tue, 3 May 2005 13:49:47 -0700

I'm not sure if this is related to the thread below, but, in GNU Emacs
21.3.50.1 (i386-mingw-nt5.1.2600) of 2005-01-30 on NONIQPC, the positioning
of a frame with `top' parameter = -14 places the frame about 4
character-heights too low on the display. Instead of the bottom of the frame
being 14 pixels above the display bottom, it appears to be about 28 pixels
below the display bottom. My (frame-char-height) is 14. I'm on Windows XP.

Thanks,

  Drew

    -----Original Message-----
    From: address@hidden
    [mailto:address@hidden Behalf Of
    Francis Litterio
    Sent: Wednesday, January 12, 2005 12:46 PM
    To: address@hidden
    Cc: address@hidden
    Subject: Re: Patch to fix frame positioning bug on Windows with
    (make-frame '((left . -1)))


    Jan D. wrote:

    >> Using Emacs built from CVS source code on Windows XP, the
    frame created
    >> using the following Emacs-Lisp code is positioned such that the
    >> rightmost 7 pixels of the frame are off the right edge of the screen:
    >>
    >>   (make-frame '((width . 80) (height . 20) (top . 0) (left . -1)))
    ...
    >> The below patch solves the problem but it may not be optimal
    because it
    >> simply subtracts 7 from the computed value of f->left_pos.
    >
    > Can you verify if your change has any impact on this bug:
    >
    >
    http://lists.gnu.org/archive/html/emacs-pretest-bug/2004-11/msg0
    0519.html
    >
    > This was the reason a change was made.  It may be impossible to get
    > Emacs to work correctly on W32.  Just [subtracting] 7 is no good, as
    > you self pointed out, a more general solution must be found.

    My change breaks the fix for that bug, so I'm going to investigate
    further.

    In my testing, I noticed that (make-frame '((top . -1))) on Windows
    suffers an even worse positioning error -- about 30 pixels at the bottom
    of the frame fall off the bottom of the screen!

    I would think that when a frame is positioned so that it is completely
    visible, we have the following variables and relations:

      OUTER-LEFT: The number of pixels between the left screen edge
              and the left border drawn by Windows of the frame.
              This can be 0.

      LEFT-BORDER: The width of the left border drawn by Windows
    (in pixels).

      FRAME-CONTENT-WIDTH: The width of the frame content, including
                       the fringes but not including the left and
                       right borders drawn by Windows.

      RIGHT-BORDER: The width of the right border drawn by Windows (in
                pixels).

      OUTER-RIGHT: The number of pixels between the right screen edge
               and the right border drawn by Windows of the frame.
               This can be 0.

      DISPLAY-WIDTH: The width of the display (in pixels).

    and finally this relation should hold:

      DISPLAY-WIDTH = OUTER-LEFT + LEFT-BORDER + FRAME-CONTENT-WIDTH +
                  RIGHT-BORDER + OUTER-RIGHT

    A similar relation can be constructed for the vertical screen
    dimension.

    Given this model, we should be able to make w32term.c position frames
    consistently, regardless of whether the 'top or 'left frame parameter
    was positive or negative (modulo the issue with the user being able to
    change the width of the border drawn by Windows -- but it should work
    with Windows' default border sizes).






reply via email to

[Prev in Thread] Current Thread [Next in Thread]