GNU bug report logs - #44961
28.0.50; [feature/pgtk] frame-position returns incorrect information

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 44961 in the body.
You can then email your comments to 44961 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #3 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; [feature/pgtk] frame-position returns incorrect information
Date: Mon, 30 Nov 2020 15:33:53 +0100

This is under Gnome Shell on Debian 10, which I think uses mutter as a
window manager:

./emacs -Q # The frame is near the top-left, I move it to the right bottom quadrant
(pgtk-backend-display-class) => "GdkWaylandDisplay"
(frame-position) => (0 . 0)

GDK_BACKEND=x11 ./emacs -Q
(pgtk-backend-display-class) => "GdkX11Display"
(frame-position) => (0 . 0)

./emacs -Q # emacs master branch
(frame-position) => (2136 . 549)

(also `set-frame-position' doesnʼt work, even though I see it calling
gtk_window_move. I can open a separate report for that)

In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.5, cairo version 1.16.0)
 of 2020-11-24 built on rltb
Repository revision: d6ef9af82eafef33e117dd61aa3bd51a2464fcc6
Repository branch: feature/pgtk
Windowing system distributor 'System Description: Debian GNU/Linux 10 (buster)

Configured using:
 'configure --with-pgtk'

Configured features:
JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GSETTINGS GLIB NOTIFY
INOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ LIBOTF ZLIB
TOOLKIT_SCROLL_BARS GTK3 PGTK XIM MODULES THREADS LIBSYSTEMD JSON
PDUMPER LCMS2

Message #6 received at 44961 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: 44961 <at> debbugs.gnu.org
Subject: Re: bug#44961: 28.0.50; [feature/pgtk] frame-position returns
 incorrect information
Date: Tue, 01 Dec 2020 10:15:55 +0100

Robert Pluim <rpluim <at> gmail.com> writes:

> This is under Gnome Shell on Debian 10, which I think uses mutter as a
> window manager:
>
> ./emacs -Q # The frame is near the top-left, I move it to the right bottom quadrant
> (pgtk-backend-display-class) => "GdkWaylandDisplay"
> (frame-position) => (0 . 0)
>
> GDK_BACKEND=x11 ./emacs -Q
> (pgtk-backend-display-class) => "GdkX11Display"
> (frame-position) => (0 . 0)
>
> ./emacs -Q # emacs master branch
> (frame-position) => (2136 . 549)
>
> (also `set-frame-position' doesnʼt work, even though I see it calling
> gtk_window_move. I can open a separate report for that)

And a side effect of this is that specifying things like 'top or 'left
in 'default-frame-alist' donʼt affect the positioning of frames.

Robert

Message #9 received at 44961 <at> debbugs.gnu.org (full text, mbox):

From: Yuuki Harano <masm+emacs <at> masm11.me>
To: 44961 <at> debbugs.gnu.org
Subject: Re: bug#44961: 28.0.50; [feature/pgtk] frame-position returns
 incorrect information
Date: Sun, 20 Dec 2020 02:42:28 +0900 (JST)

Pgtk emacs doesn't receive events when a window moves, so it can't update the position data.

Also, wayland support code in Gtk ignores gtk_window_move for toplevel windows, so pgtk emacs can't move the window.

-- 
Yuuki Harano

Message #12 received at 44961 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Yuuki Harano <masm+emacs <at> masm11.me>, 44961 <at> debbugs.gnu.org
Subject: Re: bug#44961: 28.0.50; [feature/pgtk] frame-position returns
 incorrect information
Date: Sun, 20 Dec 2020 08:45:58 +0100

> Also, wayland support code in Gtk ignores gtk_window_move for toplevel
> windows, so pgtk emacs can't move the window.

Does it work for child windows?  I'm afraid that sooner or later we have
to encapsulate all Emacs frames in one and the same session in child
windows of one major root window in order to be able to continue our
past frame positioning strategies.  So my question can eventually become
vital for these ...

martin

Message #15 received at 44961 <at> debbugs.gnu.org (full text, mbox):

