[Top][All Lists]

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

frame position is too low with negative `top' (was: Patch to fix frame p

From: Drew Adams
Subject: frame position is too low with negative `top' (was: Patch to fix frame positioning bug on Windows...)
Date: Tue, 17 May 2005 16:22:35 -0700


I don't mean to pester folks about this bug, but I'd like to know whether
someone intends to fix this. If not, I'll just hack my local code to raise
the frame 44 pixels or so, for now.

I should also have shown the kind of code I use:

  (cdr (assq 'left (frame-parameters (selected-frame))))
  (- (frame-char-height (selected-frame))))

I should mention that the display bottom seems now to be the physical
display bottom, whereas before (e.g. Emacs 20) it was the bottom of the
usable display area, not counting the Windows task bar, which takes up about
30 pixels in height.

It could be argued that that's OK, and not necessarily a bug. With that
design intention in mind, the buggy offset is a bit less than I indicated
below: It would appear to really be off by only about 14 pixels (which is my
character height).

FYI, the Windows task bar is, by default, all along the bottom of the
display, about 30 pixels in height. Users can position it elsewhere,
however. Perhaps, ideally, Emacs could determine this position and calculate
the usable display dimensions accordingly. However, it is also possible to
auto-hide the task bar, so it may not be worth trying to adjust the usable
display size (and position!)according to the task-bar position.

Also, whether or not the tool-bar and minibuffer are visible has no effect.
However, if the *menu-bar* is not shown, then the problem goes away (modulo
the Windows task-bar). So, perhaps the fix is as simple as doing whatever is
done when the menu-bar is not shown. That is, perhaps frame-positioning is
just not taking the menu-bar height into account when it figures the frame

I'm seeing the same behavior in a later snapshot, as well:

  In GNU Emacs (i386-mingw-nt5.1.2600)
   of 2005-04-16 on LAPTOP
  Distributor `Microsoft Corp.', version 5.1.2600
  configured using `configure --with-gcc (3.4)'

FYI, I obtained the snapshot here: http://www.crasseux.com/emacs/.



    -----Original Message-----
    From: Drew Adams [mailto:address@hidden
    Sent: Tuesday, May 03, 2005 1:50 PM
    To: Francis Litterio; address@hidden
    Subject: RE: Patch to fix frame positioning bug on Windows with
    (make-frame '((left . -1)))

    I'm not sure if this is related to the thread below, but, in
    GNU Emacs (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.



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

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

          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:

                          RIGHT-BORDER + OUTER-RIGHT

        A similar relation can be constructed for the vertical screen

        Given this model, we should be able to make w32term.c
    position frames
        consistently, regardless of whether the 'top or 'left frame
        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]