MS Windows Frame Maximize in .emacs (again)

MS Windows Frame Maximize in .emacs (again)

[David Abrahams]

I have nothing to add to
http://lists.gnu.org/archive/html/emacs-devel/2004-12/msg00364.html
except that it's happening for me, too.

Ideas, anyone?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Re: MS Windows Frame Maximize in .emacs (again)

[David Abrahams]

David Abrahams <dave@boost-consulting.com> writes:

> I have nothing to add to
> http://lists.gnu.org/archive/html/emacs-devel/2004-12/msg00364.html
> except that it's happening for me, too.
>
> Ideas, anyone?

I would be very glad to help fix this one if someone could give me a
few hints about where to set breakpoints, etc.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Re: MS Windows Frame Maximize in .emacs (again)

[David Abrahams]

David Abrahams <dave@boost-consulting.com> writes:

> David Abrahams <dave@boost-consulting.com> writes:
>
>> I have nothing to add to
>> http://lists.gnu.org/archive/html/emacs-devel/2004-12/msg00364.html
>> except that it's happening for me, too.
>>
>> Ideas, anyone?
>
> I would be very glad to help fix this one if someone could give me a
> few hints about where to set breakpoints, etc.

Actually, by chance, I just figured out what the problem is when I
introduced an error into my .emacs: I am hiding the toolbar, and the
amount of window shrinkage is exactly equal to the height of the
toolbar.

I used to have 

(custom-set-variables
 ...
 '(toolbar-visible-p nil)
 ...
 )

and when I added
 
 '(tool-bar-originally-present nil)

to the customizations, the crazy window shrinkage disappeared.  This
ought to be enough to tell somebody how to fix the actual problem.

HTH,
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Re: MS Windows Frame Maximize in .emacs (again)

[Lennart Borgman]

David Abrahams wrote:

>David Abrahams <dave@boost-consulting.com> writes:
>
>  
>
>>David Abrahams <dave@boost-consulting.com> writes:
>>
>>    
>>
>>>I have nothing to add to
>>>http://lists.gnu.org/archive/html/emacs-devel/2004-12/msg00364.html
>>>except that it's happening for me, too.
>>>
>>>Ideas, anyone?
>>>      
>>>
>>I would be very glad to help fix this one if someone could give me a
>>few hints about where to set breakpoints, etc.
>>    
>>
>
>Actually, by chance, I just figured out what the problem is when I
>introduced an error into my .emacs: I am hiding the toolbar, and the
>amount of window shrinkage is exactly equal to the height of the
>toolbar.
>
>I used to have 
>
>(custom-set-variables
> ...
> '(toolbar-visible-p nil)
> ...
> )
>
>and when I added
> 
> '(tool-bar-originally-present nil)
>
>to the customizations, the crazy window shrinkage disappeared.  This
>ought to be enough to tell somebody how to fix the actual problem.
>
There seems to be something wrong with the w32 for taking care of 
maximized windows. I just discovered that you actually can move a 
maximized window too. That should not be possible. And the maximized 
window does not have the height it should - it is a little bit to 
smaller than it should be.

Re: MS Windows Frame Maximize in .emacs (again)

[Lennart Borgman]

David Abrahams wrote:

>I have nothing to add to
>http://lists.gnu.org/archive/html/emacs-devel/2004-12/msg00364.html
>except that it's happening for me, too.
>
>Ideas, anyone?
>
>  
>

I think the changes below should make maximized frames behave better on 
w32. They try to prevent changing the size of a frame that is maximized.

This change remove the bug that a maximized frame does not fit the whole 
screen. It also removes the bug that a maximezed frame can be moved.

At least for me there seems to be no problem now (with these patches) to 
maximize a frame on startup on w32. (But I do not know if these patches 
actually affected that.)

Could someone please try them and check them in?