From: Yuuki Harano <masm+emacs <at> masm11.me>
To: rudalics <at> gmx.at, 44961 <at> debbugs.gnu.org
Subject: Re: bug#44961: 28.0.50; [feature/pgtk] frame-position returns
 incorrect information
Date: Sun, 20 Dec 2020 19:13:11 +0900 (JST)

On Sun, 20 Dec 2020 08:45:58 +0100,
	martin rudalics <rudalics <at> gmx.at> wrote:
> Does it work for child windows?

It is working for Emacs child frames. (frame-position) returns correct
values, and `left` and `top` can be modified by modify-frame-parameters
to move the child frame.

-- 
Yuuki Harano

Message #18 received at 44961 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Yuuki Harano <masm+emacs <at> masm11.me>, 44961 <at> debbugs.gnu.org
Subject: Re: bug#44961: 28.0.50; [feature/pgtk] frame-position returns
 incorrect information
Date: Mon, 21 Dec 2020 16:33:07 +0100

> It is working for Emacs child frames. (frame-position) returns correct
> values, and `left` and `top` can be modified by modify-frame-parameters
> to move the child frame.

OK.  Sooner or later we need a full list of functionalities that rely on
frame positioning and may not work with pgtk.  I suppose we have Emacs'
native tooltips there (which we could then base on child frames), the
speedbar (no idea for that) and all sorts of position parameters set up
in ediff-wind.el.  Could you have a cursory look?  If some "initial"
positioning works for such frames and maybe a repositioning after making
a frame temporarily invisible works too, we might have additional means
to handle these cases.  If anyone else sees a need for repositioning
frames on screen, please add it to that list.

Thanks, martin

Message #21 received at 44961 <at> debbugs.gnu.org (full text, mbox):

From: Yuuki Harano <masm+emacs <at> masm11.me>
To: rudalics <at> gmx.at, 44961 <at> debbugs.gnu.org
Subject: Re: bug#44961: 28.0.50; [feature/pgtk] frame-position returns
 incorrect information
Date: Fri, 01 Jan 2021 17:41:35 +0900 (JST)

Emacs' native tooltips
- initial positioning works.
- repositioning works.

speedbar
- initial positioning doesn't work. always center on monitor.
- repositioning doesn't work.

ediff-wind.el
- initial positioning doesn't work. always center on monitor.
- repositioning doesn't work.

-- 
Yuuki Harano

Message #24 received at 44961 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Yuuki Harano <masm+emacs <at> masm11.me>, 44961 <at> debbugs.gnu.org
Subject: Re: bug#44961: 28.0.50; [feature/pgtk] frame-position returns
 incorrect information
Date: Fri, 1 Jan 2021 11:19:04 +0100

> Emacs' native tooltips
> - initial positioning works.
> - repositioning works.
>
> speedbar
> - initial positioning doesn't work. always center on monitor.
> - repositioning doesn't work.
>
> ediff-wind.el
> - initial positioning doesn't work. always center on monitor.
> - repositioning doesn't work.

Thanks.  So if we can position and reposition our tooltips, I don't
understand why we can't do the same with the other two (and obviously
normal frames either).  Is there some special magic involved with
tooltips?  Is it because they are so small, have no decorations?

martin

Message #27 received at 44961 <at> debbugs.gnu.org (full text, mbox):

From: Yuuki Harano <masm+emacs <at> masm11.me>
To: rudalics <at> gmx.at, 44961 <at> debbugs.gnu.org
Subject: Re: bug#44961: 28.0.50; [feature/pgtk] frame-position returns
 incorrect information
Date: Sun, 03 Jan 2021 18:04:05 +0900 (JST)

> Thanks.  So if we can position and reposition our tooltips, I don't
> understand why we can't do the same with the other two (and obviously
> normal frames either).  Is there some special magic involved with
> tooltips?  Is it because they are so small, have no decorations?

Pgtk's Emacs' native tooltip is implemented by popup window, not toplevel window.
Tooltip doesn't have to be moved by users manually, doesn't have decorations,
and its position is important, so I created it by popup window.

-- 
Yuuki Harano

