bug#31031: 27.0; (elisp) `Position Parameters', floating-point values

[Robert Pluim]

martin rudalics <rudalics@gmx.at> writes:

>>> Can you try fixing that in some consistent manner?  You can find the
>>> corresponding code in x_calc_absolute_position in xterm.c.  BTW, does
>>> it work right when you use the "(- POS)" specification?
>>
>> (modify-frame-parameters nil '((user-position . t) (left .   (- 0))))
>>
>> gives the same offset effect as
>>
>> (modify-frame-parameters nil '((user-position . t) (left .  1.0)))
>
> So we should try fixing (or documenting) the misbehavior of the (- n)
> notation first.

As noted elsewhere, I think this is a window manager issue. Iʼd expect those
two calls to give the same effect, which is what I see.

>> D'oh. Of course, top is the right parameter to use. With that the
>> frame switches monitor between top and bottom, so that would imply
>> that the same switching should happen for "left". Iʼm undecided so far
>> as to which I think is the "correct" behaviour.
>
> I'm not sure I understand.  Do you mean that when you change the value
> of 'left' the frame always stays within the left monitor while when
> you change 'top' the frame moves from the upper to the lower monitor
> and back?  That would be queer.

Iʼll have to retest this one, I may have missed a case.

>>>> [1]  Not completely to the right, but thatʼs a different issue
>>>
>>> Probably a problem with calculating the decorations.  Does
>>> (frame-geometry) return "reasonable" values for your frame?
>>
>> (display-monitor-attributes-list)
>>    (((name . "XWAYLAND0") (geometry 0 540 3840 2160) (workarea 0 540 3840
>>    2094) (mm-size 350 190) (frames #<frame *unsent wide reply to martin
>>    rudalics* 0x3d5ce80> #<frame *info* 0x89f6ff0> #<frame *scratch* 
>> 0x87f1a00>)
>>    (source . "Gdk")))
>>
>> (modify-frame-parameters nil '((user-position . t) (left .  1.0)))
>>
>> (frame-geometry)
>>    ((outer-position 2340 . 1730) (outer-size 1480 . 824)
>
> Hmm ... 2340 + 1480 gives 3820 which is obviously 20 pixels to the
> left of 3840.  This clearly went wrong.  Did we _ask_ for 2340 or
> 2360?

That I donʼt know, Iʼll find out...

>>    (external-border-size 20 . 20) (outer-border-width . 0)
>>    (title-bar-size 0 . 70) (menu-bar-external . t) (menu-bar-size 0 . 0)
>>    (tool-bar-external . t) (tool-bar-position . top) (tool-bar-size 0
>>    . 0) (internal-border-width . 0))
>>
>> (+ 2340 1480) => 3820, + external-border-size? In any case, visually
>> the frame is not flush right.
>
> Do we anywhere add only one 'external-border-size' instead of two?
>
>> If I correct the visual aspect:
>>
>> (modify-frame-parameters nil '((left .   (+ 2400))))
>>
>> (frame-geometry)
>>    ((outer-position 2380 . 1586) (outer-size 1480 . 824)
>>    (external-border-size 20 . 20) (outer-border-width . 0)
>>    (title-bar-size 0 . 70) (menu-bar-external . t) (menu-bar-size 0 . 0)
>>    (tool-bar-external . t) (tool-bar-position . top) (tool-bar-size 0
>>    . 0) (internal-border-width . 0))
>>
>> which to me says thereʼs a (-20) error for the outer-position at
>> least.
>
> Why did you ask for 2400 and not for 2360?  If the position value is
> too large the window manager might try to fit the frame onto the
> screen.  OTOH "correcting" this to 2380 means there are 20 pixels (the
> full right external border) missing on the right if not I am missing
> something.

I asked for 2400 because if I ask for 2360 the frame is not flush
right.

> BTW is this on a high resolution display?  Would/should we scale
> external borders on such a display too?

Yes, itʼs high resolution, but 20 pixels seems like more than can be
accounted for by scaling.

> martin
>
>> Iʼll take a look at x_calc_absolute_position.

I think weʼre getting a -20 offset back from X somewhere when querying
the frame size/position. If I look at this hunk in
x_real_pos_and_offsets:

#ifdef USE_XCB
      geom = xcb_get_geometry_reply (xcb_conn, geom_cookie, NULL);
      if (geom)
        {
          real_x = geom->x;

then real_x there is -20 when the frame is flush left. Should we be
using gdk/gtk calls to get the window geometry?

Robert