Index: w32fns.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/w32fns.c,v
retrieving revision 1.246
diff -r1.246 w32fns.c
3651,3652c3651,3652
<               lppos->cx -= wdiff;
<               lppos->cy -= hdiff;
---
 >               //lppos->cx -= wdiff;
 >               //lppos->cy -= hdiff;
3656a3657,3658
 >                   lppos->cx -= wdiff;
 >                   lppos->cy -= hdiff;

C:\emacscvs\emacs\src>cvs diff w32term.c
Index: w32term.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/w32term.c,v
retrieving revision 1.224
diff -r1.224 w32term.c
3837a3838
 >         if (!IsZoomed(hwnd)){
3840a3842
 >         }

Re: MS Windows Frame Maximize in .emacs (again)

[jasonr]

Quoting Lennart Borgman <lennart.borgman.073@student.lu.se>:

> David Abrahams wrote:
>
> >I have nothing to add to
> >http://lists.gnu.org/archive/html/emacs-devel/2004-12/msg00364.html
> >except that it's happening for me, too.
> >
> >Ideas, anyone?
> >
> >
> >
>
> I think the changes below should make maximized frames behave better on
> w32. They try to prevent changing the size of a frame that is maximized.
>
> This change remove the bug that a maximized frame does not fit the whole
> screen. It also removes the bug that a maximezed frame can be moved.

The "bug" used to be there because Emacs required an integer number of lines on
the screen. Now that Emacs handles different sized fonts, this restriction may
not be needed anymore, in which case we should remove it completely on all
platforms, not just for maximized frames on Windows. But I am not convinced
that scrolling code and other code that works with "pages" has been adapted to
work with non inteeger numbers of lines measured in the default font yet.

Re: MS Windows Frame Maximize in .emacs (again)

[LENNART BORGMAN]

From: jasonr@f2s.com

> > I think the changes below should make maximized frames behave 
> better on
> > w32. They try to prevent changing the size of a frame that is 
> maximized.>
> > This change remove the bug that a maximized frame does not fit 
> the whole
> > screen. It also removes the bug that a maximezed frame can be moved.
> 
> The "bug" used to be there because Emacs required an integer 
> number of lines on
> the screen. Now that Emacs handles different sized fonts, this 
> restriction may
> not be needed anymore, in which case we should remove it 
> completely on all
> platforms, not just for maximized frames on Windows. But I am not 
> convincedthat scrolling code and other code that works with 
> "pages" has been adapted to
> work with non inteeger numbers of lines measured in the default 
> font yet.


I see, that is what I thought. But changing the size of a maximized window on w32 confuses the w32 window handler a bit I guess. It would be good to avoid this.

Re: MS Windows Frame Maximize in .emacs (again)

[Juanma Barranquero]

> The "bug" used to be there because Emacs required an integer number of lines on
> the screen. Now that Emacs handles different sized fonts, this restriction may
> not be needed anymore, in which case we should remove it completely on all
> platforms, not just for maximized frames on Windows.

Sure. Still, maximized frames on Windows have their own problems. I
have a custom function which uses w32-send-sys-command to maximize the
frame and I've been unable to make it work reliably (oftentimes
Windows and Emacs seem to differ about whether the Emacs frame is
maximized or not).

> But I am not convinced
> that scrolling code and other code that works with "pages" has been adapted to
> work with non inteeger numbers of lines measured in the default font yet.

What can we try to test that hypothesis?

-- 
                    /L/e/k/t/u

Re: MS Windows Frame Maximize in .emacs (again)

[Kim F. Storm]

jasonr@f2s.com writes:

> The "bug" used to be there because Emacs required an integer number of lines on
> the screen. Now that Emacs handles different sized fonts, this restriction may
> not be needed anymore, 

It is not "needed", but the window size / position calculations are
still performed in lines/column units, so it is major work to remove
the restriction.   I plan to do that _after_ the release.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: MS Windows Frame Maximize in .emacs (again)

[LENNART BORGMAN]

From: storm@cua.dk (Kim F. Storm)