Message #30 received at 44961 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Yuuki Harano <masm+emacs <at> masm11.me>, 44961 <at> debbugs.gnu.org
Subject: Re: bug#44961: 28.0.50; [feature/pgtk] frame-position returns
 incorrect information
Date: Sun, 3 Jan 2021 10:23:08 +0100

>> Thanks.  So if we can position and reposition our tooltips, I don't
>> understand why we can't do the same with the other two (and obviously
>> normal frames either).  Is there some special magic involved with
>> tooltips?  Is it because they are so small, have no decorations?
>
> Pgtk's Emacs' native tooltip is implemented by popup window, not toplevel window.
> Tooltip doesn't have to be moved by users manually, doesn't have decorations,
> and its position is important, so I created it by popup window.

I see.  So we are left with the fact that we won't be able to position
(and maybe also size) top-level frames in a foreseeable future and our
application writers must keep that in mind.

martin

Message #33 received at 44961 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Yuuki Harano <masm+emacs <at> masm11.me>
Cc: 44961 <at> debbugs.gnu.org
Subject: Re: bug#44961: 28.0.50; [feature/pgtk] frame-position returns
 incorrect information
Date: Mon, 04 Jan 2021 19:15:04 +0100

Yuuki Harano <masm+emacs <at> masm11.me> writes:

> Pgtk emacs doesn't receive events when a window moves, so it can't update the position data.
>
> Also, wayland support code in Gtk ignores gtk_window_move for toplevel windows, so pgtk emacs can't move the window.

Yes, this is the conclusion I came to as well, from reading various
comments by the Wayland developers about how the new paradigm was that
end users are not allowed to know about frame-positions, since thatʼs
Old School(™), and they're New School(™), and normal people who like
to think in coordinate systems are WRONG!
(Iʼm paraphrasing :-) )

It would be nice if frame-positioning on initial frame-creation worked
correctly, since desktop.el does that (I haven't checked if thatʼs
true or not).

Robert

Message #36 received at 44961 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Yuuki Harano <masm+emacs <at> masm11.me>,  44961 <at> debbugs.gnu.org
Subject: Re: bug#44961: 28.0.50; [feature/pgtk] frame-position returns
 incorrect information
Date: Tue, 05 Jan 2021 14:24:08 +0100

Robert Pluim <rpluim <at> gmail.com> writes:

> It would be nice if frame-positioning on initial frame-creation worked
> correctly, since desktop.el does that (I haven't checked if thatʼs
> true or not).

Answering my own question: no it doesnʼt, because frame creation
doesnʼt obey any positioning parameters such as 'top'. Oh well, all
progress involves sacrifices, I guess.

Robert

Message #39 received at 44961 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Robert Pluim <rpluim <at> gmail.com>, Yuuki Harano <masm+emacs <at> masm11.me>,
 44961 <at> debbugs.gnu.org
Subject: Re: bug#44961: 28.0.50; [feature/pgtk] frame-position returns
 incorrect information
Date: Tue, 5 Jan 2021 16:32:19 +0100

>> It would be nice if frame-positioning on initial frame-creation worked
>> correctly, since desktop.el does that (I haven't checked if thatʼs
>> true or not).
>
> Answering my own question: no it doesnʼt, because frame creation
> doesnʼt obey any positioning parameters such as 'top'. Oh well, all
> progress involves sacrifices, I guess.

Yuuki already answered it in an earlier mail:

> speedbar
> - initial positioning doesn't work. always center on monitor.
> - repositioning doesn't work.
>
> ediff-wind.el
> - initial positioning doesn't work. always center on monitor.
> - repositioning doesn't work.

martin

Message #42 received at 44961 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 44961 <at> debbugs.gnu.org, Yuuki Harano <masm+emacs <at> masm11.me>
Subject: Re: bug#44961: 28.0.50; [feature/pgtk] frame-position returns
 incorrect information
Date: Tue, 05 Jan 2021 17:00:43 +0100

martin rudalics <rudalics <at> gmx.at> writes:

