Child-frame can not move to proper position when run "env GDK_SCALE=2 emacs"

Child-frame can not move to proper position when run "env GDK_SCALE=2 emacs"

[Feng Shu]

When I run "env GDK_SCALE=2 emacs", the below code can not work properly

```
(let ((test (let ((after-make-frame-functions nil))
              (make-frame
               `((parent-frame . ,(window-frame))
                 (width . 50)
                 (height . 1)))))
      (pos (posn-x-y (posn-at-point (point) (selected-window)))))
  (set-frame-position test (car pos) (cdr pos)))<I>
```

When I eval the code at the <I>, the new created frame can not move to
<I>, it move to the wrong position.




-- 

Re: Child-frame can not move to proper position when run "env GDK_SCALE=2 emacs"

[martin rudalics]

 > When I run "env GDK_SCALE=2 emacs", the below code can not work properly
 >
 > ```
 > (let ((test (let ((after-make-frame-functions nil))
 >                (make-frame
 >                 `((parent-frame . ,(window-frame))
 >                   (width . 50)
 >                   (height . 1)))))
 >        (pos (posn-x-y (posn-at-point (point) (selected-window)))))
 >    (set-frame-position test (car pos) (cdr pos)))<I>
 > ```
 >
 > When I eval the code at the <I>, the new created frame can not move to
 > <I>, it move to the wrong position.

What happens when you divide the pos values by two?

We do not expose the GTK/GDK scale values in Lisp, maybe we should.
Robert any ideas?

martin

Re: Child-frame can not move to proper position when run "env GDK_SCALE=2 emacs"

[Feng Shu]

martin rudalics <rudalics@gmx.at> writes:

>> When I run "env GDK_SCALE=2 emacs", the below code can not work properly
>>
>> ```
>> (let ((test (let ((after-make-frame-functions nil))
>>                (make-frame
>>                 `((parent-frame . ,(window-frame))
>>                   (width . 50)
>>                   (height . 1)))))
>>        (pos (posn-x-y (posn-at-point (point) (selected-window)))))
>>    (set-frame-position test (car pos) (cdr pos)))<I>
>> ```
>>
>> When I eval the code at the <I>, the new created frame can not move to
>> <I>, it move to the wrong position.
>
> What happens when you divide the pos values by two?

When (/ x 2) and (/ y 2), It works! :-)

>
> We do not expose the GTK/GDK scale values in Lisp, maybe we should.
> Robert any ideas?
>
> martin
>

-- 

Re: Child-frame can not move to proper position when run "env GDK_SCALE=2 emacs"

[martin rudalics]

 >> What happens when you divide the pos values by two?
 >
 > When (/ x 2) and (/ y 2), It works! :-)

So it's just the same issue as everywhere else.  Now I wonder whether
the positions returned by `pos-visible-in-window-p' are wrong in this
case or the values passed to `set-frame-position'.  Maybe that's just
a philosphical question though.

martin

Re: Child-frame can not move to proper position when run "env GDK_SCALE=2 emacs"

[Robert Pluim]

"Feng Shu" <tumashu@163.com> writes:

> martin rudalics <rudalics@gmx.at> writes:
>
>>> When I run "env GDK_SCALE=2 emacs", the below code can not work properly
>>>
>>> ```
>>> (let ((test (let ((after-make-frame-functions nil))
>>>                (make-frame
>>>                 `((parent-frame . ,(window-frame))
>>>                   (width . 50)
>>>                   (height . 1)))))
>>>        (pos (posn-x-y (posn-at-point (point) (selected-window)))))
>>>    (set-frame-position test (car pos) (cdr pos)))<I>
>>> ```
>>>
>>> When I eval the code at the <I>, the new created frame can not move to
>>> <I>, it move to the wrong position.
>>
>> What happens when you divide the pos values by two?
>
> When (/ x 2) and (/ y 2), It works! :-)
>
>>
>> We do not expose the GTK/GDK scale values in Lisp, maybe we should.
>> Robert any ideas?

Ugh. I don't think we should expose the scale values, we should fix
whatever the issue is with set-frame-position. Naively that's the
attached patch, but I worry about other places that assume unscaled
coordinates. I'll run with it for a while and see if any pop up.

Longer term we need to implement your 'eliminate direct X calls' plan,
and have everything inside Emacs use GTK coordinates.

Robert

diff --git i/src/xterm.c w/src/xterm.c
index f771631daf..950e6231e0 100644
--- i/src/xterm.c
+++ w/src/xterm.c
@@ -10311,6 +10311,14 @@ x_set_offset (struct frame *f, register int xoff, register int yoff, int change_
 {
   int modified_top, modified_left;
 
+#ifdef USE_GTK
+  {
+    int scale = xg_get_scale(f);
+    xoff /= scale;
+    yoff /= scale;
+  }
+#endif
+
   if (change_gravity > 0)
     {
       f->top_pos = yoff;

Re: Child-frame can not move to proper position when run "env GDK_SCALE=2 emacs"

[Robert Pluim]

martin rudalics <rudalics@gmx.at> writes:

>>> What happens when you divide the pos values by two?
>>
>> When (/ x 2) and (/ y 2), It works! :-)
>
> So it's just the same issue as everywhere else.  Now I wonder whether
> the positions returned by `pos-visible-in-window-p' are wrong in this
> case or the values passed to `set-frame-position'.  Maybe that's just
> a philosphical question though.

I guess you meant posn-at-point. That returns the position in pixels,
unscaled, so I think it's correct.

Robert

Re: Child-frame can not move to proper position when run "env GDK_SCALE=2 emacs"

[Dmitry Gutov]

On 1/9/18 1:06 PM, Robert Pluim wrote:

> Ugh. I don't think we should expose the scale values, we should fix
> whatever the issue is with set-frame-position. Naively that's the
> attached patch, but I worry about other places that assume unscaled
> coordinates. I'll run with it for a while and see if any pop up.

This seems to fix the immediate issue (company-mode popup based on child 
frames is now positioned correctly on my HiDPI screen). Would be great 
to get this one into Emacs 26.

> Longer term we need to implement your 'eliminate direct X calls' plan,
> and have everything inside Emacs use GTK coordinates.
> 
> Robert
> 
> diff --git i/src/xterm.c w/src/xterm.c
> index f771631daf..950e6231e0 100644
> --- i/src/xterm.c
> +++ w/src/xterm.c
> @@ -10311,6 +10311,14 @@ x_set_offset (struct frame *f, register int xoff, register int yoff, int change_
>   {
>     int modified_top, modified_left;
>   
> +#ifdef USE_GTK
> +  {
> +    int scale = xg_get_scale(f);
> +    xoff /= scale;
> +    yoff /= scale;
> +  }
> +#endif
> +
>     if (change_gravity > 0)
>       {
>         f->top_pos = yoff;
> 

Re: Child-frame can not move to proper position when run "env GDK_SCALE=2 emacs"

[martin rudalics]

 > Ugh. I don't think we should expose the scale values, we should fix
 > whatever the issue is with set-frame-position. Naively that's the
 > attached patch, but I worry about other places that assume unscaled
 > coordinates. I'll run with it for a while and see if any pop up.

So I suppose Emacs tooltips (the ones enabled by customizing
`x-gtk-use-system-tooltips' to nil) were affectd by this as well and
should now work properly with your patch.  Can you verify that?

In either case I would like to install the patch on the release branch
so anyone using GTK/GDK scaling please try it ASAP.

Many thanks, martin

Re: Child-frame can not move to proper position when run "env GDK_SCALE=2 emacs"

[martin rudalics]

 >> So it's just the same issue as everywhere else.  Now I wonder whether
 >> the positions returned by `pos-visible-in-window-p' are wrong in this
 >> case or the values passed to `set-frame-position'.  Maybe that's just
 >> a philosphical question though.
 >
 > I guess you meant posn-at-point.

Which eventually falls back on `pos-visible-in-window-p', yes.

 > That returns the position in pixels,
 > unscaled, so I think it's correct.

Thus we can be sure that the caller of our position functions can
always contine to think in terms of unscaled positions so scaling is
"transparent"?

I think that after you fixed all this we should somewhere add a
paragraph to the Elisp manual explaining whether, why and how this
works.

martin

Re: Child-frame can not move to proper position when run "env GDK_SCALE=2 emacs"

[Stefan Monnier]

>> +  {
>> +    int scale = xg_get_scale(f);
>> +    xoff /= scale;
>> +    yoff /= scale;
>> +  }

BTW, why do we presume that scaling is an integer?


        Stefan

Re: Child-frame can not move to proper position when run "env GDK_SCALE=2 emacs"

[Robert Pluim]

martin rudalics <rudalics@gmx.at> writes:

>> Ugh. I don't think we should expose the scale values, we should fix
>> whatever the issue is with set-frame-position. Naively that's the
>> attached patch, but I worry about other places that assume unscaled
>> coordinates. I'll run with it for a while and see if any pop up.
>
> So I suppose Emacs tooltips (the ones enabled by customizing
> `x-gtk-use-system-tooltips' to nil) were affectd by this as well and
> should now work properly with your patch.  Can you verify that?
>

I don't use tooltips at all normally, but in quick testing this patch
makes no difference in the GDK_SCALE=2 case.

> In either case I would like to install the patch on the release branch
> so anyone using GTK/GDK scaling please try it ASAP.

I have no objection. I'm still a little uncomfortable that it's more
of a bandaid than a real fix, but a real fix is many month away.

Robert

Re: Child-frame can not move to proper position when run "env GDK_SCALE=2 emacs"

[Robert Pluim]

martin rudalics <rudalics@gmx.at> writes:

>> That returns the position in pixels,
>> unscaled, so I think it's correct.
>
> Thus we can be sure that the caller of our position functions can
> always contine to think in terms of unscaled positions so scaling is
> "transparent"?

I think so. I think that should be our goal anyway.

> I think that after you fixed all this we should somewhere add a
> paragraph to the Elisp manual explaining whether, why and how this
> works.

That depends on what you mean by 'this'. If you mean 'Emacs always
works in pixels regardless of scaling', then 'Coordinates and Windows'
in windows.texi would be a good place. I'm just not sure we can
guarantee that yet (I know that e.g. frameset-restore misbehaves in
the presence of scaling, and I haven't tracked down why yet)

Robert

Re: Child-frame can not move to proper position when run "env GDK_SCALE=2 emacs"

[Robert Pluim]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> +  {
>>> +    int scale = xg_get_scale(f);
>>> +    xoff /= scale;
>>> +    yoff /= scale;
>>> +  }
>
> BTW, why do we presume that scaling is an integer?

We don't, it's how GTK defines it.

Robert

Re: Child-frame can not move to proper position when run "env GDK_SCALE=2 emacs"

[Dmitry Gutov]

On 1/10/18 4:48 PM, Robert Pluim wrote:

> We don't, it's how GTK defines it.

Any idea how Unity supports fractional scale values, then?

Re: Child-frame can not move to proper position when run "env GDK_SCALE=2 emacs"

[Robert Pluim]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 1/10/18 4:48 PM, Robert Pluim wrote:
>
>> We don't, it's how GTK defines it.
>
> Any idea how Unity supports fractional scale values, then?

Using GTK on X? I thought that was only on Wayland, where as far as I
can tell the relevant APIs return 'double'.

Robert

Re: Child-frame can not move to proper position when run "env GDK_SCALE=2 emacs"

[Dmitry Gutov]

On 1/10/18 6:08 PM, Robert Pluim wrote:

>> Any idea how Unity supports fractional scale values, then?
> 
> Using GTK on X?

Yup. Unity is a fork of Gnome 3, and no Wayland support here (not in 
Ubuntu 17.04, at least).

And the fractional values do get reflected in the text size in menus, 
the Files app, etc.

Re: Child-frame can not move to proper position when run "env GDK_SCALE=2 emacs"

[Robert Pluim]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 1/10/18 6:08 PM, Robert Pluim wrote:
>
>>> Any idea how Unity supports fractional scale values, then?
>>
>> Using GTK on X?
>
> Yup. Unity is a fork of Gnome 3, and no Wayland support here (not in
> Ubuntu 17.04, at least).
>
> And the fractional values do get reflected in the text size in menus,
> the Files app, etc.

They must be using something other than gtk_widget_get_scale_factor
then. Or they've changed it to support non-integer values.

Robert

Re: Child-frame can not move to proper position when run "env GDK_SCALE=2 emacs"

[Dmitry Gutov]

On 1/10/18 6:58 PM, Robert Pluim wrote:

> They must be using something other than gtk_widget_get_scale_factor
> then. Or they've changed it to support non-integer values.

Indeed, it seems like this is a value-add over GNOME. Canonical is said 
to use some patched versions of libraries, maybe it's one of the places.

Or it performs additional scaling in the compositor, like described 
here: https://wiki.gnome.org/Initiatives/FracionalScaling In that case, 
the proposed fix might work with those cases too.

Re: Child-frame can not move to proper position when run "env GDK_SCALE=2 emacs"

[Dmitry Gutov]

On 1/10/18 1:19 PM, martin rudalics wrote:

> So I suppose Emacs tooltips (the ones enabled by customizing
> `x-gtk-use-system-tooltips' to nil) were affectd by this as well and
> should now work properly with your patch.

They don't seem affected here either. They are positioned correctly both 
with and without the patch.

> In either case I would like to install the patch on the release branch
> so anyone using GTK/GDK scaling please try it ASAP.

Like mentioned before, it improves the behavior of Feng Shu's code for me.

Re: Child-frame can not move to proper position when run "env GDK_SCALE=2 emacs"

[martin rudalics]

 > I don't use tooltips at all normally, but in quick testing this patch
 > makes no difference in the GDK_SCALE=2 case.

Then the problem seems to occur exclusively when we want to position a
window (a tooltip window in xg_show_tooltip, a scroll bar window in
xg_update_scrollbar_pos, or a window corresponding to a child frame as
in the present case) relative to its Emacs parent window.  It seems to
never occur when we want to position a frame's window relative to the
top-level window.

martin

Re: Child-frame can not move to proper position when run "env GDK_SCALE=2 emacs"

[martin rudalics]

 > That depends on what you mean by 'this'. If you mean 'Emacs always
 > works in pixels regardless of scaling', then 'Coordinates and Windows'
 > in windows.texi would be a good place. I'm just not sure we can
 > guarantee that yet (I know that e.g. frameset-restore misbehaves in
 > the presence of scaling, and I haven't tracked down why yet)

I meant when and where programmers have to be aware of the presence of
scaling.  If we can make scaling completely transparent, they probably
can ignore this issue.  If we can't or there are still unsolved issues
(like the one with the frame size changing when enabling or disabling
scroll bars) we should mention it somewhere.

martin