bug#73207: 31.0.50; On PGTK frame outer-position and frame-monitor-workarea wrong.

bug#73207: 31.0.50; On PGTK frame outer-position and frame-monitor-workarea wrong.

[David Koppelman]

In a PGTK build of Emacs running on KDE Wayland (versions are below) the
position of a frame and the size of the workarea are wrong. These work
correctly in non-PGTK builds. For example, (frame-edges nil
'outer-edges) returns (0 0 752 840), even though the top-left of the
frame is not over pixel 0,0. In a call to (frame-monitor-attributes) the
geometry and workarea dimensions are the same. The workarea is correctly
reported as smaller in non-PGTK builds.

I'd prefer that these be fixed, but if not they ought to be documented
in etc/PROBLEMS.


In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.43, cairo version 1.18.0) of 2024-09-08 built on dmk-laptop-23
Repository revision: 4073c624376148d469a27a7c487a9b2f49d5352a
Repository branch: master
System Description: Fedora Linux 41 (KDE Plasma Prerelease)

Configured using:
 'configure 'CFLAGS=-O2 -march=native' --without-pop
 --with-native-compilation --with-pgtk'

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

Important settings:
  value of $LC_COLLATE: C
  value of $LC_MONETARY: en_US.UTF-8
  value of $LC_NUMERIC: en_US.UTF-8
  value of $LC_TIME: C
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=none
  locale-coding-system: utf-8-unix

Major mode: Info

Minor modes in effect:
  global-hi-lock-mode: t
  hi-lock-mode: t
  which-function-mode: t
  global-ligature-mode: t
  ligature-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  isearch-fold-quotes-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  minibuffer-regexp-mode: t
  buffer-read-only: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:

 The problem occurs with a -Q run, no need for my load path details.

Features:
(shadow sort gnus-msg gnus-art mm-uu mml2015 mm-view mml-smime smime
gnutls dig gnus-sum shr pixel-fill kinsoku url-file svg dom gnus-group
gnus-undo gnus-start gnus-dbus gnus-cloud nnimap nnmail mail-source utf7
nnoo gnus-spec gnus-int gnus-range gnus-win gnus nnheader range wid-edit
emacsbug tabify color tex-mode latexenc verilog-mode-4702 skeleton
reporter verilog-mode log-view pcvs-util bug-reference pcase
emacs-news-mode noutline outline debug backtrace find-func shortdoc gud
conf-mode wdired smerge-mode diff vc vc-git diff-mode track-changes
vc-dispatcher cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles
cc-align cc-engine cc-vars cc-defs parse-time iso8601 mule-util info
apropos cl-print help-fns radix-tree pcmpl-unix misearch multi-isearch
cperl-mode facemenu mail-extr project add-log compile comp-run
comp-common view p-math.el sh-script smie treesit executable files-x
p-viewer-laptop browse-url url url-proxy url-privacy url-expand
url-methods url-history url-cookie generate-lisp-file url-domsuf
url-util p-iimage simtools p-tex-funcs shell pcomplete comint ansi-osc
ring man ansi-color hi-lock rmail p-stop-time time-stamp dired-aux
p-page dabbrev ps-print ps-print-loaddefs lpr holidays holiday-loaddefs
appt p-diary-aux cal-x p-diary-audit diary-lib diary-loaddefs cal-menu
calendar cal-loaddefs mic-paren message sendmail mailcap yank-media puny
dired dired-loaddefs rfc822 mml mml-sec epa epg rfc6068 epg-config
gnus-util text-property-search time-date mm-decode mm-bodies mm-encode
mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr
mailabbrev mail-utils gmm-utils mailheader ffap url-parse auth-source
eieio eieio-core icons password-cache json map byte-opt bytecomp
byte-compile url-vars ccl-mode ampl-mode texize chemora-mode cmake-mode
thingatpt which-func imenu flyspell ispell gnuplot-mode yaml-mode
p-pwf-mode p-autoreload cl-extra help-mode rx cl-seq ligature easy-mmode
advice derived sd image-file image-converter dbus xml subr-x cl-macs gv
cl-loaddefs cl-lib rmc iso-transl tooltip cconv eldoc paren electric
uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/pgtk-win pgtk-win term/common-win touch-screen pgtk-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow
isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify
dynamic-setting system-font-setting font-render-setting cairo gtk pgtk
lcms2 multi-tty move-toolbar make-network-process native-compile emacs)

