GNU bug report logs - #14233
24.3; Don't constrain frame size to character multiples

Previous Next

Full log

View this message in rfc822 format

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, "esabof <at> gmail.com" <esabof <at> gmail.com>, "14233 <at> debbugs.gnu.org" <14233 <at> debbugs.gnu.org>
Subject: bug#14233: 24.3; Don't constrain frame size to character multiples
Date: Tue, 23 Apr 2013 13:58:07 +0200

Hello.

22 apr 2013 kl. 18:38 skrev martin rudalics <rudalics <at> gmx.at>:

> >>> This is insane. it means changing lots and lots of calls, and makes merging between branches harder.
> >> Currently, change_frame_size doesn't know anything about the various
> >> platforms' requirements going beyond those of the frame's text area.
> >
> > I don't understand what you are trying to say.
> 
> change_frame_size has no idea whether it is called for a text or a
> graphical frame.  Text frames might want to call it as before using
> character sizes.  Callers that are able to process pixels and want them
> applied will call it with pixel sizes.  In any case, the callers have to
> strip space used for tool- or menubars because change_frame_size does
> not know whether these are part of the frame or not.

We do have macros like FRAME_MENUBAR_HEIGHT and FRAME_TOOLBAR_HEIGHT that can be used.  It is better to have that calculation in one place, rather than in each port, so this might be a good time to move it.

> 
> >>> Make a new function (change_frame_size_pixelwise for example), with the arguments above, and let change_frame_size call it with the last argument false.
> >> And how would change_frame_size know what the new pixel dimensions of
> >> the frame's text area are?
> >
> > As Emacs has always done, multiply by canonical character pixel size.
> 
> Doing that would just leave things as they are now.
> 
> When I maximize a frame, that frame may get a new pixel size which is
> not necessarily a multiple of the frame's character size.  If I now want
> to resize that frame's windows (and not leave some spare pixels at the
> bottom of the frame as we do now) I have to communicate the new pixel
> size of the frame's root window to the window resizing mechanism.  The
> function that does that is change_frame_size.

That is one occasion where a pixel-function is needed.  But for most calls, pixel precision is not needed.  These are the non-tile/fullscreen/maxmimized cases in X and NS.

	Jan D.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.