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, 14233 <at> debbugs.gnu.org
Subject: bug#14233: 24.3; Don't constrain frame size to character multiples
Date: Sun, 21 Apr 2013 19:21:28 +0200

Hello.

21 apr 2013 kl. 11:26 skrev martin rudalics <rudalics <at> gmx.at>:

> > WM hints tell the window manager the width increment and height
> > increment that the Emacs frame wants to be resized in.  This means when
> > a user resizes by dragging the window border, the window manager only
> > allows resize increments by the specified width/height increments.
> 
> At least for the window manager of Windos XP this is not true.

That is why testing this on anything but X11 gives the wrong impression on how things work.

> 
> > So
> > there is no half characters showing.  In addition, when resize occurs
> > some, not all, window managers shows the size while resizing.  When
> > width/height increments have been set, the WM shows the size in these
> > units, which for Emacs translates to rows and columns.
> 
> Again with Windows XP resizing an Emacs frame shows the new sizes
> pixelwise.  Only when releasing the mouse button the frame snaps back to
> its previous size unless I made it beyond the character size barrier.
> But in this case it's just Emacs not honoring the WM's request.
> 
> > This does not mean that the toolbar, menubar, scrollbar, fringe etc. has
> > to be in a multiple of these increments.  In addition to the increments,
> > you also specify a base width/height in pixels.  That base width/height
> > is the non-text portions width/height.
> 
> Can you explain what the base width/height is?  Something like a minimum
> size?

Sort of a minimu size if we would have zero columns and lines.

> 
> > So at any time the WM maintains the invariant:
> >    width = base width + n x width increment
> >    height = base height + m x height increment
> >
> > n, m are integers.
> >
> > You can also specify a minimum size, but that is not relevant to this
> > issue.
> 
> A minimum size for what?

A minimum size for the frame.  We do say that the minimum frame is one line and one column, but it could be anthing.  We could say that the minimum size is 5 rows and 14 coulmns, or whatever we choose.  The WM will then not shrink the window below this.

> 
> > Note that for fullscreen, the WM does not keep this invariant, nor does
> > tiling window managers.
> 
> What about maximized frames?

Not for that either.

> 
> > For other types of resize (i.e. interactive
> > with the mouse) I'd like to keep the WM size hints, because it is more
> > userfriendly.
> 
> From the Emacs POV this is easy: I could accept `frame-resize-pixelwise'
> being a list that enumerates all WM operations that should be
> interpreted pixelwise and have t stand for "all are pixelwise" and nil
> for "none are".  The problem is that IIUC a maximize frame request
> should be interpreted pixelwise but comes in just as a plain resize
> request.  What are your experiences in this regard?  How does ns do
> that?
> 

For NS a maximized and fullscreen requests comes in as separate requests, for X they are normal resize request.

The problem is that you think from the W32 point of view where (if I interepret you correctly), Emacs applies size hints after the resize request has been delivered.

This is not so for NS and X.  Any size in a resize request is accepted.  If it follows WM size hints, great, if it don't, who cares?.  The frame size is set to the size in the request anyway.

So for NS and X, fullscreen, maximized and such is no problem.  A minor glitch in NS is that we calculate the maximized sizes ourself, and these are rounded to character sizes.  If windows could handle pixel sizes, we could easily fix this.

> > If we want to make windows display partial lines that is OK, and even
> > preferrable for the fullscreen/tiling case, but we should not disregard
> > WM size hints for the other case.
> 
> I agree with you.  But we should make them customizable.
> 
> >>> But I'd prefer if the text part is resizable only in terms of
> >>> lines/columns.
> >>
> >> Why?  Is there any other reason beyond WM hints?
> >
> > Usability.  For example, all terminal emulators does this.
> 
> OK.  But this should not impede us from providing an adequate graphical
> implementation.
> 
> >>> An exception to this is tiling window managers and fullscreen behaviour.
> >>
> >> If we cannot resize in pixels, we cannot make those exceptions, can
> >> we?
> >
> > We only need to make Emacs windows be resizable in pixels, not the frame
> > as I tried to explain above.
> 
> Tiling, fullscreen and maximization requests are all incarnations of
> pixelwise resizing of frames.  How else would you call them?

But there is no restriction on NS and X11 frames to resize by pixel (i.e. not character multiples).  We do that already.  The bug reports we get usually concern when we don't adhere to WM size hints, like fullscreen.  Then there are wasted pixels, becaue windows can't resize pixelwise.
That is where the restriction is.

	Jan D.

Previous Next

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