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

[Ship Mints <shipmints@gmail.com>]

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

That patch seems to work. Thank you, Martin. I tested on NS with and
without vertical scroll bars and with and without fringes. A basic test of
frameset-save and frameset-restore now seem to correctly respect its
embedded text-pixel geometry.

Now, about clone-frame. Are there any objections to the below
implementation that uses text-pixels?

(defun my/clone-frame (&optional frame no-windows pixelwise)
  "Make a new frame with the same parameters and windows as FRAME.
With a prefix arg NO-WINDOWS, don't clone the window configuration.  When
PIXELWISE is non-nil or if `frame-resize-pixelwise' is non-nil, and frame
is not text-only, clone the originating frame's pixel size.

FRAME defaults to the selected frame.  The frame is created on the
same terminal as FRAME.  If the terminal is a text-only terminal then
also select the new frame."
  (interactive (list (selected-frame) current-prefix-arg))
  (let* ((frame (or frame (selected-frame)))
         (windows (unless no-windows
                    (window-state-get (frame-root-window frame))))
         (default-frame-alist
          (seq-remove (lambda (elem)
                        (memq (car elem) frame-internal-parameters))
                      (frame-parameters frame)))
         (frame-resize-pixelwise frame-resize-pixelwise)
         (new-frame))
    (when (and (display-graphic-p frame)
               (or pixelwise frame-resize-pixelwise))
      (setq frame-resize-pixelwise t)
      (push (cons 'width (cons 'text-pixels (frame-text-width frame)))
            default-frame-alist)
      (push (cons 'height (cons 'text-pixels (frame-text-height frame)))
            default-frame-alist))
    (setq new-frame (make-frame))
    (when windows
      (window-state-put windows (frame-root-window new-frame) 'safe))
    (unless (display-graphic-p frame)
      (select-frame new-frame))
    new-frame))

I may be able to test on GTK early this week, but I think you have GNU
Linux/GTK on your end?

-Stephane

On Sat, Dec 14, 2024 at 3:27 AM martin rudalics <rudalics@gmx.at> wrote:

>  > Indeed 15 is the vertical scroll bar width. This was what I reported in
> the
>  > original bug submission. You suggested a patch that would accommodate
>  > fringes, et.al. If you'd like me to make adjustments; e.g., resizing
>  > fringes or whatever, happy to do it and rerun.
>
> I've been throwing out the child with the bathwater.  Please try the
> attached patch which retains an important conjunct.
>
>  > These are all ostensively calls to clone-frame. I'd expect, as I guess
> most
>  > people would, that cloning produces the precise geometry of the
> originating
>  > frame, scroll bar or not.
>
> The major purpose of 'frame-inhibit-implied-resize' is to avoid resizes
> when a frame has been tailored to fit into some arrangement of windows
> on the display as, for example, with a tiling window manager.  Here I
> hardly ever use it.  By design, it should have no effect when making a
> new frame which is what the corrected patch should support.  Still, it
> might not work for elements like the external tool bar.
>
>  >> We can try to make it behave reasonably when
>  >> these values change but I am not sure whether we will succeed.
>  >>
>  >
>  > Let's try.
>
> Let's.
>
> martin

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