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

Previous Next

Full log

Message #17 received at 14233 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#14233: 24.3; Don't constrain frame size to character multiples
Date: Sat, 20 Apr 2013 11:11:37 +0200

Hello.

20 apr 2013 kl. 10:53 skrev martin rudalics <rudalics <at> gmx.at>:

> >> ** Remove the limitation that window and frame widths and heights can
> >>   be only full columns/lines.
> >
> > Right.  And I don't think the wording of the problem in both cases is
> > accurate enough.  There is no such limitation, except in functions
> > that actually resize the frame/window.  The display engine doesn't
> > require integral number of character cells.
> >
> > So, if someone wants to bite the bullet, the way to go is:
> >
> >   . introduce interfaces to specify frame/window size in pixels
> 
> I'm mostly done with the low-level parts of the implementation.  What
> might be lacking is a better interface specification.  So far I have:
> 
> - An option `frame-resize-pixelwise' which, when non-nil, passes resize
>  requests from the window manager pixelwise to the frame and window
>  resizing routines.
> 
> - An option `window-resize-pixelwise' which, when non-nil, makes some
>  window resize functions (like `adjust-window-trailing-edge' or
>  `fit-window-to-buffer') operate pixelwise.
> 
> - Functions like `window-resize', `split-window' or `set-frame-size'
>  take an optional argument PIXELWISE which means to interpret their
>  size/delta/width/height argument pixelwise.
> 

How does these interact with WM size hints?  Are you turning them off when resizing pixelwise?

> Some issues still deserve discussion:
> 
> - The window resize routines work pixelwise although when resizing I
>  still try to preserve full lines/columns first and give the remainder
>  to one window only.  That is, if I have three windows and 90 pixels
>  height to distribute, by default I assign 32, 32 and 26 pixels instead
>  of 30 pixels to each.  If you prefer a different solution tell me - I
>  have no strong opinion here.
> 
> - We currently include a frame's fringe widths and scroll bar widths in
>  the frame's pixel width but not in the frame's text width.  This is
>  very inconvenient on graphic systems and leads to all sorts of subtle
>  bugs like bug#14222.  Do we really care about this distinction or
>  could we simply say that specifying a frame's width specifies also the
>  width of that frame's root window (minus the internal border width)?

Are you proposing that the width of the scroll bar and the fringe be included in the text width?  You need to explain this better.

> 
> - IIUC we currently do not allow to specify the sizes of display margins
>  pixelwise.  Are we interested in lifting this restriction?  We would
>  have to invent suitable terms for these.
> 
> - We currently round fringe widths (in compute_fringe_widths) and scroll
>  bar widths (in x_set_scroll_bar_width) to columns.  Is this still
>  desirable or shall this be lifted too?
> 
> - The heights of the tool and menubar are specified in lines.  Do we
>  intend to change that to pixels?

This is dependent on the port.  For the Gtk+ port, toolbar and menubar height has no restriction to be in lines.  A value > 0 means "on".  The actual height is not the height of a line, but whatever height the toolkit chooses.

	Jan D.

> 
> >   . in the implementation of those interfaces, round up the sizes in
> >     column and line units to the integral numbers, so that the glyph
> >     matrices are large enough
> 
> I tried to do that.  Usually, the display routines are so robust that
> hardly anything could ever break them.
> 
> martin
> 
> 

Previous Next

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