>>> It would be nice if frame-positioning on initial frame-creation worked
>>> correctly, since desktop.el does that (I haven't checked if thatʼs
>>> true or not).
>>
>> Answering my own question: no it doesnʼt, because frame creation
>> doesnʼt obey any positioning parameters such as 'top'. Oh well, all
>> progress involves sacrifices, I guess.
>
> Yuuki already answered it in an earlier mail:
>
>> speedbar
>> - initial positioning doesn't work. always center on monitor.
>> - repositioning doesn't work.
>>
>> ediff-wind.el
>> - initial positioning doesn't work. always center on monitor.
>> - repositioning doesn't work.

Indeed. Iʼm behind on my messages :-)

Robert

Message #45 received at 44961 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 44961 <at> debbugs.gnu.org
Subject: Re: bug#44961: 28.0.50; [feature/pgtk] frame-position returns
 incorrect information
Date: Sun, 20 Feb 2022 15:07:39 +0100

Robert Pluim <rpluim <at> gmail.com> writes:

> This is under Gnome Shell on Debian 10, which I think uses mutter as a
> window manager:
>
> ./emacs -Q # The frame is near the top-left, I move it to the right
> bottom quadrant
> (pgtk-backend-display-class) => "GdkWaylandDisplay"
> (frame-position) => (0 . 0)
>
> GDK_BACKEND=x11 ./emacs -Q
> (pgtk-backend-display-class) => "GdkX11Display"
> (frame-position) => (0 . 0)
>
> ./emacs -Q # emacs master branch
> (frame-position) => (2136 . 549)

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

I tried this on the current master with  --with-pgtk, and
(frame-position) seems to report the correct results for me on
Debian/bookworm under Gnome shell (with X).

Are you still seeing this problem on the current trunk?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #50 received at 44961 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 44961 <at> debbugs.gnu.org, Robert Pluim <rpluim <at> gmail.com>
Subject: Re: bug#44961: 28.0.50; [feature/pgtk] frame-position returns
 incorrect information
Date: Sun, 20 Feb 2022 20:57:42 +0100

On Sun, 20 Feb 2022 15:07:39 +0100 Lars Ingebrigtsen <larsi <at> gnus.org> wrote:

> Robert Pluim <rpluim <at> gmail.com> writes:
>
>> This is under Gnome Shell on Debian 10, which I think uses mutter as a
>> window manager:
>>
>> ./emacs -Q # The frame is near the top-left, I move it to the right
>> bottom quadrant
>> (pgtk-backend-display-class) => "GdkWaylandDisplay"
>> (frame-position) => (0 . 0)
>>
>> GDK_BACKEND=x11 ./emacs -Q
>> (pgtk-backend-display-class) => "GdkX11Display"
>> (frame-position) => (0 . 0)
>>
>> ./emacs -Q # emacs master branch
>> (frame-position) => (2136 . 549)
>
> (I'm going through old bug reports that unfortunately weren't resolved
> at the time.)
>
> I tried this on the current master with  --with-pgtk, and
> (frame-position) seems to report the correct results for me on
> Debian/bookworm under Gnome shell (with X).
>
> Are you still seeing this problem on the current trunk?

This sounds like bug#52697, which was fixed on master in 855928082b and
9966d9574b.

Steve Berman

Message #53 received at 44961 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 44961 <at> debbugs.gnu.org, Robert Pluim <rpluim <at> gmail.com>
Subject: Re: bug#44961: 28.0.50; [feature/pgtk] frame-position returns
 incorrect information
Date: Mon, 21 Feb 2022 09:22:21 +0800

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> I tried this on the current master with  --with-pgtk, and
> (frame-position) seems to report the correct results for me on
> Debian/bookworm under Gnome shell (with X).
>
> Are you still seeing this problem on the current trunk?

That was fixed earlier but with the small caveat that the position
reporting sometimes gets completely messed up after a frame is iconified
and deiconified.

AFAICT it's a problem in GTK, but it happens too randomly for me to
track down.

Message #56 received at 44961 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: Po Lu <luangruo <at> yahoo.com>, 44961 <at> debbugs.gnu.org,
 Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#44961: 28.0.50; [feature/pgtk] frame-position returns
 incorrect information
