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

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

Re: startup frame position


From: Eli Zaretskii
Subject: Re: startup frame position
Date: Fri, 23 Jun 2006 15:59:41 +0300

> From: Ralf Angeli <address@hidden>
> Date: Mon, 12 Jun 2006 23:25:46 +0200
> 
> It turned out that `x_set_offset' was called with `f->left_pos' and
> `f->top_pos' as arguments which have to be updated after the frame was
> created.  The following patch works for me:
> 
> Index: w32fns.c
> ===================================================================
> RCS file: /sources/emacs/emacs/src/w32fns.c,v
> retrieving revision 1.270
> diff -c -r1.270 w32fns.c
> --- w32fns.c  2 Jun 2006 21:20:44 -0000       1.270
> +++ w32fns.c  12 Jun 2006 21:17:34 -0000
> @@ -2085,8 +2085,8 @@
>      = CreateWindow (EMACS_CLASS,
>                   f->namebuf,
>                   f->output_data.w32->dwStyle | WS_CLIPCHILDREN,
> -                 f->left_pos,
> -                 f->top_pos,
> +                 CW_USEDEFAULT,
> +                 SW_SHOW,
>                   rect.right - rect.left,
>                   rect.bottom - rect.top,
>                   NULL,
> @@ -2106,7 +2106,12 @@
>        DragAcceptFiles (hwnd, TRUE);
>  
>        /* Do this to discard the default setting specified by our parent. */
> -      ShowWindow (hwnd, SW_HIDE);
> +      ShowWindow (hwnd, SW_SHOW);
> +
> +      /* Update frame positions. */
> +      GetWindowRect (hwnd, &rect);
> +      f->left_pos = rect.left;
> +      f->top_pos = rect.top;
>      }
>  }

Thanks.

Unfortunately, this patch has an unpleasant effect on my system:
"emacs -q" comes up with the mode line and the minibuffer obscured by
the task bar (which is in its default position on this box).
Surprisingly, "emacs -Q" causes Windows to create the Emacs frame in a
better place, where the minibuffer is not obscured, but subsequent
invocations of "emacs -q" progressively lower the frame until it again
has its lower edge aligned with the screen's lower boundary, which
again causes the minibuffer to be obscured.

Since the OP complained about portions of the frame being obscured, I
don't think we can accept this patch, unless you or someone else
augments it with more code to prevent Windows from pushing the
minibuffer under the task bar.  The goal is to get "emacs -q" and
"emacs -Q" start in such a manner that no portion of the Emacs frame
is ever obscured by the standard portions of the Windows desktop.




reply via email to

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