> jasonr@f2s.com writes:
> 
> > The "bug" used to be there because Emacs required an integer 
> number of lines on
> > the screen. Now that Emacs handles different sized fonts, this 
> restriction may
> > not be needed anymore, 
> 
> It is not "needed", but the window size / position calculations are
> still performed in lines/column units, so it is major work to remove
> the restriction.   I plan to do that _after_ the release.

But is it at all needed for maximized frames currently?

Re: MS Windows Frame Maximize in .emacs (again)

[Juanma Barranquero]

On 6/9/05, LENNART BORGMAN <lennart.borgman.073@student.lu.se> wrote:

> I see, that is what I thought. But changing the size of a maximized window on
> w32 confuses the w32 window handler a bit I guess. It would be good to avoid this.

Removing the full-lines restriction is perhaps too large a change for
the freeze period. Making maximized frames do-the-right-thing is OTOH
worthwhile. All this IMO, of course.

                    /L/e/k/t/u

Re: MS Windows Frame Maximize in .emacs (again)

[Juanma Barranquero]

> I plan to do that _after_ the release.

Cool.

Could we install Lennart's patch for 22.1, then? (If it causes any
trouble we'll find soon enough during the pretest.)

                    /L/e/k/t/u

Re: MS Windows Frame Maximize in .emacs (again)

[David Kastrup]

Juanma Barranquero <lekktu@gmail.com> writes:

> On 6/9/05, LENNART BORGMAN <lennart.borgman.073@student.lu.se> wrote:
>
>> I see, that is what I thought. But changing the size of a maximized
>> window on w32 confuses the w32 window handler a bit I guess. It
>> would be good to avoid this.
>
> Removing the full-lines restriction is perhaps too large a change
> for the freeze period.  Making maximized frames do-the-right-thing
> is OTOH worthwhile. All this IMO, of course.

One problem is that toggling tool-bar-mode and menu-bar-mode will
change the size of the frame, and that is a definitive nuisance.

In principle, we need to record whenever a geometry specification is
heeded whether, at the time of the instantiation of the geometry,
tool-bar and menu-bar have been on.  Then whenever the setting of
tool-bar-mode and menu-bar-mode is changed, the frame size needs to
get recalculated, by always rounding down any fractional lines
resulting from a change of the setting _from_ the original
instantiation, and by always rounding up any fractional lines
resulting from a change _to_ the original instantiation.  And the
fractional lines resulting from a change in menu bar and toolbar have
to be maintained separately, and menu bar and toolbar have to have a
height of at least one default window line.

And then we have window managers which behave strangely when docking
and undocking the toolbar and stuff.

I am not convinced that it would not be the least invasive fix to just
allow fractional window heights and thus be not forced to resize the
frame at all on such events.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: MS Windows Frame Maximize in .emacs (again)

[Kim F. Storm]

Juanma Barranquero <lekktu@gmail.com> writes:

>> I plan to do that _after_ the release.
>
> Cool.
>
> Could we install Lennart's patch for 22.1, then? (If it causes any
> trouble we'll find soon enough during the pretest.)

IIRC, Lennart said some time ago that he had signed papers, but I
cannot find his entry in the copyright assignment file.

This may be a tiny change in itself, but there is already a
pretty large change by Lennart in CVS: 

2005-03-26  Lennart Borgman  <lennart.borgman.073@student.lu.se>

	* w32term.h (x_output): Add focus_state.

	* w32term.c (x_focus_changed, w32_detect_focus_change): New functions.
	(w32_read_socket) [WM_SETFOCUS]: Call w32_detect_focus_change.


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: MS Windows Frame Maximize in .emacs (again)

[jasonr]

Quoting LENNART BORGMAN <lennart.borgman.073@student.lu.se>:

