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

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

bug#14233: 24.3; Don't constrain frame size to character multiples


From: Jan Djärv
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 <address@hidden>:

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







reply via email to

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