Date: Mon, 21 Feb 2022 12:17:18 +0100

>>>>> On Sun, 20 Feb 2022 20:57:42 +0100, Stephen Berman <stephen.berman <at> gmx.net> said:

    Stephen> On Sun, 20 Feb 2022 15:07:39 +0100 Lars Ingebrigtsen <larsi <at> gnus.org> wrote:
    >> Robert Pluim <rpluim <at> gmail.com> writes:
    >> 
    >>> This is under Gnome Shell on Debian 10, which I think uses mutter as a
    >>> window manager:
    >>> 
    >>> ./emacs -Q # The frame is near the top-left, I move it to the right
    >>> bottom quadrant
    >>> (pgtk-backend-display-class) => "GdkWaylandDisplay"
    >>> (frame-position) => (0 . 0)
    >>> 
    >>> GDK_BACKEND=x11 ./emacs -Q
    >>> (pgtk-backend-display-class) => "GdkX11Display"
    >>> (frame-position) => (0 . 0)
    >>> 
    >>> ./emacs -Q # emacs master branch
    >>> (frame-position) => (2136 . 549)
    >> 
    >> (I'm going through old bug reports that unfortunately weren't resolved
    >> at the time.)
    >> 
    >> I tried this on the current master with  --with-pgtk, and
    >> (frame-position) seems to report the correct results for me on
    >> Debian/bookworm under Gnome shell (with X).
    >> 
    >> Are you still seeing this problem on the current trunk?

    Stephen> This sounds like bug#52697, which was fixed on master in 855928082b and
    Stephen> 9966d9574b.

