[Sawfish] Re: Firefox/Waterfox window size is reported incorrectly in resize overlay.

[GSR - FR <famrom@xxxxxxxxxxxxxxxxxxxx>]

Hi,
Robert.Zenz@xxxxxxxxxxxxxx (2023-07-07 at 1837.38 +0200):
> I haven't had time to look into this so far, but I just noticed that
> the Firefox/Waterfox window size is being reported incorrectly by the
> resize-overlay.
> 
> I've enabled "Move/Resize -> Show current dimensions of window while
> resizing" and it seems like that the displayed/reported window size is
> the actual size minus the *minimum* size, so the displayed size is a
> few hundred pixels wrong. See the attached screenshot.
> 
> I can't remember when it started, but so far Firefox/Waterfox seems to
> be the only application/window which exhibits this behavior. Other
> applications which have a fixed minimum size of the window do not
> display this. I've updated to the latest master and this still shows.
> 
> Has somebody else seen this?

Yes, numbers in info window can be weird. What you saw also happens
with the tool window of geeqie (old version, and IIRC it even did it
when the name was gqview... thus long ago). No idea if SF should do
it, IMHO no, it should list the total pixel size, with caveat:

Gimp toolbox (classic multiwindow, not the new "all in one") is even
more complex as it mixes pixels and "steps", so reading the info
window can be a bit weird at first. Example:

---8<---
WM_WINDOW_ROLE(STRING) = "gimp-toolbox-1"
WM_NORMAL_HINTS(WM_SIZE_HINTS):
		user specified location: 34, 1
		program specified minimum size: 68 by 366
		program specified resize increment: 34 by 1
		program specified base size: 34 by 0
		window gravity: NorthWest
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST
WM_CLASS(STRING) = "gimp", "Gimp"
WM_ICON_NAME(STRING) = "Toolbox"
_NET_WM_ICON_NAME(UTF8_STRING) = "Toolbox"
WM_NAME(STRING) = "Toolbox"
_NET_WM_NAME(UTF8_STRING) = "Toolbox"
--->8---

34 is the size required per button, 68 means two columns of them.
Sawfish reports 2x366 in the info window and does not let you go below
366 (mouse moves, but window locks). At least in this case there is no
pixel subtraction.

Another example, rxvt show steps both for X and Y:

---8<---
WM_CLASS(STRING) = "rxvt-unicode", "URxvt"
WM_HINTS(WM_HINTS):
		Client accepts input or input focus: True
		Initial state is Normal State.
		window id # of group leader: 0x2e00007
WM_NORMAL_HINTS(WM_SIZE_HINTS):
		program specified minimum size: 28 by 19
		program specified resize increment: 9 by 15
		program specified base size: 19 by 4
		window gravity: NorthWest
--->8---

Rxvt, being a terminal, can display one step at minimum plus space for
the scrollbar, and Sawfish always reports the full steps, not the
pixels. IIUC scrollbar is 15 and own inner border is 2, so base size
is 15+2+2 x 2+2. Font size (9x15) sets the resize increment per step,
and base plus one step gives the minimum size. Default size is 80x24
and you can go down to 1x1 (one character).

I think one of the documents that matter is
https://tronche.com/gui/x/icccm/sec-4.html#s-4.1.2.3 and wonder if the
right thing to do is to only subtract in cases where resize increment
is >1, to properly compute steps (spec encourages showing steps to
user). Or to show both screen pixels (no subtraction) and steps (as
"pixels: WxH - steps: IxJ" eg) in the popup, when applicable.

In any case, I do not discard it will cause other issues with programs
that went creative in different way (from past experience about the
meaning of "uniquely identifies that window among all windows that
have the same client leader window" WRT values of WM_WINDOW_ROLE).

In conclusion, I think showing full size instead of allowed size
change is way better. And only do maths for when steps apply.

Cheers,
GSR
 

-- 
Sawfish ML