> From: storm@cua.dk (Kim F. Storm)
>
> > jasonr@f2s.com writes:
> >
> > > The "bug" used to be there because Emacs required an integer
> > number of lines on
> > > the screen. Now that Emacs handles different sized fonts, this
> > restriction may
> > > not be needed anymore,
> >
> > It is not "needed", but the window size / position calculations are
> > still performed in lines/column units, so it is major work to remove
> > the restriction.   I plan to do that _after_ the release.
>
> But is it at all needed for maximized frames currently?

If the code is unable to handle non-integer frame heights for non-maximised
frames, it is unable to handle them for maximised frames.

I'd leave this change for after the release, as it is likely to introduce subtle
bugs until Kim has made those changes.

Re: MS Windows Frame Maximize in .emacs (again)

[jasonr]

Quoting Juanma Barranquero <lekktu@gmail.com>:

> > I plan to do that _after_ the release.
>
> Cool.
>
> Could we install Lennart's patch for 22.1, then? (If it causes any
> trouble we'll find soon enough during the pretest.)
>

Lennart's change depends on Kim's change to work reliably, so installing it for
22.1 would not be right.

Re: MS Windows Frame Maximize in .emacs (again)

[Juanma Barranquero]

> I'd leave this change for after the release, as it is likely to introduce subtle
> bugs until Kim has made those changes.

OK, you're the expert :)

-- 
                    /L/e/k/t/u

Re: MS Windows Frame Maximize in .emacs (again)

[Lennart Borgman]

Kim F. Storm wrote:

>IIRC, Lennart said some time ago that he had signed papers, but I
>cannot find his entry in the copyright assignment file.
>  
>
I have signed them a second time and posted them.

Re: MS Windows Frame Maximize in .emacs (again)

[Richard Stallman]

    IIRC, Lennart said some time ago that he had signed papers, but I
    cannot find his entry in the copyright assignment file.

I will ask the copyright clerk to look for his papers.

Re: MS Windows Frame Maximize in .emacs (again)

[Juanma Barranquero]

I've been testing Lennart's patch for the maximizing problems on
Windows for about a month with no glitch whatsoever.

Of the two components of Lennart's patch, the first one was decided it
would be better fixed when adding support for fractional heights:

> --- src/w32fns.c        3 Jan 2005 22:53:30 -0000       1.246
> +++ src/w32fns.c        9 Jun 2005 08:17:43 -0000
> @@ -3649,10 +3649,9 @@
>                    and Y positions as well.  */
> 
> -               lppos->cx -= wdiff;
> -               lppos->cy -= hdiff;
> -
>                 if (wp.showCmd != SW_SHOWMAXIMIZED
>                     && (lppos->flags & SWP_NOMOVE) == 0)
>                   {
> +                    lppos->cx -= wdiff;
> +                    lppos->cy -= hdiff;
>                     if (lppos->x != wr.left || lppos->y != wr.top)
>                       {

However, this part of the change shouldn't be dependant on that, should it?

> --- src/w32term.c       26 Mar 2005 00:19:53 -0000      1.224
> +++ src/w32term.c       9 Jun 2005 08:20:38 -0000
> @@ -3836,7 +3836,8 @@
>               area of the parent window now exposed will be refreshed.  */
>            my_show_window (f, hwnd, SW_HIDE);
> -          MoveWindow (hwnd, sb_left + VERTICAL_SCROLL_BAR_WIDTH_TRIM,
> -                     top, sb_width - VERTICAL_SCROLL_BAR_WIDTH_TRIM * 2,
> -                     max (height, 1), TRUE);
> +          if (!IsZoomed (hwnd))
> +              MoveWindow (hwnd, sb_left + VERTICAL_SCROLL_BAR_WIDTH_TRIM,
> +                          top, sb_width - VERTICAL_SCROLL_BAR_WIDTH_TRIM * 2,
> +                          max (height, 1), TRUE);
>            if (pfnSetScrollInfo)
>              {
> 

I mean, we shouldn't be allowing to move a zoomed window. I propose we
install this part (which can reasonably be supposed to introduce no
instability, it's just skipping a MoveWindow call).

-- 
                    /L/e/k/t/u