[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#11113: [Tristan Miller] Re: bug#11113: 23.3; Access to the mini-buff
From: |
Po Lu |
Subject: |
bug#11113: [Tristan Miller] Re: bug#11113: 23.3; Access to the mini-buffer in auctex mode triggers window resize in KDE (Kwin) |
Date: |
Sat, 08 Jun 2024 21:55:03 +0800 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Po Lu <luangruo@yahoo.com> writes:
> A window manager's creatively interpreting (read: failing to observe)
> geometry hints specified by a client is deficient behavior on the window
> manager's part, so the least they could have done should have been
> declining to play "shift the blame." As enforcing window management
> properties otherwise than the client requested was a KWin bug then, so
> it is now, whether they admit it or not, and until they leave their high
> pedestal Emacs users might easily circumvent it by configuring
> `frame-resize-pixelwise' to t.
BTW, it might interest them to know that the wm-spec defines
maximization in quite express terms:
Maximization is a very old feature of window managers. There was even
a ZoomedState in early ICCCM drafts. Maximizing a window should give
it as much of the screen area as possible (this may not be the full
--------------------------------------
screen area, but only a smaller 'workarea', since the window manager
may have reserved certain areas for other windows). A window manager
is expected to remember the geometry of a maximized window and restore
it upon de-maximization. Modern window managers typically allow
separate horizontal and vertical maximization.
Emphasis mine. By any reasonable interpretation, the window manager
should disregard resize increments in resizing maximized windows, and
indeed as far as I'm aware, KWin's design choices have been emulated by
no other conforming window manager.
bug#11113: 23.3; Access to the mini-buffer in auctex mode triggers window resize in KDE (Kwin), Tristan Miller, 2024/06/12