It does, but I think that only fixed part of the issue. With
GDK_BACKEND=x11, I get the right results, but with the Wayland backend
I always get "(26 . 23)" wherever I place the frame(although if I
maximize the frame I get "(0 . 0)"

This might be an effect of the Wayland coordinate system insanity that
they've foisted on the rest of the world.

Robert
-- 

Message #59 received at 44961 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 44961 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>,
 Stephen Berman <stephen.berman <at> gmx.net>
Subject: Re: bug#44961: 28.0.50; [feature/pgtk] frame-position returns
 incorrect information
Date: Mon, 21 Feb 2022 19:28:27 +0800

Robert Pluim <rpluim <at> gmail.com> writes:

>     Stephen> This sounds like bug#52697, which was fixed on master in 855928082b and
>     Stephen> 9966d9574b.

> It does, but I think that only fixed part of the issue. With
> GDK_BACKEND=x11, I get the right results, but with the Wayland backend
> I always get "(26 . 23)" wherever I place the frame(although if I
> maximize the frame I get "(0 . 0)"

Could you tell the result with an undecorated frame?

> This might be an effect of the Wayland coordinate system insanity that
> they've foisted on the rest of the world.

I tend to agree.

Message #62 received at 44961 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 44961 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>,
 Stephen Berman <stephen.berman <at> gmx.net>
Subject: Re: bug#44961: 28.0.50; [feature/pgtk] frame-position returns
 incorrect information
Date: Mon, 21 Feb 2022 19:46:27 +0800

Po Lu <luangruo <at> yahoo.com> writes:

> Could you tell the result with an undecorated frame?

Nevermind, it's there to trick programs which rely on coordinates to
determine tiling state to think that the window is not tiled at the top
left corner when it's not maximized (or otherwise tiled that way.)

Should we respect that information from GTK?  WDYT?

Thanks.

Message #65 received at 44961 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 44961 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>,
 Stephen Berman <stephen.berman <at> gmx.net>
Subject: Re: bug#44961: 28.0.50; [feature/pgtk] frame-position returns
 incorrect information
Date: Mon, 21 Feb 2022 12:49:48 +0100

>>>>> On Mon, 21 Feb 2022 19:28:27 +0800, Po Lu <luangruo <at> yahoo.com> said:

    Po> Robert Pluim <rpluim <at> gmail.com> writes:
    Stephen> This sounds like bug#52697, which was fixed on master in 855928082b and
    Stephen> 9966d9574b.

    >> It does, but I think that only fixed part of the issue. With
    >> GDK_BACKEND=x11, I get the right results, but with the Wayland backend
    >> I always get "(26 . 23)" wherever I place the frame(although if I
    >> maximize the frame I get "(0 . 0)"

    Po> Could you tell the result with an undecorated frame?

If I create a second frame with

(make-frame '((undecorated . t)))

then

(frame-position) => (0 . 0)

wherever that frame is positioned.

Robert
-- 

Message #68 received at 44961 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 44961 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>,
 Stephen Berman <stephen.berman <at> gmx.net>
Subject: Re: bug#44961: 28.0.50; [feature/pgtk] frame-position returns
 incorrect information
Date: Mon, 21 Feb 2022 19:55:29 +0800

Robert Pluim <rpluim <at> gmail.com> writes:

> If I create a second frame with
>
> (make-frame '((undecorated . t)))
>
> then
>
> (frame-position) => (0 . 0)
>
> wherever that frame is positioned.

That's what I would have expected, thanks.  Please see the other message
I sent.

Message #71 received at 44961 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 44961 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>,
 Stephen Berman <stephen.berman <at> gmx.net>
Subject: Re: bug#44961: 28.0.50; [feature/pgtk] frame-position returns
 incorrect information
Date: Mon, 21 Feb 2022 13:58:12 +0100

>>>>> On Mon, 21 Feb 2022 19:46:27 +0800, Po Lu <luangruo <at> yahoo.com> said:

    Po> Po Lu <luangruo <at> yahoo.com> writes:
    >> Could you tell the result with an undecorated frame?

    Po> Nevermind, it's there to trick programs which rely on coordinates to
    Po> determine tiling state to think that the window is not tiled at the top
    Po> left corner when it's not maximized (or otherwise tiled that way.)

    Po> Should we respect that information from GTK?  WDYT?

Respect which information from GTK? If reporting (0 . 0) for
undecorated and fullboth frames and a fixed value for decorated frames
works, then I see no problem with it (although I donʼt run pgtk as my
daily driver, so perhaps there are other issues). The frame
positioning portions of desktop.el and similar are doomed under
Wayland in any case.

Robert
-- 

Message #74 received at 44961 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 44961 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>,
 Stephen Berman <stephen.berman <at> gmx.net>
Subject: Re: bug#44961: 28.0.50; [feature/pgtk] frame-position returns
 incorrect information
Date: Mon, 21 Feb 2022 21:26:37 +0800

Robert Pluim <rpluim <at> gmail.com> writes:

> If reporting (0 . 0) for undecorated and fullboth frames and a fixed
> value for decorated frames works, then I see no problem with it
> (although I donʼt run pgtk as my daily driver, so perhaps there are
> other issues). The frame positioning portions of desktop.el and
> similar are doomed under Wayland in any case.

Yes, indeed.  Let's keep the status quo for now and see if anyone
complains in the future.

Thanks for your input.

Message #79 received at 44961-done <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Po Lu <luangruo <at> yahoo.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 44961-done <at> debbugs.gnu.org,
 Stephen Berman <stephen.berman <at> gmx.net>
Subject: Re: bug#44961: 28.0.50; [feature/pgtk] frame-position returns
 incorrect information
Date: Mon, 21 Feb 2022 15:50:35 +0100

>>>>> On Mon, 21 Feb 2022 21:26:37 +0800, Po Lu <luangruo <at> yahoo.com> said:

    Po> Robert Pluim <rpluim <at> gmail.com> writes:
    >> If reporting (0 . 0) for undecorated and fullboth frames and a fixed
    >> value for decorated frames works, then I see no problem with it
    >> (although I donʼt run pgtk as my daily driver, so perhaps there are
    >> other issues). The frame positioning portions of desktop.el and
    >> similar are doomed under Wayland in any case.

    Po> Yes, indeed.  Let's keep the status quo for now and see if anyone
    Po> complains in the future.

OK. Iʼll close the bug for now, we can always reopen it later.

    Po> Thanks for your input.

np

Robert
-- 

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.