GNU bug report logs -
#31968
26.1.50; Allow to hide title bar on maximize (gtk/gnome/csd)
Previous Next
Reported by: Carlos Pita <carlosjosepita <at> gmail.com>
Date: Mon, 25 Jun 2018 20:45:02 UTC
Severity: wishlist
Found in version 26.1.50
Fixed in version 29.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 31968 in the body.
You can then email your comments to 31968 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31968; Package
emacs.
(Mon, 25 Jun 2018 20:45:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Carlos Pita <carlosjosepita <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Mon, 25 Jun 2018 20:45:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
In gnome decorations are considered part of the client (even classic
titlebars) in the sense that it's the client who decides to show them or
not (see [1] and [2]). In waylan there is no other way around, but they
also decided to pretend X apps behave like that. This is very frustrating
since the reality is that many clients don't work in that way yet.
So this is a request to add a gtk-hide-titlebar-if-maximized or similar
variable since I assume emacs won't be using proper CSDs for a long
time, maybe for good. Without that variable it's not possible to achieve
the same humble goal in the strange new world of gnome, at least not without
lots of xprop, xwinifo, xdotool, wmctrl, etc. horrible hacks. As I said,
it's supposed to be the client who knows what to show and when to show
it.
---
[1] https://blogs.gnome.org/tbernard/2018/01/26/csd-initiative/
[2] https://bugzilla.gnome.org/show_bug.cgi?id=775061
In GNU Emacs 26.1.50 (build 3, x86_64-pc-linux-gnu, GTK+ Version 3.22.30)
of 2018-06-18 built on carlos
Repository revision: 0a8b7f365cbc8de02ddb4e806dd76b1bf6302565
Windowing system distributor 'The X.Org Foundation', version 11.0.11906000
System Description: Manjaro Linux
Recent messages:
Loading ido-completing-read+...done
Loading paren...done
Loading winner...done
Loading xclip...done
Loading a theme can run Lisp code. Really load? (y or n) y
Treat this theme as safe in future sessions? (y or n) y
[yas] Prepared just-in-time loading of snippets successfully.
Saving file /home/carlos/.emacs.d/init.el...
Wrote /home/carlos/.emacs.d/init.el [2 times]
For information about GNU Emacs and the GNU system, type C-h C-a.
Configured using:
'configure --prefix=/home/carlos/Local/stow/emacs-26
--libexecdir=/home/carlos/Local/stow/emacs-26/lib --with-x-toolkit=gtk3
--with-xft --with-modules'
Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND GPM DBUS GSETTINGS NOTIFY ACL GNUTLS
LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11
MODULES THREADS LIBSYSTEMD LCMS2
Important settings:
value of $LC_MONETARY: en_US.UTF-8
value of $LC_NUMERIC: en_US.UTF-8
value of $LC_TIME: en_US.UTF-8
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Major mode: Lisp Interaction
Minor modes in effect:
display-line-numbers-mode: t
flymake-mode: t
pyvenv-mode: t
shell-dirtrack-mode: t
diff-auto-refine-mode: t
xclip-mode: t
winner-mode: t
show-paren-mode: t
ido-ubiquitous-mode: t
ido-everywhere: t
global-company-mode: t
company-mode: t
display-battery-mode: t
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
column-number-mode: t
line-number-mode: t
transient-mark-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
display-line-numbers checkdoc pp cl-extra yasnippet
highlight-indentation flymake-proc flymake warnings help-fns radix-tree
help-mode elpy find-file-in-project ivy delsel ivy-overlay ffap
thingatpt elpy-shell pyvenv esh-var esh-io esh-cmd esh-opt esh-ext
esh-proc esh-arg esh-groups eshell esh-module esh-mode esh-util
elpy-profile elpy-django elpy-refactor subr-x python tramp-sh tramp
tramp-compat tramp-loaddefs trampver ucs-normalize shell pcomplete
parse-time format-spec advice json map grep compile comint ansi-color
files-x doom-themes-org windmove vc-git diff-mode easy-mmode
company-oddmuse company-keywords company-etags etags xref project
company-gtags company-dabbrev-code company-dabbrev company-files
company-capf company-cmake company-xcode company-clang company-semantic
company-eclim company-template company-css company-nxml company-bbdb
doom-tomorrow-night-theme doom-themes doom-themes-common elec-pair xclip
winner ring paren ido-completing-read+ memoize s cus-edit minibuf-eldef
ido gnus nnheader gnus-util rmail rmail-loaddefs rfc2047 rfc2045
ietf-drums mail-utils mm-util mail-prsvr wid-edit company edmacro kmacro
pcase battery cus-start cus-load finder-inf info package easymenu
epg-config url-handlers url-parse auth-source cl-seq eieio eieio-core
cl-macs eieio-loaddefs password-cache url-vars seq byte-opt gv bytecomp
byte-compile cconv cl-loaddefs cl-lib server time-date mule-util tooltip
eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel
term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode
lisp-mode prog-mode register page menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic 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 charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote dbusbind inotify lcms2 dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty
make-network-process emacs)
Memory information:
((conses 16 446497 14130)
(symbols 48 36746 2)
(miscs 40 74 141)
(strings 32 98962 3555)
(string-bytes 1 2638751)
(vectors 16 55867)
(vector-slots 8 983572 13084)
(floats 8 276 155)
(intervals 56 304 0)
(buffers 992 14))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31968; Package
emacs.
(Wed, 27 Jun 2018 10:09:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 31968 <at> debbugs.gnu.org (full text, mbox):
Carlos Pita <carlosjosepita <at> gmail.com> writes:
> In gnome decorations are considered part of the client (even classic
> titlebars) in the sense that it's the client who decides to show them or
> not (see [1] and [2]). In waylan there is no other way around, but they
> also decided to pretend X apps behave like that. This is very frustrating
> since the reality is that many clients don't work in that way yet.
>
> So this is a request to add a gtk-hide-titlebar-if-maximized or similar
> variable since I assume emacs won't be using proper CSDs for a long
> time, maybe for good. Without that variable it's not possible to achieve
> the same humble goal in the strange new world of gnome, at least not without
> lots of xprop, xwinifo, xdotool, wmctrl, etc. horrible hacks. As I said,
> it's supposed to be the client who knows what to show and when to show
> it.
Could you explain in a bit more detail what GTK call(s) would need to
change in order to implement such a variable? That would allow us to
evaluate the effort (although personally Iʼd rather spend effort
towards implementing GTK as a native frame type).
Regards
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31968; Package
emacs.
(Wed, 27 Jun 2018 13:03:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 31968 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
One simple possibility is to set/unset
the _GTK_HIDE_TITLEBAR_WHEN_MAXIMIZED property. I think there is also a
corresponding gtk api for that but maybe the property could be set using
standard X machinery already exposed to elisp(?). Probably all this would
be ineffective under waylan but it's simply enough to fix the problem for X
with low effort.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31968; Package
emacs.
(Wed, 27 Jun 2018 13:26:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 31968 <at> debbugs.gnu.org (full text, mbox):
Carlos Pita <carlosjosepita <at> gmail.com> writes:
> One simple possibility is to set/unset
> the _GTK_HIDE_TITLEBAR_WHEN_MAXIMIZED property. I think there is also a
> corresponding gtk api for that but maybe the property could be set using
> standard X machinery already exposed to elisp(?). Probably all this would
> be ineffective under waylan but it's simply enough to fix the problem for X
> with low effort.
This is not quite what you asked for, but have you tried:
(modify-frame-parameters nil '((undecorated t)))
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31968; Package
emacs.
(Wed, 27 Jun 2018 15:21:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 31968 <at> debbugs.gnu.org (full text, mbox):
Yes, but the point is to hook something like that on
maximized/unmaximized events, which I don't see how to do.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31968; Package
emacs.
(Thu, 28 Jun 2018 04:23:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 31968 <at> debbugs.gnu.org (full text, mbox):
On Wed, Jun 27, 2018 at 10:21 AM Carlos Pita <carlosjosepita <at> gmail.com> wrote:
>
> Yes, but the point is to hook something like that on
> maximized/unmaximized events, which I don't see how to do.
Since maximizing a frame changes the window size, couldn't you hook
into window-size-change-functions to achieve the desired effect?
Something like this perhaps:
(defun hide-titlebar-when-maximized (frame)
(if (eq 'maximized (alist-get 'fullscreen (frame-parameters frame)))
(set-frame-parameter frame 'undecorated t)
(set-frame-parameter frame 'undecorated nil)))
(add-hook 'window-size-change-functions 'hide-titlebar-when-maximized)
--
Jonathan Kyle Mitchell
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31968; Package
emacs.
(Thu, 28 Jun 2018 08:03:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 31968 <at> debbugs.gnu.org (full text, mbox):
>> Yes, but the point is to hook something like that on
>> maximized/unmaximized events, which I don't see how to do.
>
> Since maximizing a frame changes the window size, couldn't you hook
> into window-size-change-functions to achieve the desired effect?
> Something like this perhaps:
>
> (defun hide-titlebar-when-maximized (frame)
> (if (eq 'maximized (alist-get 'fullscreen (frame-parameters frame)))
> (set-frame-parameter frame 'undecorated t)
> (set-frame-parameter frame 'undecorated nil)))
>
> (add-hook 'window-size-change-functions 'hide-titlebar-when-maximized)
Wouldn't that show the title bar when making the frame fullscreen via
F11?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31968; Package
emacs.
(Thu, 28 Jun 2018 08:03:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 31968 <at> debbugs.gnu.org (full text, mbox):
> One simple possibility is to set/unset
> the _GTK_HIDE_TITLEBAR_WHEN_MAXIMIZED property. I think there is also a
> corresponding gtk api for that but maybe the property could be set using
> standard X machinery already exposed to elisp(?). Probably all this would
> be ineffective under waylan but it's simply enough to fix the problem for X
> with low effort.
Could someone try to add a 'xg_set_hide_titlebar_when_maximized'
function to gtkutil.c. That would be just like 'xg_set_undecorated'
but call 'gtk_window_set_hide_titlebar_when_maximized' instead of
'gtk_window_set_decorated'. The Lisp interface for the moment could
be a simple 'x-set-hide-titlebar-when-maximized' function with a FRAME
and HIDE argument defined in xfns.c for GTK only that calls
'xg_set_hide_titlebar_when_maximized' with a frame structure
corresponding to the frame argument.
'gdk_x11_window_set_hide_title_bar_when_maximized' in gdkwindow-x11.c
has the XChangeProperty calls to make this work for non-GTK builds.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31968; Package
emacs.
(Thu, 28 Jun 2018 12:24:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 31968 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>>> Yes, but the point is to hook something like that on
>>> maximized/unmaximized events, which I don't see how to do.
>>
>> Since maximizing a frame changes the window size, couldn't you hook
>> into window-size-change-functions to achieve the desired effect?
>> Something like this perhaps:
>>
>> (defun hide-titlebar-when-maximized (frame)
>> (if (eq 'maximized (alist-get 'fullscreen (frame-parameters frame)))
>> (set-frame-parameter frame 'undecorated t)
>> (set-frame-parameter frame 'undecorated nil)))
>>
>> (add-hook 'window-size-change-functions 'hide-titlebar-when-maximized)
>
> Wouldn't that show the title bar when making the frame fullscreen via
> F11?
It doesnʼt for me. Note you can use 'move-frame-functions' instead of
window-size-change-functions if you prefer.
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31968; Package
emacs.
(Thu, 28 Jun 2018 15:27:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 31968 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> One simple possibility is to set/unset
>> the _GTK_HIDE_TITLEBAR_WHEN_MAXIMIZED property. I think there is also a
>> corresponding gtk api for that but maybe the property could be set using
>> standard X machinery already exposed to elisp(?). Probably all this would
>> be ineffective under waylan but it's simply enough to fix the problem for X
>> with low effort.
>
> Could someone try to add a 'xg_set_hide_titlebar_when_maximized'
> function to gtkutil.c. That would be just like 'xg_set_undecorated'
> but call 'gtk_window_set_hide_titlebar_when_maximized' instead of
> 'gtk_window_set_decorated'. The Lisp interface for the moment could
> be a simple 'x-set-hide-titlebar-when-maximized' function with a FRAME
> and HIDE argument defined in xfns.c for GTK only that calls
> 'xg_set_hide_titlebar_when_maximized' with a frame structure
> corresponding to the frame argument.
>
Patch attached. It sets the correct property on my emacs frame for me,
but it appears KWin ignores that, so I see no effect. No doubt needs a
few more USE_GTK ifdef checks.
> 'gdk_x11_window_set_hide_title_bar_when_maximized' in gdkwindow-x11.c
> has the XChangeProperty calls to make this work for non-GTK builds.
Youʼre suggesting we copy their code? Iʼm not sure what the value of
setting a GTK property is in a non-GTK build.
Robert
diff --git i/src/gtkutil.c w/src/gtkutil.c
index 69325ff00a..6cd502f430 100644
--- i/src/gtkutil.c
+++ w/src/gtkutil.c
@@ -1538,6 +1538,21 @@ xg_set_undecorated (struct frame *f, Lisp_Object undecorated)
}
}
+/* Set a property on the frame that requests the window manager to
+ hide the titlebar when it is maximized. Does not seem to work with
+ KWin. */
+void
+xg_set_hide_titlebar_when_maximized (struct frame *f, Lisp_Object hide)
+{
+ if (FRAME_GTK_WIDGET (f))
+ {
+ block_input ();
+ gtk_window_set_hide_titlebar_when_maximized
+ (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
+ NILP (hide) ? FALSE : TRUE);
+ unblock_input ();
+ }
+}
/* Restack F1 below F2, above if ABOVE_FLAG is true. This might not
work with all window managers. */
diff --git i/src/gtkutil.h w/src/gtkutil.h
index 7dcd549f5c..942238cff5 100644
--- i/src/gtkutil.h
+++ w/src/gtkutil.h
@@ -173,6 +173,7 @@ extern void xg_set_frame_icon (struct frame *f,
Pixmap icon_mask);
extern void xg_set_undecorated (struct frame *f, Lisp_Object undecorated);
+extern void xg_set_hide_titlebar_when_maximized (struct frame *f, Lisp_Object hide);
extern void xg_frame_restack (struct frame *f1, struct frame *f2, bool above);
extern void xg_set_skip_taskbar (struct frame *f, Lisp_Object skip_taskbar);
extern void xg_set_no_focus_on_map (struct frame *f, Lisp_Object no_focus_on_map);
diff --git i/src/xfns.c w/src/xfns.c
index fe8170cf63..fccf8f471a 100644
--- i/src/xfns.c
+++ w/src/xfns.c
@@ -7600,6 +7600,28 @@ visible. */)
#endif /* USE_GTK */
#endif /* USE_CAIRO */
+DEFUN ("x-set-hide-titlebar-when-maximized", Fx_set_hide_titlebar_when_maximized,
+ Sx_set_hide_titlebar_when_maximized,
+ 2, 2, 0,
+ doc:
+ /* Set titlebar hiding behavior when FRAME becomes maximized.
+If FRAME is nil it defaults to the currently selected frame. If HIDE
+is non-nil, FRAME's window-system window is requested to be drawn
+without a titlebar when it becomes maximized. If HIDE is nil,
+drawing with a titlebar is requested.
+
+Only works in build using GTK
+Some window managers may not honor this parameter.*/)
+ (Lisp_Object frame, Lisp_Object hide)
+{
+#ifdef USE_GTK
+ struct frame *f = decode_window_system_frame (frame);
+
+ xg_set_hide_titlebar_when_maximized (f, hide);
+#endif
+ return Qnil;
+}
+
/***********************************************************************
Initialization
@@ -7958,4 +7980,5 @@ When using Gtk+ tooltips, the tooltip face is not used. */);
defsubr (&Sx_print_frames_dialog);
#endif
#endif
+ defsubr(&Sx_set_hide_titlebar_when_maximized);
}
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31968; Package
emacs.
(Fri, 29 Jun 2018 08:43:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 31968 <at> debbugs.gnu.org (full text, mbox):
> Patch attached. It sets the correct property on my emacs frame for me,
> but it appears KWin ignores that, so I see no effect. No doubt needs a
> few more USE_GTK ifdef checks.
Carlos, can you test the patch? If it works, we can brush it up a
little to make it a frame parameter just like 'undecorated'.
>> 'gdk_x11_window_set_hide_title_bar_when_maximized' in gdkwindow-x11.c
>> has the XChangeProperty calls to make this work for non-GTK builds.
>
> Youʼre suggesting we copy their code? Iʼm not sure what the value of
> setting a GTK property is in a non-GTK build.
FWIW I did that for x_set_undecorated when implementing that awful
PROP_MOTIF_WM_HINTS_ELEMENTS hack.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31968; Package
emacs.
(Fri, 29 Jun 2018 08:49:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 31968 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> Patch attached. It sets the correct property on my emacs frame for me,
>> but it appears KWin ignores that, so I see no effect. No doubt needs a
>> few more USE_GTK ifdef checks.
>
> Carlos, can you test the patch? If it works, we can brush it up a
> little to make it a frame parameter just like 'undecorated'.
That would be a somewhat bigger patch. Iʼm assuming weʼd need to
adjust nsgui and w32gui frame parameter definitions as well.
>>> 'gdk_x11_window_set_hide_title_bar_when_maximized' in gdkwindow-x11.c
>>> has the XChangeProperty calls to make this work for non-GTK builds.
>>
>> Youʼre suggesting we copy their code? Iʼm not sure what the value of
>> setting a GTK property is in a non-GTK build.
>
> FWIW I did that for x_set_undecorated when implementing that awful
> PROP_MOTIF_WM_HINTS_ELEMENTS hack.
I donʼt know what that is, and I donʼt think I want to know.
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31968; Package
emacs.
(Sat, 30 Jun 2018 08:35:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 31968 <at> debbugs.gnu.org (full text, mbox):
> That would be a somewhat bigger patch. Iʼm assuming weʼd need to
> adjust nsgui and w32gui frame parameter definitions as well.
For non-GTK builds we'd have to proceed as follows:
(1) When we do the maximization ourselves, remove the decorations
first and then maximize.
(2) When we get a maximize event, remove the decorations.
(3) For any event or action that removes the maximized state, re-add
the decorations provided the frame should not stay undecorated via
a frame parameter.
So this would require some quite substantial coding effort and should
definitely wait until someone confirms that your GTK patch works.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31968; Package
emacs.
(Sat, 30 Jun 2018 22:33:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 31968 <at> debbugs.gnu.org (full text, mbox):
On Sat, Jun 30, 2018 at 3:38 AM martin rudalics <rudalics <at> gmx.at> wrote:
>
> > That would be a somewhat bigger patch. Iʼm assuming weʼd need to
> > adjust nsgui and w32gui frame parameter definitions as well.
>
> For non-GTK builds we'd have to proceed as follows:
>
> (1) When we do the maximization ourselves, remove the decorations
> first and then maximize.
>
> (2) When we get a maximize event, remove the decorations.
>
> (3) For any event or action that removes the maximized state, re-add
> the decorations provided the frame should not stay undecorated via
> a frame parameter.
>
> So this would require some quite substantial coding effort and should
> definitely wait until someone confirms that your GTK patch works.
>
> martin
I had the opportunity to test Robert's C patch on a recent copy of the
master branch today in a Fedora 28 VM using Gnome3, Xfce4, and KDE5.
Setting the hide argument to `t' in the new Lisp function
`x-set-hide-titlebar-when-maximized' worked as expected in Gnome and
Xfce--the titlebar disappeared when I maximized the Emacs frame. The
KDE titlebar remained in place except when putting Emacs in fullscreen
mode.
--
Jonathan Kyle Mitchell
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31968; Package
emacs.
(Sat, 30 Jun 2018 22:55:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 31968 <at> debbugs.gnu.org (full text, mbox):
Works for me too. I had to manually apply the patch because it doesn't
cleanly applies on latest emacs-26, but besides that it does what is
announced.
I think it's ok for this functionality to be gtk only since the kde
people (and mostly everyone else) hate the csd stuff and want their wm
to deal with decorations, old school. There is a flame war around this
issue indeed. Plasma can be configured for "hide titlebar on maximize"
but gnome and its derivatives (thinking of cinnamon here) can't. I
wonder for how long it would be even possible to hide the titlebar at
the gtk level.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31968; Package
emacs.
(Sat, 30 Jun 2018 23:27:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 31968 <at> debbugs.gnu.org (full text, mbox):
Sorry if this is a silly question but what would be the right hook to
call this function? The frame should already exist but not yet be
mapped or made visible.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31968; Package
emacs.
(Sun, 01 Jul 2018 00:14:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 31968 <at> debbugs.gnu.org (full text, mbox):
Bad news: this doesn't work under Cinnamon, only Gnome. I somehow
assumed it was gtk itself hidding the decoration, but it seems it's
not working like that.
Nevertheless I'm more fond of a pure elisp approach like the one
suggested by Johnathan (hooking from window-size-change-functions). Is
there anything wrong with that?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31968; Package
emacs.
(Sun, 01 Jul 2018 09:03:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 31968 <at> debbugs.gnu.org (full text, mbox):
> I had the opportunity to test Robert's C patch on a recent copy of the
> master branch today in a Fedora 28 VM using Gnome3, Xfce4, and KDE5.
> Setting the hide argument to `t' in the new Lisp function
> `x-set-hide-titlebar-when-maximized' worked as expected in Gnome and
> Xfce--the titlebar disappeared when I maximized the Emacs frame.
Thank you very much for testing. Can you check whether it works when
maximizing an undecorated frame? That is, make a new frame, in it do
(set-frame-parameter nil 'undecorated t)
then maximize it and demaximize it. Is it still undecorated?
> The
> KDE titlebar remained in place except when putting Emacs in fullscreen
> mode.
Somehow KDE is a notorious refusnik as far as Emacs frames are
concerned. While you're there: Can you confirm the strange resizing
behaviors of Bug#31968? For example, does evaluating
(modify-frame-parameters nil '((left . 0) (top . 0) (width . 130) (height . 56)))
result in a 130x56 frame?
Thanks again, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31968; Package
emacs.
(Sun, 01 Jul 2018 09:04:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 31968 <at> debbugs.gnu.org (full text, mbox):
> Works for me too. I had to manually apply the patch because it doesn't
> cleanly applies on latest emacs-26, but besides that it does what is
> announced.
Thank you. Which are your desktop and window manager?
> I think it's ok for this functionality to be gtk only since the kde
> people (and mostly everyone else) hate the csd stuff and want their wm
> to deal with decorations, old school. There is a flame war around this
> issue indeed. Plasma can be configured for "hide titlebar on maximize"
Does this apply to all windows even when their application has not
requested such behavior?
> but gnome and its derivatives (thinking of cinnamon here) can't. I
> wonder for how long it would be even possible to hide the titlebar at
> the gtk level.
IIUC it has been added in 3.4 so it will probably stay there for a
while.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31968; Package
emacs.
(Sun, 01 Jul 2018 09:05:01 GMT)
Full text and
rfc822 format available.
Message #62 received at 31968 <at> debbugs.gnu.org (full text, mbox):
> Bad news: this doesn't work under Cinnamon, only Gnome. I somehow
> assumed it was gtk itself hidding the decoration, but it seems it's
> not working like that.
GTK just manages the settings we request and passes them on to the
window manager.
> Nevertheless I'm more fond of a pure elisp approach like the one
> suggested by Johnathan (hooking from window-size-change-functions). Is
> there anything wrong with that?
Couldn't you try it? Just check the 'fullscreen' and 'undecorated'
frame parameters there and if they don't match (that is maximized and
decorated or not-maximized and undecorated) set the 'undecorated'
parameter appropriately. Later on we have to make sure that a per se
undecorated frame does not get decorations when it's demaximized.
I'm afraid you will see some flickering though.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31968; Package
emacs.
(Sun, 01 Jul 2018 17:24:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 31968 <at> debbugs.gnu.org (full text, mbox):
Under Cinnamon it worked without flickering. There is just a minor
problem that could be pointing to a bug elsewhere in emacs. Cinnamon
implements a progression of tiles layouts, for instance starting from
a normal sized window (i) you press Super-Up and the window is tiled
to the top half of the screen, (ii) you then press Super-Up again and
the window is maximized, (iii) finally you press Super-Down and the
window returns to top half tile mode. In general only fully maximized
windows (ii) gets undecorated, as intended, but when transitioning
from fully maximized to top half tiled (ii->iii) emacs still sees the
maximized state in the fullscreen frame parameter and fails to
undecorate the window. Nevertheless the client state in (ii) is:
~:: xprop | grep _NET_WM_STATE
_NET_WM_STATE(ATOM) = _NET_WM_STATE_MAXIMIZED_VERT, _NET_WM_STATE_TILED
The problem seems to be in the reported frame parameters, not in
Jonathan's hook.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31968; Package
emacs.
(Sun, 01 Jul 2018 17:37:01 GMT)
Full text and
rfc822 format available.
Message #68 received at 31968 <at> debbugs.gnu.org (full text, mbox):
It could be a matter of timing since sometimes (ii->iii) indeed
restores the decorations, but most of the time it doesn't.
Also I realized that the above is more simple and reliable to
reproduce by just pressing Alt-F10 twice (toggle maximized on/off),
when restoring the normal window size it doesn't get its decorations
again. I would say that this also is a timing issue, because xprop
correctly shows that the x11 window is not maximized but emacs thinks
otherwise, probably because an emacs window was resized before the x11
window properties were set by the wm.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31968; Package
emacs.
(Sun, 01 Jul 2018 17:47:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 31968 <at> debbugs.gnu.org (full text, mbox):
Same under Gnome, both Super-Up/Down tiling and Alt-10 maximize
toggling: decorations aren't restored, at least until some further
action inside the frame triggers the hook again. A more reliable hook
should be used if available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31968; Package
emacs.
(Sun, 01 Jul 2018 18:10:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 31968 <at> debbugs.gnu.org (full text, mbox):
Moving to a more manual approach I find a new problem: at least under
gnome undecorating the frame makes it lose its focus.
(global-set-key (kbd "C-x t")
(lambda () (interactive)
(set-frame-parameter nil 'undecorated
(not (frame-parameter nil 'undecorated)))))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31968; Package
emacs.
(Mon, 02 Jul 2018 05:09:01 GMT)
Full text and
rfc822 format available.
Message #77 received at 31968 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> I had the opportunity to test Robert's C patch on a recent copy of the
>> master branch today in a Fedora 28 VM using Gnome3, Xfce4, and KDE5.
>> Setting the hide argument to `t' in the new Lisp function
>> `x-set-hide-titlebar-when-maximized' worked as expected in Gnome and
>> Xfce--the titlebar disappeared when I maximized the Emacs frame.
>
> Thank you very much for testing. Can you check whether it works when
> maximizing an undecorated frame? That is, make a new frame, in it do
>
> (set-frame-parameter nil 'undecorated t)
>
> then maximize it and demaximize it. Is it still undecorated?
Yes, the frame remains undecorated after both maximizing and
demaximizing it.
>> The
>> KDE titlebar remained in place except when putting Emacs in fullscreen
>> mode.
>
> Somehow KDE is a notorious refusnik as far as Emacs frames are
> concerned. While you're there: Can you confirm the strange resizing
> behaviors of Bug#31968? For example, does evaluating
>
> (modify-frame-parameters nil '((left . 0) (top . 0) (width . 130)
> (height . 56)))
>
> result in a 130x56 frame?
Yes, I get a frame-width of 130 and frame-height of 56 after running
that function.
--
Jonathan Kyle Mitchell
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31968; Package
emacs.
(Mon, 02 Jul 2018 09:14:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 31968 <at> debbugs.gnu.org (full text, mbox):
> Under Cinnamon it worked without flickering.
Thanks. But please post your code here so we know what we are
discussing.
> There is just a minor
> problem that could be pointing to a bug elsewhere in emacs. Cinnamon
> implements a progression of tiles layouts, for instance starting from
> a normal sized window (i) you press Super-Up and the window is tiled
> to the top half of the screen, (ii) you then press Super-Up again and
> the window is maximized, (iii) finally you press Super-Down and the
> window returns to top half tile mode. In general only fully maximized
> windows (ii) gets undecorated, as intended, but when transitioning
> from fully maximized to top half tiled (ii->iii) emacs still sees the
> maximized state in the fullscreen frame parameter and fails to
> undecorate the window. Nevertheless the client state in (ii) is:
>
> ~:: xprop | grep _NET_WM_STATE
> _NET_WM_STATE(ATOM) = _NET_WM_STATE_MAXIMIZED_VERT, _NET_WM_STATE_TILED
>
> The problem seems to be in the reported frame parameters, not in
> Jonathan's hook.
get_current_wm_state in xterm.c has this
else if (a == dpyinfo->Xatom_net_wm_state_maximized_vert)
{
if (*size_state == FULLSCREEN_WIDTH)
*size_state = FULLSCREEN_MAXIMIZED;
else
*size_state = FULLSCREEN_HEIGHT;
}
Could you try setting a GDB breakpoint at the
if (*size_state == FULLSCREEN_WIDTH)
line and see if it ever gets executed during (ii->iii).
Thanks for trying, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31968; Package
emacs.
(Mon, 02 Jul 2018 13:22:01 GMT)
Full text and
rfc822 format available.
Message #83 received at 31968 <at> debbugs.gnu.org (full text, mbox):
Carlos Pita <carlosjosepita <at> gmail.com> writes:
> Sorry if this is a silly question but what would be the right hook to
> call this function? The frame should already exist but not yet be
> mapped or made visible.
I think the best solution in that case would be to have a frame
parameter for this property that you could set in default-frame-alist,
that would get it applied automatically. There should then be no need
to put it in a hook.
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31968; Package
emacs.
(Mon, 02 Jul 2018 13:25:02 GMT)
Full text and
rfc822 format available.
Message #86 received at 31968 <at> debbugs.gnu.org (full text, mbox):
Carlos Pita <carlosjosepita <at> gmail.com> writes:
> Moving to a more manual approach I find a new problem: at least under
> gnome undecorating the frame makes it lose its focus.
>
> (global-set-key (kbd "C-x t")
> (lambda () (interactive)
> (set-frame-parameter nil 'undecorated
> (not (frame-parameter nil 'undecorated)))))
FWIW I donʼt see this under kwin (I do have focus-follows-mouse, which
might be influencing it).
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31968; Package
emacs.
(Mon, 02 Jul 2018 13:32:01 GMT)
Full text and
rfc822 format available.
Message #89 received at 31968 <at> debbugs.gnu.org (full text, mbox):
Carlos Pita <carlosjosepita <at> gmail.com> writes:
> Works for me too. I had to manually apply the patch because it doesn't
> cleanly applies on latest emacs-26, but besides that it does what is
> announced.
It was against master. Thereʼs no way Iʼd propose a change like this
for emacs-26, itʼs something that would require a lot of testing on a
lot of different systems first (and emacs' existing maximize behaviour
already has its share of problems).
> I think it's ok for this functionality to be gtk only since the kde
> people (and mostly everyone else) hate the csd stuff and want their wm
> to deal with decorations, old school. There is a flame war around this
> issue indeed. Plasma can be configured for "hide titlebar on maximize"
> but gnome and its derivatives (thinking of cinnamon here) can't. I
> wonder for how long it would be even possible to hide the titlebar at
> the gtk level.
Yes, Plasma has an option you can set in kwinrc. Iʼm undecided whether
I like the functionality or not, but it would be better if we tried to
at least support both kde and gnome here (which probably means
figuring out if thereʼs a way to specify this per-application in kde).
Regards
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31968; Package
emacs.
(Mon, 02 Jul 2018 14:24:02 GMT)
Full text and
rfc822 format available.
Message #92 received at 31968 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I would oppose to any change that exlicitly undecorates and redecorates the
window because (I'm summing up below what I already mentioned in a more
haphazardly way above):
1. Both under Gnome and under Cinnamon there are scenarios in which
changing the client decorated state wreaks havoc with WM operation. In
Gnome when you remove decorations the client lose focus. In Cinnamon
undecorating and redecorating a maximized window makes it completely
inaccessible, as if the WM couldn't show it anymore. I managed to make the
maximize-undecorate / unmaximize-decorate combo work under Cinnamon, but
that's all. Expect problems under other DEs and WMs.
2. Using Jonathan hook shares the problems described in point 1, since it
explicitly deals with decorations instead of just hinting the WM, but also
fails to redecorate the window in many circumstances, since the hook seems
to be called before the maximized property was removed from the frame
properties alist. Even if there were a more convenient event to hook from
(I was unable to find one in frame.el) I would disregard the solution
because of 1.
So that let's us able to support WMs that offers
_GTK_HIDE_TITLEBAR_WHEN_MAXIMIZED or a similar mechanism, or that
explicitly advertise they allow decoration change events triggered by the
client.
I've requested support for _GTK_HIDE_TITLEBAR_WHEN_MAXIMIZED in the
Cinnamon tracker [1], maybe you can argue a bit more for the feature there.
---
[1] https://github.com/linuxmint/Cinnamon/issues/7681
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31968; Package
emacs.
(Mon, 02 Jul 2018 14:29:02 GMT)
Full text and
rfc822 format available.
Message #95 received at 31968 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>
>
> FWIW I donʼt see this under kwin (I do have focus-follows-mouse, which
> might be influencing it).
>
As I mentioned elsewhere the effects seems to be very WM dependent. The
pair maximize-undecorate / unmaximize-decorate works fine on Cinnamon (but
not every other combination or sequence), maybe also under Plasma, but I
wouldn't count on it to continue working after a new release except the
developers explicitly supported the ability to change decorations.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31968; Package
emacs.
(Mon, 02 Jul 2018 17:46:01 GMT)
Full text and
rfc822 format available.
Message #98 received at 31968 <at> debbugs.gnu.org (full text, mbox):
One more thing to take into account: after decorations are removed by
the WM because of _GTK_HIDE_TITLEBAR_WHEN_MAXIMIZED the undecorated
property is still nil in the frame alist. Maybe it's better for this
to be so, but I'm not so sure, after all the WM did remove the
decorations.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31968; Package
emacs.
(Mon, 02 Jul 2018 20:04:02 GMT)
Full text and
rfc822 format available.
Message #101 received at 31968 <at> debbugs.gnu.org (full text, mbox):
Carlos Pita <carlosjosepita <at> gmail.com> writes:
> One more thing to take into account: after decorations are removed by
> the WM because of _GTK_HIDE_TITLEBAR_WHEN_MAXIMIZED the undecorated
> property is still nil in the frame alist. Maybe it's better for this
> to be so, but I'm not so sure, after all the WM did remove the
> decorations.
Youʼre confusing a proof-of-concept patch with a final implementation
:-)
Actually, if _GTK_HIDE_TITLEBAR_WHEN_MAXIMIZED and '(undecorated t)
result in the same visuals, why donʼt we do the latter when we
maximize a frame (with a variable to control it of course). Does that
not avoid more of the differences between window managers?
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31968; Package
emacs.
(Mon, 02 Jul 2018 22:31:02 GMT)
Full text and
rfc822 format available.
Message #104 received at 31968 <at> debbugs.gnu.org (full text, mbox):
> Youʼre confusing a proof-of-concept patch with a final implementation
> :-)
No, it's ok, it was meant to be just a heads up.
> Actually, if _GTK_HIDE_TITLEBAR_WHEN_MAXIMIZED and '(undecorated t)
> result in the same visuals, why donʼt we do the latter when we
> maximize a frame (with a variable to control it of course). Does that
> not avoid more of the differences between window managers?
See my previous email detailing why this might be a bad idea, namely:
unreliable response from WMs and no adequate hook in emacs. We have
control only over the second one.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31968; Package
emacs.
(Tue, 03 Jul 2018 02:07:02 GMT)
Full text and
rfc822 format available.
Message #107 received at 31968 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Cinnamon just added support for _GTK_HIDE_TITLEBAR_WHEN_MAXIMIZED to muffin
after I requested it because of this issue!!!
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31968; Package
emacs.
(Tue, 03 Jul 2018 02:10:02 GMT)
Full text and
rfc822 format available.
Message #110 received at 31968 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
These are other desktop environments that I know are able to hide titlebars
on maximize as a WM setting: xfce, plasma, mate. I think if emacs goes the
way of setting _GTK_HIDE_TITLEBAR_WHEN_MAXIMIZED pretty much everything
will be covered (although not always in a per app basis).
On Mon, Jul 2, 2018, 11:06 PM Carlos Pita <carlosjosepita <at> gmail.com> wrote:
> Cinnamon just added support for _GTK_HIDE_TITLEBAR_WHEN_MAXIMIZED to
> muffin after I requested it because of this issue!!!
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31968; Package
emacs.
(Tue, 03 Jul 2018 23:36:02 GMT)
Full text and
rfc822 format available.
Message #113 received at 31968 <at> debbugs.gnu.org (full text, mbox):
I've written this utility
https://github.com/memeplex/maximal
that uses xlib to handle creation events and set the
_GTK_HIDE_TITLEBAR_WHEN_MAXIMIZED for normal windows.
It comes with a few goodies: blacklist/whitelist, disable/resume, pip
installation, but nevertheless it's quite a humble script.
I mention it here because:
1. Someone reading this might want to get the feature before emacs 27.
2. Given that one can blacklist everything and whitelist just emacs,
it could be seen as a solution for this issue (although I understand
you might still want to implement it as a feature of emacs itself).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31968; Package
emacs.
(Fri, 04 Sep 2020 04:16:01 GMT)
Full text and
rfc822 format available.
Message #116 received at 31968 <at> debbugs.gnu.org (full text, mbox):
Robert Pluim <rpluim <at> gmail.com> writes:
> Patch attached. It sets the correct property on my emacs frame for me,
> but it appears KWin ignores that, so I see no effect. No doubt needs a
> few more USE_GTK ifdef checks.
[...]
> +void
> +xg_set_hide_titlebar_when_maximized (struct frame *f, Lisp_Object hide)
Reading this thread, I'm not quite sure what the outcome was. It seemed
like this approach worked for Carlos in some environments, and in the
one it didn't work (Cinnamon), that one got support for it after he
reported that as a bug to the Cinnamon people?
So should something like this be added?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31968; Package
emacs.
(Thu, 28 Apr 2022 12:04:02 GMT)
Full text and
rfc822 format available.
Message #119 received at 31968 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> Reading this thread, I'm not quite sure what the outcome was. It seemed
> like this approach worked for Carlos in some environments, and in the
> one it didn't work (Cinnamon), that one got support for it after he
> reported that as a bug to the Cinnamon people?
>
> So should something like this be added?
I tried Robert's patch in Emacs 29 with Gnome Shell and Debian/bookworm
with:
(x-set-hide-titlebar-when-maximized (selected-frame) t)
And the title bar was not hidden when maximised. To it seems like this
doesn't work reliably (any more).
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31968; Package
emacs.
(Fri, 29 Apr 2022 04:29:01 GMT)
Full text and
rfc822 format available.
Message #122 received at 31968 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> So should something like this be added?
I don't see why this feature cannot be implemented in Lisp by users who
want it. It seems extravagant to have it as a frame parameter in C,
especially one relying on an undocumented window property specific to
new versions of GTK that is not implemented by many window managers.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31968; Package
emacs.
(Fri, 29 Apr 2022 10:05:01 GMT)
Full text and
rfc822 format available.
Message #125 received at 31968 <at> debbugs.gnu.org (full text, mbox):
Po Lu <luangruo <at> yahoo.com> writes:
> I don't see why this feature cannot be implemented in Lisp by users who
> want it. It seems extravagant to have it as a frame parameter in C,
> especially one relying on an undocumented window property specific to
> new versions of GTK that is not implemented by many window managers.
If I skimmed the thread correctly, the Lisp solutions led to some
"flickering" -- i.e., first we show the frame maximised with a title
bar, and then the callback hook is called, and then we remove the title
bar. So asking the WM to do it all in one operation seemed attractive.
But when that doesn't even work, then the in-Lisp solution seems like
the only option.
(Note that I haven't actually tested the Lisp solution.)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31968; Package
emacs.
(Fri, 29 Apr 2022 10:27:02 GMT)
Full text and
rfc822 format available.
Message #128 received at 31968 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> If I skimmed the thread correctly, the Lisp solutions led to some
> "flickering" -- i.e., first we show the frame maximised with a title
> bar, and then the callback hook is called, and then we remove the title
> bar. So asking the WM to do it all in one operation seemed attractive.
> But when that doesn't even work, then the in-Lisp solution seems like
> the only option.
BTW, the frame resize synchronization introduced recently might
alleviate the flicker in the Lisp-based solutions, though I don't see
any flicker with or without resize synchronization.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31968; Package
emacs.
(Fri, 29 Apr 2022 10:32:02 GMT)
Full text and
rfc822 format available.
Message #131 received at 31968 <at> debbugs.gnu.org (full text, mbox):
Po Lu <luangruo <at> yahoo.com> writes:
> BTW, the frame resize synchronization introduced recently might
> alleviate the flicker in the Lisp-based solutions, though I don't see
> any flicker with or without resize synchronization.
Let's see... this was the proposed code:
(defun hide-titlebar-when-maximized (frame)
(if (eq 'maximized (alist-get 'fullscreen (frame-parameters frame)))
(set-frame-parameter frame 'undecorated t)
(set-frame-parameter frame 'undecorated nil)))
(add-hook 'window-size-change-functions 'hide-titlebar-when-maximized)
And indeed -- I don't see any flickering, so this seems like a good
solution.
So I think I'll add `hide-titlebar-when-maximized' to Emacs 29, and then
document that as a possible value for `window-size-change-functions'.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31968; Package
emacs.
(Fri, 29 Apr 2022 10:43:02 GMT)
Full text and
rfc822 format available.
Message #134 received at 31968 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> So I think I'll add `hide-titlebar-when-maximized' to Emacs 29, and then
> document that as a possible value for `window-size-change-functions'.
Now done, so I'm closing this bug report.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug marked as fixed in version 29.1, send any further explanations to
31968 <at> debbugs.gnu.org and Carlos Pita <carlosjosepita <at> gmail.com>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Fri, 29 Apr 2022 10:43:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31968; Package
emacs.
(Fri, 29 Apr 2022 17:23:02 GMT)
Full text and
rfc822 format available.
Message #139 received at 31968 <at> debbugs.gnu.org (full text, mbox):
> So I think I'll add `hide-titlebar-when-maximized' to Emacs 29, and then
> document that as a possible value for `window-size-change-functions'.
`window-size-change-functions' is a strange choice to react to the event
that maximizes the frame. Maybe there is a hook that reacts to frame changes?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31968; Package
emacs.
(Fri, 29 Apr 2022 18:58:01 GMT)
Full text and
rfc822 format available.
Message #142 received at 31968 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 29 Apr 2022 20:11:47 +0300
> Cc: Po Lu <luangruo <at> yahoo.com>, 31968 <at> debbugs.gnu.org,
> Carlos Pita <carlosjosepita <at> gmail.com>
>
> `window-size-change-functions' is a strange choice to react to the event
> that maximizes the frame.
When a frame changes its size, at least one of its windows changes
dimensions, so these functions are called.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sat, 28 May 2022 11:24:07 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 328 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.