bug#74750: clone-frame and make-frame pixelwise issues

[Ship Mints <shipmints@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4482 bytes --]

On Tue, Dec 10, 2024 at 10:56 AM martin rudalics <rudalics@gmx.at> wrote:

>  >> clone-frame does not correctly clone frames on a pixelwise basis.
>  >>
>  >> make-frame's text-pixels geometry support does not produce specified
>  >> pixelwise geometry. This also impacts frameset-restore's ability to
>  >> precisely reproduce pixelwise frame sizes.
>
> This would be a bug in frameset.el.  One problem I see is that
> 'frame-resize-pixelwise' must be set "very early" when restoring a
> session - at least _before_ the first time we send size hints to the
> window manager.
>

The goal is, I think, to achieve pixelwise harmony among clone, make, and
restore. FWIW, my GUI sessions always run with frame-resize-pixelwise set
to t and see these sizing issues consistently. My reproducer is intended to
engender the conversation as an illustration. I have resorted to manual
labor to set frame sizes in various places and including squirreling away
frame pixel size in frameset-save just to manually reset it after
restoration due to text-pixel reliability issues. Somewhere in the bowels
of frame.c, et.al., is an issue where text-pixels behaves differently than
set-frame-size which is reliable on NS where make-frame using text-pixels
is incorrect by the vertical scroll bar width. GTK it's off, too, but I
didn't analyze that further.


>  >> I consider these to be related as clone-frame's use of make-frame
> could be
>  >> using text-pixels but if that doesn't work then pixelwise cloning won't
>  >> work. I did read through the code base as best as I could but could not
>  >> find the source of the text-pixels issue.
>  >>
>  >> The following reproducer, under -Q, shows the same results on 29.4 and
>  >> 30.0.92. My main platform is NS and I also did some testing on GTK.
> GTK's
>  >> issues seem a bit "messier" and I didn't spend any time trying to
>  >> understand them in depth as I was more interested to know if GTK worked
>  >> correctly or not, which it doesn't.
>
> Your code binds 'frame-resize-pixelwise' temporarily.  This cannot work
> reliably.  That variable should never change in an Emacs session because
> its value affects the way we send size hint increments to the window
> manager.
>

Again, this is just a reproducer for discussion and is intended to
illustrate the issues, not to specifically discuss user habits for
frame-resize-pixelwise across a GUI session. I think most people these days
probably do have it set to t, even if it's become reflexive.

This is, admittedly, a design error that would have to be fixed as
> follows:
>
> - Implement a new frame parameter 'resize-pixelwise'.
>

I certainly prefer something more explicit such as this.

- Send size hints according to the value of this parameter.  When the
>    parameter is set, new size hints must be sent.
>
> Alternatively, we could send new size hints for all live frames whenever
> 'frame-resize-pixelwise' is changed.  This would have to be done with a
> variable watcher.  Still, let-binding this variable would confuse the
> hell out of our interactions with the window manager.  When the scope of
> the let-binding is left, we would have to send size hints again.
>

No, please.

 >> This is an implementation of clone-frame that uses text-pixels under
>  >> make-frame. This depends on make-frame text-pixels being corrected.
> Happy
>  >> to supply this as a patch should the discussion of these issues
> progress in
>  >> that direction.
>  >>
>  >> (defun clone-frame (&optional frame no-windows pixelwise)
>
> What would the WM do in a situation where PIXELWISE is non-nil and
> 'frame-resize-pixelwise' is nil?
>

The simple interim code (vs. the resize-pixelwise proposal) respects
frame-resize-pixelwise as the user's preference. Same with being explicit
by saying 'pixelwise, it's user intention.

    (when (and (display-graphic-p frame)
               (or pixelwise frame-resize-pixelwise))

FWIW, there are surely weird WM issues but at the very least, we're talking
about the inner geometry text-width and text-height that Emacs controls and
I stayed away from external geometry to start off at least seeing if we can
correct for what Emacs controls completely. GTK is definitely worse than NS
but at least in NS every user has the same experience as the WM options and
behaviors are more constrained than X11-derived kind of free-for-all WMs.

martin
>

[-- Attachment #2: Type: text/html, Size: 6900 bytes --]