* bug#44961: 28.0.50; [feature/pgtk] frame-position returns incorrect information
@ 2020-11-30 14:33 Robert Pluim
2020-12-01 9:15 ` Robert Pluim
` (3 more replies)
0 siblings, 4 replies; 25+ messages in thread
From: Robert Pluim @ 2020-11-30 14:33 UTC (permalink / raw)
To: 44961
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#44961: 28.0.50; [feature/pgtk] frame-position returns incorrect information
2020-11-30 14:33 bug#44961: 28.0.50; [feature/pgtk] frame-position returns incorrect information Robert Pluim
@ 2020-12-01 9:15 ` Robert Pluim
2020-12-19 17:42 ` Yuuki Harano
` (2 subsequent siblings)
3 siblings, 0 replies; 25+ messages in thread
From: Robert Pluim @ 2020-12-01 9:15 UTC (permalink / raw)
To: 44961
Robert Pluim <rpluim@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
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#44961: 28.0.50; [feature/pgtk] frame-position returns incorrect information
2020-11-30 14:33 bug#44961: 28.0.50; [feature/pgtk] frame-position returns incorrect information Robert Pluim
2020-12-01 9:15 ` Robert Pluim
@ 2020-12-19 17:42 ` Yuuki Harano
2020-12-20 7:45 ` martin rudalics
2021-01-04 18:15 ` Robert Pluim
2021-01-01 8:41 ` Yuuki Harano
2022-02-20 14:07 ` Lars Ingebrigtsen
3 siblings, 2 replies; 25+ messages in thread
From: Yuuki Harano @ 2020-12-19 17:42 UTC (permalink / raw)
To: 44961
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#44961: 28.0.50; [feature/pgtk] frame-position returns incorrect information
2020-12-19 17:42 ` Yuuki Harano
@ 2020-12-20 7:45 ` martin rudalics
2020-12-20 10:13 ` Yuuki Harano
2021-01-04 18:15 ` Robert Pluim
1 sibling, 1 reply; 25+ messages in thread
From: martin rudalics @ 2020-12-20 7:45 UTC (permalink / raw)
To: Yuuki Harano, 44961
> 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
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#44961: 28.0.50; [feature/pgtk] frame-position returns incorrect information
2020-12-20 7:45 ` martin rudalics
@ 2020-12-20 10:13 ` Yuuki Harano
2020-12-21 15:33 ` martin rudalics
0 siblings, 1 reply; 25+ messages in thread
From: Yuuki Harano @ 2020-12-20 10:13 UTC (permalink / raw)
To: rudalics, 44961
On Sun, 20 Dec 2020 08:45:58 +0100,
martin rudalics <rudalics@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
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#44961: 28.0.50; [feature/pgtk] frame-position returns incorrect information
2020-12-20 10:13 ` Yuuki Harano
@ 2020-12-21 15:33 ` martin rudalics
0 siblings, 0 replies; 25+ messages in thread
From: martin rudalics @ 2020-12-21 15:33 UTC (permalink / raw)
To: Yuuki Harano, 44961
> 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
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#44961: 28.0.50; [feature/pgtk] frame-position returns incorrect information
2020-11-30 14:33 bug#44961: 28.0.50; [feature/pgtk] frame-position returns incorrect information Robert Pluim
2020-12-01 9:15 ` Robert Pluim
2020-12-19 17:42 ` Yuuki Harano
@ 2021-01-01 8:41 ` Yuuki Harano
2021-01-01 10:19 ` martin rudalics
2022-02-20 14:07 ` Lars Ingebrigtsen
3 siblings, 1 reply; 25+ messages in thread
From: Yuuki Harano @ 2021-01-01 8:41 UTC (permalink / raw)
To: rudalics, 44961
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#44961: 28.0.50; [feature/pgtk] frame-position returns incorrect information
2021-01-01 8:41 ` Yuuki Harano
@ 2021-01-01 10:19 ` martin rudalics
2021-01-03 9:04 ` Yuuki Harano
0 siblings, 1 reply; 25+ messages in thread
From: martin rudalics @ 2021-01-01 10:19 UTC (permalink / raw)
To: Yuuki Harano, 44961
> 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
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#44961: 28.0.50; [feature/pgtk] frame-position returns incorrect information
2021-01-01 10:19 ` martin rudalics
@ 2021-01-03 9:04 ` Yuuki Harano
2021-01-03 9:23 ` martin rudalics
0 siblings, 1 reply; 25+ messages in thread
From: Yuuki Harano @ 2021-01-03 9:04 UTC (permalink / raw)
To: rudalics, 44961
> 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
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#44961: 28.0.50; [feature/pgtk] frame-position returns incorrect information
2021-01-03 9:04 ` Yuuki Harano
@ 2021-01-03 9:23 ` martin rudalics
0 siblings, 0 replies; 25+ messages in thread
From: martin rudalics @ 2021-01-03 9:23 UTC (permalink / raw)
To: Yuuki Harano, 44961
>> 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
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#44961: 28.0.50; [feature/pgtk] frame-position returns incorrect information
2020-12-19 17:42 ` Yuuki Harano
2020-12-20 7:45 ` martin rudalics
@ 2021-01-04 18:15 ` Robert Pluim
2021-01-05 13:24 ` Robert Pluim
1 sibling, 1 reply; 25+ messages in thread
From: Robert Pluim @ 2021-01-04 18:15 UTC (permalink / raw)
To: Yuuki Harano; +Cc: 44961
Yuuki Harano <masm+emacs@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
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#44961: 28.0.50; [feature/pgtk] frame-position returns incorrect information
2021-01-04 18:15 ` Robert Pluim
@ 2021-01-05 13:24 ` Robert Pluim
2021-01-05 15:32 ` martin rudalics
0 siblings, 1 reply; 25+ messages in thread
From: Robert Pluim @ 2021-01-05 13:24 UTC (permalink / raw)
To: Yuuki Harano, 44961
Robert Pluim <rpluim@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
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#44961: 28.0.50; [feature/pgtk] frame-position returns incorrect information
2021-01-05 13:24 ` Robert Pluim
@ 2021-01-05 15:32 ` martin rudalics
2021-01-05 16:00 ` Robert Pluim
0 siblings, 1 reply; 25+ messages in thread
From: martin rudalics @ 2021-01-05 15:32 UTC (permalink / raw)
To: Robert Pluim, Yuuki Harano, 44961
>> 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
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#44961: 28.0.50; [feature/pgtk] frame-position returns incorrect information
2021-01-05 15:32 ` martin rudalics
@ 2021-01-05 16:00 ` Robert Pluim
0 siblings, 0 replies; 25+ messages in thread
From: Robert Pluim @ 2021-01-05 16:00 UTC (permalink / raw)
To: martin rudalics; +Cc: 44961, Yuuki Harano
martin rudalics <rudalics@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
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#44961: 28.0.50; [feature/pgtk] frame-position returns incorrect information
2020-11-30 14:33 bug#44961: 28.0.50; [feature/pgtk] frame-position returns incorrect information Robert Pluim
` (2 preceding siblings ...)
2021-01-01 8:41 ` Yuuki Harano
@ 2022-02-20 14:07 ` Lars Ingebrigtsen
2022-02-20 19:57 ` Stephen Berman
2022-02-21 1:22 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
3 siblings, 2 replies; 25+ messages in thread
From: Lars Ingebrigtsen @ 2022-02-20 14:07 UTC (permalink / raw)
To: Robert Pluim; +Cc: 44961
Robert Pluim <rpluim@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
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#44961: 28.0.50; [feature/pgtk] frame-position returns incorrect information
2022-02-20 14:07 ` Lars Ingebrigtsen
@ 2022-02-20 19:57 ` Stephen Berman
2022-02-21 11:17 ` Robert Pluim
2022-02-21 1:22 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 1 reply; 25+ messages in thread
From: Stephen Berman @ 2022-02-20 19:57 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 44961, Robert Pluim
On Sun, 20 Feb 2022 15:07:39 +0100 Lars Ingebrigtsen <larsi@gnus.org> wrote:
> Robert Pluim <rpluim@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
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#44961: 28.0.50; [feature/pgtk] frame-position returns incorrect information
2022-02-20 14:07 ` Lars Ingebrigtsen
2022-02-20 19:57 ` Stephen Berman
@ 2022-02-21 1:22 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 0 replies; 25+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-02-21 1:22 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 44961, Robert Pluim
Lars Ingebrigtsen <larsi@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.
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#44961: 28.0.50; [feature/pgtk] frame-position returns incorrect information
2022-02-20 19:57 ` Stephen Berman
@ 2022-02-21 11:17 ` Robert Pluim
2022-02-21 11:28 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 25+ messages in thread
From: Robert Pluim @ 2022-02-21 11:17 UTC (permalink / raw)
To: Stephen Berman; +Cc: Po Lu, 44961, Lars Ingebrigtsen
>>>>> On Sun, 20 Feb 2022 20:57:42 +0100, Stephen Berman <stephen.berman@gmx.net> said:
Stephen> On Sun, 20 Feb 2022 15:07:39 +0100 Lars Ingebrigtsen <larsi@gnus.org> wrote:
>> Robert Pluim <rpluim@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
--
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#44961: 28.0.50; [feature/pgtk] frame-position returns incorrect information
2022-02-21 11:17 ` Robert Pluim
@ 2022-02-21 11:28 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-02-21 11:46 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-02-21 11:49 ` Robert Pluim
0 siblings, 2 replies; 25+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-02-21 11:28 UTC (permalink / raw)
To: Robert Pluim; +Cc: 44961, Lars Ingebrigtsen, Stephen Berman
Robert Pluim <rpluim@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.
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#44961: 28.0.50; [feature/pgtk] frame-position returns incorrect information
2022-02-21 11:28 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-02-21 11:46 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-02-21 12:58 ` Robert Pluim
2022-02-21 11:49 ` Robert Pluim
1 sibling, 1 reply; 25+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-02-21 11:46 UTC (permalink / raw)
To: Robert Pluim; +Cc: 44961, Lars Ingebrigtsen, Stephen Berman
Po Lu <luangruo@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.
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#44961: 28.0.50; [feature/pgtk] frame-position returns incorrect information
2022-02-21 11:28 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-02-21 11:46 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-02-21 11:49 ` Robert Pluim
2022-02-21 11:55 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 1 reply; 25+ messages in thread
From: Robert Pluim @ 2022-02-21 11:49 UTC (permalink / raw)
To: Po Lu; +Cc: 44961, Lars Ingebrigtsen, Stephen Berman
>>>>> On Mon, 21 Feb 2022 19:28:27 +0800, Po Lu <luangruo@yahoo.com> said:
Po> Robert Pluim <rpluim@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
--
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#44961: 28.0.50; [feature/pgtk] frame-position returns incorrect information
2022-02-21 11:49 ` Robert Pluim
@ 2022-02-21 11:55 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 25+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-02-21 11:55 UTC (permalink / raw)
To: Robert Pluim; +Cc: 44961, Lars Ingebrigtsen, Stephen Berman
Robert Pluim <rpluim@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.
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#44961: 28.0.50; [feature/pgtk] frame-position returns incorrect information
2022-02-21 11:46 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-02-21 12:58 ` Robert Pluim
2022-02-21 13:26 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 25+ messages in thread
From: Robert Pluim @ 2022-02-21 12:58 UTC (permalink / raw)
To: Po Lu; +Cc: 44961, Lars Ingebrigtsen, Stephen Berman
>>>>> On Mon, 21 Feb 2022 19:46:27 +0800, Po Lu <luangruo@yahoo.com> said:
Po> Po Lu <luangruo@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
--
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#44961: 28.0.50; [feature/pgtk] frame-position returns incorrect information
2022-02-21 12:58 ` Robert Pluim
@ 2022-02-21 13:26 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-02-21 14:50 ` Robert Pluim
0 siblings, 1 reply; 25+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-02-21 13:26 UTC (permalink / raw)
To: Robert Pluim; +Cc: 44961, Lars Ingebrigtsen, Stephen Berman
Robert Pluim <rpluim@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.
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#44961: 28.0.50; [feature/pgtk] frame-position returns incorrect information
2022-02-21 13:26 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-02-21 14:50 ` Robert Pluim
0 siblings, 0 replies; 25+ messages in thread
From: Robert Pluim @ 2022-02-21 14:50 UTC (permalink / raw)
To: Po Lu; +Cc: Lars Ingebrigtsen, 44961-done, Stephen Berman
>>>>> On Mon, 21 Feb 2022 21:26:37 +0800, Po Lu <luangruo@yahoo.com> said:
Po> Robert Pluim <rpluim@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
--
^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2022-02-21 14:50 UTC | newest]
Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-30 14:33 bug#44961: 28.0.50; [feature/pgtk] frame-position returns incorrect information Robert Pluim
2020-12-01 9:15 ` Robert Pluim
2020-12-19 17:42 ` Yuuki Harano
2020-12-20 7:45 ` martin rudalics
2020-12-20 10:13 ` Yuuki Harano
2020-12-21 15:33 ` martin rudalics
2021-01-04 18:15 ` Robert Pluim
2021-01-05 13:24 ` Robert Pluim
2021-01-05 15:32 ` martin rudalics
2021-01-05 16:00 ` Robert Pluim
2021-01-01 8:41 ` Yuuki Harano
2021-01-01 10:19 ` martin rudalics
2021-01-03 9:04 ` Yuuki Harano
2021-01-03 9:23 ` martin rudalics
2022-02-20 14:07 ` Lars Ingebrigtsen
2022-02-20 19:57 ` Stephen Berman
2022-02-21 11:17 ` Robert Pluim
2022-02-21 11:28 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-02-21 11:46 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-02-21 12:58 ` Robert Pluim
2022-02-21 13:26 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-02-21 14:50 ` Robert Pluim
2022-02-21 11:49 ` Robert Pluim
2022-02-21 11:55 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-02-21 1:22 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).