emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#64630: closed (30.0.50; unable to change to raise or lower a child-f


From: GNU bug Tracking System
Subject: bug#64630: closed (30.0.50; unable to change to raise or lower a child-frame)
Date: Sat, 02 Sep 2023 22:26:01 +0000

Your message dated Sat, 2 Sep 2023 15:25:09 -0700
with message-id 
<CADwFkmn2jaZR4Yb3Far_xi5AE5Xi1A8jVC0_KiimNEiYuAUZNg@mail.gmail.com>
and subject line Re: bug#64630: 30.0.50; unable to change to raise or lower a 
child-frame
has caused the debbugs.gnu.org bug report #64630,
regarding 30.0.50; unable to change to raise or lower a child-frame
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
64630: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=64630
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: 30.0.50; unable to change to raise or lower a child-frame Date: Fri, 14 Jul 2023 23:04:22 +0300 User-agent: mu4e 1.8.11; emacs 30.0.50
Hello.

I'm working on an alternative windowing system for Emacs that explores
child frames as a base for windowing, instead of using splits.  I've
noticed that no matter what I do, I can't restack child-frames.  Calling
`frame-raise' or changing the `z-group' has no effect on the frames
spawned by my window manager.

The simplest possible way to test this in Emacs -Q is to eval this code
twice:

(let ((frame
       (make-frame
        `((width . 20) (height . 8)
          (parent-frame . ,(selected-frame))
          (drag-with-header-line . t)
          (undecorated . t)
          (minibuffer . nil)))))
  (set-window-parameter
   (frame-root-window frame)
   'header-line-format
   " %b"))

It will create two small child frames, and no matter what I do the order
of frames is not changes.  A friend of mine reported that it works under
X on Emacs 28 as expected.  I suspect that it may be related to the fact
that I'm using Wayland version of GNOME Shell and a PGTK build. I will
try to recompile Emacs later and post the results here.

The window manager can be obtained here[1] if you want to experiment with
it but the snipped above should be sufficient.


In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.38, cairo version 1.17.8) of 2023-07-07 built on toolbox
Repository revision: 37101780243d083e8773c255242aa26614f22a14
Repository branch: master
System Description: Fedora Linux 38 (Container Image)

Configured using:
 'configure --without-compress-install --with-native-compilation=aot
 --with-pgtk --with-mailutils --with-xwidgets
 --prefix=/var/home/alist/.local'

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

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Infinite

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  buffer-read-only: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa epg rfc6068
epg-config gnus-util text-property-search mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils time-date infinite
derived pcase vc-git diff-mode easy-mmode vc-dispatcher cl-loaddefs comp
comp-cstr warnings icons subr-x rx cl-seq cl-macs gv cl-extra help-mode
bytecomp byte-compile 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 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 xwidget-internal 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 89926 11925) (symbols 48 7843 0) (strings 32 21861 1792)
 (string-bytes 1 674782) (vectors 16 17291)
 (vector-slots 8 356861 18308) (floats 8 33 44) (intervals 56 347 0)
 (buffers 984 13))

[1] 
https://gitlab.com/andreyorst/infinite.el/-/blob/d8740f5657a880620456f8fabd16fe3d8a5918b8/infinite.el



--- End Message ---
--- Begin Message --- Subject: Re: bug#64630: 30.0.50; unable to change to raise or lower a child-frame Date: Sat, 2 Sep 2023 15:25:09 -0700
Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: 64630@debbugs.gnu.org
>> Date: Sat, 15 Jul 2023 09:16:28 +0800
>> From:  Po Lu via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>>
>> This is a known limitation of PGTK builds that is a consequence of how
>> newer versions of GDK implement its ``client-side windows''.  It was
>> discussed in depth last year, within another bug report, and the
>> consensus was that it wouldn't be fixed any time soon.
>
> Thanks, please close this bug if it's clear that we cannot fix the
> issue on our side.

It seems like this is not something we can fix in Emacs, so I'm closing
this bug report now.

If this conclusion is incorrect, please reopen the bug report.


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]