Memory information:
((conses 16 596625 74664) (symbols 48 25644 0)
 (strings 32 109707 10232) (string-bytes 1 3677640) (vectors 16 55193)
 (vector-slots 8 1481273 104469) (floats 8 889 749)
 (intervals 56 39508 2174) (buffers 992 65))

bug#73207: 31.0.50; On PGTK frame outer-position and frame-monitor-workarea wrong.

[Eli Zaretskii]

> From: David Koppelman <koppel@ece.lsu.edu>
> Date: Thu, 12 Sep 2024 13:24:04 -0500
> 
> In a PGTK build of Emacs running on KDE Wayland (versions are below) the
> position of a frame and the size of the workarea are wrong. These work
> correctly in non-PGTK builds. For example, (frame-edges nil
> 'outer-edges) returns (0 0 752 840), even though the top-left of the
> frame is not over pixel 0,0. In a call to (frame-monitor-attributes) the
> geometry and workarea dimensions are the same. The workarea is correctly
> reported as smaller in non-PGTK builds.
> 
> I'd prefer that these be fixed, but if not they ought to be documented
> in etc/PROBLEMS.

Po Lu, any comments?

ISTR that we already know about this issue, but for some reason I
cannot find it in PROBLEMS or anywhere else.  What did I miss?

bug#73207: 31.0.50; On PGTK frame outer-position and frame-monitor-workarea wrong.

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Koppelman <koppel@ece.lsu.edu>
>> Date: Thu, 12 Sep 2024 13:24:04 -0500
>> 
>> In a PGTK build of Emacs running on KDE Wayland (versions are below) the
>> position of a frame and the size of the workarea are wrong. These work
>> correctly in non-PGTK builds. For example, (frame-edges nil
>> 'outer-edges) returns (0 0 752 840), even though the top-left of the
>> frame is not over pixel 0,0. In a call to (frame-monitor-attributes) the
>> geometry and workarea dimensions are the same. The workarea is correctly
>> reported as smaller in non-PGTK builds.
>> 
>> I'd prefer that these be fixed, but if not they ought to be documented
>> in etc/PROBLEMS.
>
> Po Lu, any comments?
>
> ISTR that we already know about this issue, but for some reason I
> cannot find it in PROBLEMS or anywhere else.  What did I miss?

It's impossible to extract these values on Wayland because the protocol
is engineered to withhold them from programs.  There are entries for
similar protocol limitations in etc/PROBLEMS (e.g. warping or locating
the mouse pointer), but not the unavailability of frame geometry or
workspace dimensions.

bug#73207: 31.0.50; On PGTK frame outer-position and frame-monitor-workarea wrong.

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: David Koppelman <koppel@ece.lsu.edu>,  73207@debbugs.gnu.org
> Date: Sat, 14 Sep 2024 20:08:41 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: David Koppelman <koppel@ece.lsu.edu>
> >> Date: Thu, 12 Sep 2024 13:24:04 -0500
> >> 
> >> In a PGTK build of Emacs running on KDE Wayland (versions are below) the
> >> position of a frame and the size of the workarea are wrong. These work
> >> correctly in non-PGTK builds. For example, (frame-edges nil
> >> 'outer-edges) returns (0 0 752 840), even though the top-left of the
> >> frame is not over pixel 0,0. In a call to (frame-monitor-attributes) the
> >> geometry and workarea dimensions are the same. The workarea is correctly
> >> reported as smaller in non-PGTK builds.
> >> 
> >> I'd prefer that these be fixed, but if not they ought to be documented
> >> in etc/PROBLEMS.
> >
> > Po Lu, any comments?
> >
> > ISTR that we already know about this issue, but for some reason I
> > cannot find it in PROBLEMS or anywhere else.  What did I miss?
> 
> It's impossible to extract these values on Wayland because the protocol
> is engineered to withhold them from programs.  There are entries for
> similar protocol limitations in etc/PROBLEMS (e.g. warping or locating
> the mouse pointer), but not the unavailability of frame geometry or
> workspace dimensions.

Can you please add this to PROBLEMS on the release branch?