* bug#21317: 25.0.50; frame-resize-pixelwise has no effect (GTK, no window manager) @ 2015-08-21 22:34 Pip Cet 2015-08-22 6:40 ` martin rudalics 0 siblings, 1 reply; 19+ messages in thread From: Pip Cet @ 2015-08-21 22:34 UTC (permalink / raw) To: 21317 When starting Emacs (GTK build) on an X server which has no window manager (such as a newly-created Xnest session), setting `frame-resize-pixelwise' to t followed by a resize operation often has no effect. In GNU Emacs 25.0.50.31 (x86_64-unknown-linux-gnu, GTK+ Version 3.16.6) of 2015-08-21 on ... Repository revision: a9d799b5dea1efb9216dc6f985ffc9bdd25d8cba Windowing system distributor `The X.Org Foundation', version 11.0.11702000 System Description: Debian GNU/Linux unstable (sid) Configured using: `configure 'CFLAGS=-O0 -g3'' Configured features: XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND DBUS GCONF GSETTINGS NOTIFY LIBSELINUX GNUTLS LIBXML2 FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 Important settings: value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix Major mode: Lisp Interaction Minor modes in effect: tooltip-mode: t global-eldoc-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 font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Recent messages: For information about GNU Emacs and the GNU system, type C-h C-a. user-error: Beginning of history; no preceding item user-error: End of history; no default available Load-path shadows: None found. Features: (shadow sort gnus-util mail-extr emacsbug message dired format-spec rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util help-fns help-mode easymenu cl-loaddefs pcase cl-lib mail-prsvr mail-utils time-date mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core 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 charscript case-table epa-hook jka-cmpr-hook help simple abbrev 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 gfilenotify dynamic-setting system-font-setting font-render-setting move-toolbar gtk x-toolkit x multi-tty make-network-process emacs) Memory information: ((conses 16 81307 5982) (symbols 48 19076 0) (miscs 40 42 86) (strings 32 13284 4355) (string-bytes 1 377456) (vectors 16 11222) (vector-slots 8 413750 4157) (floats 8 130 19) (intervals 56 179 0) (buffers 976 11) (heap 1024 33363 990)) Steps to reproduce: Xnest :3 -geometry 877x877+0+0 DISPLAY=:3 emacs -Q --eval "(progn (setq frame-resize-pixelwise t) (set-frame-parameter (selected-frame) 'fullscreen 'fullboth))" Expected result: Emacs frame fills Xnest window precisely. Actual result: Emacs frame size differs from Xnest window size. In my case, the minibuffer/echo area is cut off and there is an area to the right of the Emacs window that is not used by the Emacs frame. Analysis: There are two problems: (1) x_check_fullscreen (xterm.c) calls XResizeWindow without first calling x_wm_set_size_hint (gtkutil.c), which would propagate the `frame-resize-pixelwise' flag to have an effect on GTK/GDK (2) x_wm_set_size_hint returns without propagating the `frame-resize-pixelwise' flag when the frame's fullscreen property is 'maximized or 'fullboth. The first appears to be simple oversight, but the second is intentional to work around a KWin bug. Note that despite the name, the GTK version of `x_wm_set_size_hint' does not rely on the presence of a window manager or indeed communicate with it. Fixing the first problem is trivial, but the second problem would require knowing more about the KWin bug that is being avoided by the workaround at #14627. ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#21317: 25.0.50; frame-resize-pixelwise has no effect (GTK, no window manager) 2015-08-21 22:34 bug#21317: 25.0.50; frame-resize-pixelwise has no effect (GTK, no window manager) Pip Cet @ 2015-08-22 6:40 ` martin rudalics 2015-08-22 10:50 ` Pip Cet 0 siblings, 1 reply; 19+ messages in thread From: martin rudalics @ 2015-08-22 6:40 UTC (permalink / raw) To: Pip Cet, 21317 > When starting Emacs (GTK build) on an X server which has no window > manager (such as a newly-created Xnest session), setting > `frame-resize-pixelwise' to t followed by a resize operation often has > no effect. According to the manual Setting this variable usually causes the next resize operation to pass the corresponding size hints to the window manager. This means that this variable should be set only in a user's initial file; applications should never bind it temporarily. So it's possible that Xnest or some other X component refuses to resize your frame because the size hints were set up inappropriately. Does it also fail when `frame-resize-pixelwise' is set to t in your initial file? Does it fail when you set `frame-resize-pixelwise' to t, request an integral resize first and a second non-integral one afterwards? martin ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#21317: 25.0.50; frame-resize-pixelwise has no effect (GTK, no window manager) 2015-08-22 6:40 ` martin rudalics @ 2015-08-22 10:50 ` Pip Cet 2015-08-22 14:16 ` martin rudalics 0 siblings, 1 reply; 19+ messages in thread From: Pip Cet @ 2015-08-22 10:50 UTC (permalink / raw) To: martin rudalics; +Cc: 21317 [-- Attachment #1: Type: text/plain, Size: 2851 bytes --] Thanks for responding! On Sat, Aug 22, 2015 at 6:40 AM, martin rudalics <rudalics@gmx.at> wrote: >> When starting Emacs (GTK build) on an X server which has no window >> manager (such as a newly-created Xnest session), setting >> `frame-resize-pixelwise' to t followed by a resize operation often has >> no effect. > > According to the manual > > Setting this variable usually causes the next resize operation to > pass the corresponding size hints to the window manager. This > means that this variable should be set only in a user's initial > file; applications should never bind it temporarily. That documentation is outdated and does not apply to GTK builds in all cases, I'm afraid. It is not the window manager that decides to honor or dishonor frame-resize-pixelwise but GDK. See x_wm_set_size_hint and gtk_window_move_resize (gtkwindow.c, in the GTK sources). In particular, gtk_window_compute_configure_request calls gtk_window_constrain_size which calls gdk_window_constrain_size which calculates width = base_width + FLOOR (width - base_width, xinc); height = base_height + FLOOR (height - base_height, yinc); (where FLOOR is defined as #define FLOOR(value, base) ( ((gint) ((value) / (base))) * (base) ) ) > So it's possible that Xnest or some other X component refuses to resize > your frame because the size hints were set up inappropriately. I'm pretty sure that's not what's happening, but I'll be happy to provide traces to demonstrate my analysis is correct...or to prove it wrong, of course! The attached gdb log shows quite clearly that it's GDK making the second (erroneous) call to XResizeWindow, not Xnest (there is no window manager). > Does it also fail when `frame-resize-pixelwise' is set to t in your > initial file? Yes, it does. > Does it fail when you set `frame-resize-pixelwise' to t, request an > integral resize first and a second non-integral one afterwards? I'm not sure I fully understand how you define "integral". In short, non-full-screen resize + redisplay + full-screen resize works, the other combinations do not. If I run this code (Xnest running on display :3): DISPLAY=:3 emacs -Q --eval "(progn (setq frame-resize-pixelwise t) (set-frame-height (selected-frame) (1+ (frame-pixel-height (selected-frame))) nil t) (redisplay) (set-frame-parameter (selected-frame) 'fullscreen 'fullboth))" Things work, but without the "(redisplay)" they don't. (So that's a non-full-screen resize first, then a full-screen resize). Doing the full-screen resize first breaks things. I must also point out that without the "(redisplay)", there are unexpected results: the full screen resize appears to be ignored entirely. But, again, I currently stand by my initial analysis of what's happening. The problem is that we cannot simply do the right thing because of the KWin bug... [-- Attachment #2: emacs-bug-008-gdb-log.txt --] [-- Type: text/plain, Size: 22085 bytes --] % Xnest :2 -geometry 877x877+0+0 & Xnest :2 -geometry 877x877+0+0 & [1] 14675 % DISPLAY=:2 /usr/bin/gdb --args emacs -Q --eval "(progn (setq frame-resize-pixelwise t) (set-frame-parameter (selected-frame) 'fullscreen 'fullboth))" <wise t) (set-frame-parameter (selected-frame) 'fullscreen 'fullboth))" GNU gdb (Debian 7.9.1-1) 7.9.1 Copyright (C) 2015 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from emacs...done. (gdb) b XResizeWindow b XResizeWindow Breakpoint 1 at 0x4167a0 (gdb) r r Starting program: /usr/local/bin/emacs -Q --eval \(progn\ \(setq\ frame-resize-pixelwise\ t\)\ \(set-frame-parameter\ \(selected-frame\)\ \'fullscreen\ \'fullboth\)\) [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". 1 XSELINUXs still allocated at reset SCREEN: 0 objects of 152 bytes = 0 total bytes 0 private allocs COLORMAP: 0 objects of 8 bytes = 0 total bytes 0 private allocs DEVICE: 0 objects of 96 bytes = 0 total bytes 0 private allocs CLIENT: 0 objects of 56 bytes = 0 total bytes 0 private allocs WINDOW: 0 objects of 72 bytes = 0 total bytes 0 private allocs PIXMAP: 1 objects of 24 bytes = 24 total bytes 0 private allocs GC: 0 objects of 24 bytes = 0 total bytes 0 private allocs CURSOR: 0 objects of 8 bytes = 0 total bytes 0 private allocs TOTAL: 1 objects, 24 bytes, 0 allocs 1 PIXMAPs still allocated at reset PIXMAP: 1 objects of 24 bytes = 24 total bytes 0 private allocs GC: 0 objects of 24 bytes = 0 total bytes 0 private allocs CURSOR: 0 objects of 8 bytes = 0 total bytes 0 private allocs TOTAL: 1 objects, 24 bytes, 0 allocs 1 DAMAGEs still allocated at reset TOTAL: 0 objects, 0 bytes, 0 allocs 1 XSELINUXs still allocated at reset SCREEN: 0 objects of 152 bytes = 0 total bytes 0 private allocs COLORMAP: 0 objects of 8 bytes = 0 total bytes 0 private allocs DEVICE: 0 objects of 96 bytes = 0 total bytes 0 private allocs CLIENT: 0 objects of 56 bytes = 0 total bytes 0 private allocs WINDOW: 0 objects of 72 bytes = 0 total bytes 0 private allocs PIXMAP: 1 objects of 24 bytes = 24 total bytes 0 private allocs GC: 0 objects of 24 bytes = 0 total bytes 0 private allocs CURSOR: 0 objects of 8 bytes = 0 total bytes 0 private allocs TOTAL: 1 objects, 24 bytes, 0 allocs 1 PIXMAPs still allocated at reset PIXMAP: 1 objects of 24 bytes = 24 total bytes 0 private allocs GC: 0 objects of 24 bytes = 0 total bytes 0 private allocs CURSOR: 0 objects of 8 bytes = 0 total bytes 0 private allocs TOTAL: 1 objects, 24 bytes, 0 allocs 1 DAMAGEs still allocated at reset TOTAL: 0 objects, 0 bytes, 0 allocs 1 XSELINUXs still allocated at reset SCREEN: 0 objects of 152 bytes = 0 total bytes 0 private allocs COLORMAP: 0 objects of 8 bytes = 0 total bytes 0 private allocs DEVICE: 0 objects of 96 bytes = 0 total bytes 0 private allocs CLIENT: 0 objects of 56 bytes = 0 total bytes 0 private allocs WINDOW: 0 objects of 72 bytes = 0 total bytes 0 private allocs PIXMAP: 1 objects of 24 bytes = 24 total bytes 0 private allocs GC: 0 objects of 24 bytes = 0 total bytes 0 private allocs CURSOR: 0 objects of 8 bytes = 0 total bytes 0 private allocs TOTAL: 1 objects, 24 bytes, 0 allocs 1 PIXMAPs still allocated at reset PIXMAP: 1 objects of 24 bytes = 24 total bytes 0 private allocs GC: 0 objects of 24 bytes = 0 total bytes 0 private allocs CURSOR: 0 objects of 8 bytes = 0 total bytes 0 private allocs TOTAL: 1 objects, 24 bytes, 0 allocs 1 DAMAGEs still allocated at reset TOTAL: 0 objects, 0 bytes, 0 allocs [New Thread 0x7fffe5bde700 (LWP 14768)] [New Thread 0x7fffe538d700 (LWP 14770)] [New Thread 0x7fffe7daa700 (LWP 14734)] Breakpoint 1, XResizeWindow (dpy=0xd25940, w=w@entry=6291477, width=width@entry=591, height=height@entry=474) at ../../src/ChWindow.c:38 38 ../../src/ChWindow.c: No such file or directory. (gdb) c c Continuing. Breakpoint 1, XResizeWindow (dpy=0xd25940, w=6291477, width=877, height=877) at ../../src/ChWindow.c:38 38 in ../../src/ChWindow.c (gdb) bt bt #0 XResizeWindow (dpy=0xd25940, w=6291477, width=877, height=877) at ../../src/ChWindow.c:38 #1 0x000000000051e540 in x_check_fullscreen (f=0x12ac8d0) at xterm.c:10194 #2 0x000000000051e1da in XTfullscreen_hook (f=0x12ac8d0) at xterm.c:10111 #3 0x000000000042d2cd in x_set_fullscreen (f=0x12ac8d0, new_value=23328, old_value=0) at frame.c:3480 #4 0x000000000042cb0d in x_set_frame_parameters (f=0x12ac8d0, alist=0) at frame.c:3358 #5 0x000000000042af52 in Fmodify_frame_parameters (frame=19581141, alist=17149331) at frame.c:2675 #6 0x00000000005ec894 in Ffuncall (nargs=3, args=0x7fffffffcb80) at eval.c:2737 #7 0x000000000062f468 in exec_byte_code (bytestr=10600972, vector=10601005, maxdepth=30, args_template=3086, nargs=3, args=0x7fffffffcff8) at bytecode.c:919 #8 0x00000000005ed0a1 in funcall_lambda (fun=10600925, nargs=3, arg_vector=0x7fffffffcfe0) at eval.c:2901 #9 0x00000000005ece53 in apply_lambda (fun=10600925, args=17150691, count=12) at eval.c:2842 #10 0x00000000005eb5f1 in eval_sub (form=17150755) at eval.c:2242 #11 0x00000000005e7751 in Fprogn (body=17149955) at eval.c:460 #12 0x00000000005eb09f in eval_sub (form=17151091) at eval.c:2147 #13 0x00000000005eab88 in Feval (form=17151091, lexical=0) at eval.c:2011 #14 0x00000000005ec894 in Ffuncall (nargs=2, args=0x7fffffffd520) at eval.c:2737 #15 0x000000000062f468 in exec_byte_code (bytestr=10651788, vector=10651821, maxdepth=90, args_template=1030, nargs=1, args=0x7fffffffda78) at bytecode.c:919 #16 0x00000000005ed0a1 in funcall_lambda (fun=10651741, nargs=1, arg_vector=0x7fffffffda70) at eval.c:2901 #17 0x00000000005ecae3 in Ffuncall (nargs=2, args=0x7fffffffda68) at eval.c:2783 #18 0x000000000062f468 in exec_byte_code (bytestr=10628596, vector=10628629, maxdepth=86, args_template=2, nargs=0, args=0x7fffffffe018) at bytecode.c:919 #19 0x00000000005ed0a1 in funcall_lambda (fun=10628549, nargs=0, arg_vector=0x7fffffffe018) at eval.c:2901 #20 0x00000000005ecae3 in Ffuncall (nargs=1, args=0x7fffffffe010) at eval.c:2783 #21 0x000000000062f468 in exec_byte_code (bytestr=10625196, vector=10625229, maxdepth=50, args_template=2, nargs=0, args=0x7fffffffe4b0) at bytecode.c:919 #22 0x00000000005ed0a1 in funcall_lambda (fun=10625149, nargs=0, arg_vector=0x7fffffffe4b0) at eval.c:2901 #23 0x00000000005ece53 in apply_lambda (fun=10625149, args=0, count=3) at eval.c:2842 #24 0x00000000005eb5f1 in eval_sub (form=17711795) at eval.c:2242 #25 0x00000000005eab88 in Feval (form=17711795, lexical=0) at eval.c:2011 #26 0x0000000000551bda in top_level_2 () at keyboard.c:1147 #27 0x00000000005e94e1 in internal_condition_case (bfun=0x551bb7 <top_level_2>, handlers=18672, hfun=0x551677 <cmd_error>) at eval.c:1363 #28 0x0000000000551c1b in top_level_1 (ignore=0) at keyboard.c:1155 #29 0x00000000005e8c76 in internal_catch (tag=44496, func=0x551bdc <top_level_1>, arg=0) at eval.c:1123 #30 0x0000000000551b0f in command_loop () at keyboard.c:1116 #31 0x000000000055123f in recursive_edit_1 () at keyboard.c:723 #32 0x00000000005513d3 in Frecursive_edit () at keyboard.c:794 #33 0x000000000054f20d in main (argc=4, argv=0x7fffffffea58) at emacs.c:1629 (gdb) c c Continuing. Breakpoint 1, XResizeWindow (dpy=0xd25940, w=w@entry=6291477, width=width@entry=871, height=height@entry=877) at ../../src/ChWindow.c:38 38 in ../../src/ChWindow.c (gdb) bt bt #0 XResizeWindow (dpy=0xd25940, w=w@entry=6291477, width=width@entry=871, height=height@entry=877) at ../../src/ChWindow.c:38 #1 0x00007ffff677a74a in window_x11_resize (height=877, width=871, window=0xd3dbd0) at /tmp/buildd/gtk+3.0-3.16.6/./gdk/x11/gdkwindow-x11.c:1806 #2 gdk_window_x11_move_resize (window=0xd3dbd0, with_move=<optimized out>, x=<optimized out>, y=<optimized out>, width=<optimized out>, height=<optimized out>) at /tmp/buildd/gtk+3.0-3.16.6/./gdk/x11/gdkwindow-x11.c:1890 #3 0x00007ffff6757371 in gdk_window_move_resize_toplevel (height=877, width=871, y=0, x=0, with_move=0, window=0xd3dbd0) at /tmp/buildd/gtk+3.0-3.16.6/./gdk/gdkwindow.c:5619 #4 gdk_window_move_resize_internal (window=0xd3dbd0, with_move=0, x=0, y=0, width=871, height=877) at /tmp/buildd/gtk+3.0-3.16.6/./gdk/gdkwindow.c:5686 #5 0x00007ffff6d35f59 in gtk_window_move_resize (window=0x158c230) at /tmp/buildd/gtk+3.0-3.16.6/./gtk/gtkwindow.c:9371 #6 gtk_window_check_resize (container=0x158c230) at /tmp/buildd/gtk+3.0-3.16.6/./gtk/gtkwindow.c:8071 #7 0x00007ffff5390504 in _g_closure_invoke_va (closure=0xd01b00, return_value=0x0, instance=0x158c230, args=0x7fffffffc040, n_params=<optimized out>, param_types=0x0) at /tmp/buildd/glib2.0-2.44.1/./gobject/gclosure.c:831 #8 0x00007ffff53a9fa7 in g_signal_emit_valist (instance=0x158c230, signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7fffffffc040) at /tmp/buildd/glib2.0-2.44.1/./gobject/gsignal.c:3214 #9 0x00007ffff53aa8ff in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>) at /tmp/buildd/glib2.0-2.44.1/./gobject/gsignal.c:3361 #10 0x00007ffff6b2f96c in gtk_container_idle_sizer (clock=0xd41240, container=0x158c230) at /tmp/buildd/gtk+3.0-3.16.6/./gtk/gtkcontainer.c:1873 #11 0x00007ffff5390504 in _g_closure_invoke_va (closure=0x1bd5b50, return_value=0x0, instance=0xd41240, args=0x7fffffffc388, n_params=<optimized out>, param_types=0x0) at /tmp/buildd/glib2.0-2.44.1/./gobject/gclosure.c:831 #12 0x00007ffff53a9fa7 in g_signal_emit_valist (instance=instance@entry=0xd41240, signal_id=signal_id@entry=140, detail=detail@entry=0, var_args=var_args@entry=0x7fffffffc388) at /tmp/buildd/glib2.0-2.44.1/./gobject/gsignal.c:3214 #13 0x00007ffff53aae4a in g_signal_emit_by_name (instance=instance@entry=0xd41240, detailed_signal=detailed_signal@entry=0x7ffff67b319a "layout") at /tmp/buildd/glib2.0-2.44.1/./gobject/gsignal.c:3401 #14 0x00007ffff6747624 in gdk_frame_clock_paint_idle (data=0xd41240) at /tmp/buildd/gtk+3.0-3.16.6/./gdk/gdkframeclockidle.c:408 #15 0x00007ffff6736d88 in gdk_threads_dispatch (data=0xefccc0, data@entry=<error reading variable: value has been optimized out>) at /tmp/buildd/gtk+3.0-3.16.6/./gdk/gdk.c:719 #16 0x00007ffff50bb5e3 in g_timeout_dispatch (source=0x1bd6c00, callback=<optimized out>, user_data=<optimized out>) at /tmp/buildd/glib2.0-2.44.1/./glib/gmain.c:4545 #17 0x00007ffff50bab4d in g_main_dispatch (context=0xd1f0c0) at /tmp/buildd/glib2.0-2.44.1/./glib/gmain.c:3122 #18 g_main_context_dispatch (context=context@entry=0xd1f0c0) at /tmp/buildd/glib2.0-2.44.1/./glib/gmain.c:3737 #19 0x00007ffff50baf20 in g_main_context_iterate (context=context@entry=0xd1f0c0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at /tmp/buildd/glib2.0-2.44.1/./glib/gmain.c:3808 #20 0x00007ffff50bafcc in g_main_context_iteration (context=0xd1f0c0, context@entry=0x0, may_block=may_block@entry=1) at /tmp/buildd/glib2.0-2.44.1/./glib/gmain.c:3869 #21 0x00007ffff6be1ff5 in gtk_main_iteration () at /tmp/buildd/gtk+3.0-3.16.6/./gtk/gtkmain.c:1320 #22 0x000000000051b4f2 in XTread_socket (terminal=0x11fe6a0, hold_quit=0x7fffffffc6a0) at xterm.c:8644 #23 0x000000000055d733 in gobble_input () at keyboard.c:6929 #24 0x000000000055db1d in handle_async_input () at keyboard.c:7181 #25 0x000000000055db3c in process_pending_signals () at keyboard.c:7195 #26 0x000000000055db7c in unblock_input_to (level=0) at keyboard.c:7210 #27 0x000000000055dbb1 in totally_unblock_input () at keyboard.c:7238 #28 0x000000000051e920 in x_wait_for_event (f=0x12ac8d0, eventtype=22) at xterm.c:10318 #29 0x000000000051e563 in x_check_fullscreen (f=0x12ac8d0) at xterm.c:10199 #30 0x000000000051e1da in XTfullscreen_hook (f=0x12ac8d0) at xterm.c:10111 #31 0x000000000042d2cd in x_set_fullscreen (f=0x12ac8d0, new_value=23328, old_value=0) at frame.c:3480 #32 0x000000000042cb0d in x_set_frame_parameters (f=0x12ac8d0, alist=0) at frame.c:3358 #33 0x000000000042af52 in Fmodify_frame_parameters (frame=19581141, alist=17149331) at frame.c:2675 #34 0x00000000005ec894 in Ffuncall (nargs=3, args=0x7fffffffcb80) at eval.c:2737 #35 0x000000000062f468 in exec_byte_code (bytestr=10600972, vector=10601005, maxdepth=30, ---Type <return> to continue, or q <return> to quit--- args_template=3086, nargs=3, args=0x7fffffffcff8) at bytecode.c:919 #36 0x00000000005ed0a1 in funcall_lambda (fun=10600925, nargs=3, arg_vector=0x7fffffffcfe0) at eval.c:2901 #37 0x00000000005ece53 in apply_lambda (fun=10600925, args=17150691, count=12) at eval.c:2842 #38 0x00000000005eb5f1 in eval_sub (form=17150755) at eval.c:2242 #39 0x00000000005e7751 in Fprogn (body=17149955) at eval.c:460 #40 0x00000000005eb09f in eval_sub (form=17151091) at eval.c:2147 #41 0x00000000005eab88 in Feval (form=17151091, lexical=0) at eval.c:2011 #42 0x00000000005ec894 in Ffuncall (nargs=2, args=0x7fffffffd520) at eval.c:2737 #43 0x000000000062f468 in exec_byte_code (bytestr=10651788, vector=10651821, maxdepth=90, args_template=1030, nargs=1, args=0x7fffffffda78) at bytecode.c:919 #44 0x00000000005ed0a1 in funcall_lambda (fun=10651741, nargs=1, arg_vector=0x7fffffffda70) at eval.c:2901 #45 0x00000000005ecae3 in Ffuncall (nargs=2, args=0x7fffffffda68) at eval.c:2783 #46 0x000000000062f468 in exec_byte_code (bytestr=10628596, vector=10628629, maxdepth=86, args_template=2, nargs=0, args=0x7fffffffe018) at bytecode.c:919 #47 0x00000000005ed0a1 in funcall_lambda (fun=10628549, nargs=0, arg_vector=0x7fffffffe018) at eval.c:2901 #48 0x00000000005ecae3 in Ffuncall (nargs=1, args=0x7fffffffe010) at eval.c:2783 #49 0x000000000062f468 in exec_byte_code (bytestr=10625196, vector=10625229, maxdepth=50, args_template=2, nargs=0, args=0x7fffffffe4b0) at bytecode.c:919 #50 0x00000000005ed0a1 in funcall_lambda (fun=10625149, nargs=0, arg_vector=0x7fffffffe4b0) at eval.c:2901 #51 0x00000000005ece53 in apply_lambda (fun=10625149, args=0, count=3) at eval.c:2842 #52 0x00000000005eb5f1 in eval_sub (form=17711795) at eval.c:2242 #53 0x00000000005eab88 in Feval (form=17711795, lexical=0) at eval.c:2011 #54 0x0000000000551bda in top_level_2 () at keyboard.c:1147 #55 0x00000000005e94e1 in internal_condition_case (bfun=0x551bb7 <top_level_2>, handlers=18672, hfun=0x551677 <cmd_error>) at eval.c:1363 #56 0x0000000000551c1b in top_level_1 (ignore=0) at keyboard.c:1155 #57 0x00000000005e8c76 in internal_catch (tag=44496, func=0x551bdc <top_level_1>, arg=0) at eval.c:1123 #58 0x0000000000551b0f in command_loop () at keyboard.c:1116 #59 0x000000000055123f in recursive_edit_1 () at keyboard.c:723 #60 0x00000000005513d3 in Frecursive_edit () at keyboard.c:794 #61 0x000000000054f20d in main (argc=4, argv=0x7fffffffea58) at emacs.c:1629 (gdb) c c Continuing. Breakpoint 1, XResizeWindow (dpy=0xd25940, w=w@entry=6291477, width=width@entry=871, height=height@entry=922) at ../../src/ChWindow.c:38 38 in ../../src/ChWindow.c (gdb) bt bt #0 XResizeWindow (dpy=0xd25940, w=w@entry=6291477, width=width@entry=871, height=height@entry=922) at ../../src/ChWindow.c:38 #1 0x00007ffff677a74a in window_x11_resize (height=922, width=871, window=0xd3dbd0) at /tmp/buildd/gtk+3.0-3.16.6/./gdk/x11/gdkwindow-x11.c:1806 #2 gdk_window_x11_move_resize (window=0xd3dbd0, with_move=<optimized out>, x=<optimized out>, y=<optimized out>, width=<optimized out>, height=<optimized out>) at /tmp/buildd/gtk+3.0-3.16.6/./gdk/x11/gdkwindow-x11.c:1890 #3 0x00007ffff6757371 in gdk_window_move_resize_toplevel (height=922, width=871, y=0, x=0, with_move=0, window=0xd3dbd0) at /tmp/buildd/gtk+3.0-3.16.6/./gdk/gdkwindow.c:5619 #4 gdk_window_move_resize_internal (window=0xd3dbd0, with_move=0, x=0, y=0, width=871, height=922) at /tmp/buildd/gtk+3.0-3.16.6/./gdk/gdkwindow.c:5686 #5 0x00007ffff6d35f59 in gtk_window_move_resize (window=0x158c230) at /tmp/buildd/gtk+3.0-3.16.6/./gtk/gtkwindow.c:9371 #6 gtk_window_check_resize (container=0x158c230) at /tmp/buildd/gtk+3.0-3.16.6/./gtk/gtkwindow.c:8071 #7 0x00007ffff5390504 in _g_closure_invoke_va (closure=0xd01b00, return_value=0x0, instance=0x158c230, args=0x7fffffff9840, n_params=<optimized out>, param_types=0x0) at /tmp/buildd/glib2.0-2.44.1/./gobject/gclosure.c:831 #8 0x00007ffff53a9fa7 in g_signal_emit_valist (instance=0x158c230, signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7fffffff9840) at /tmp/buildd/glib2.0-2.44.1/./gobject/gsignal.c:3214 #9 0x00007ffff53aa8ff in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>) at /tmp/buildd/glib2.0-2.44.1/./gobject/gsignal.c:3361 #10 0x00007ffff6b2f96c in gtk_container_idle_sizer (clock=0xd41240, container=0x158c230) at /tmp/buildd/gtk+3.0-3.16.6/./gtk/gtkcontainer.c:1873 #11 0x00007ffff5390504 in _g_closure_invoke_va (closure=0x1b50db0, return_value=0x0, instance=0xd41240, args=0x7fffffff9b88, n_params=<optimized out>, param_types=0x0) at /tmp/buildd/glib2.0-2.44.1/./gobject/gclosure.c:831 #12 0x00007ffff53a9fa7 in g_signal_emit_valist (instance=instance@entry=0xd41240, signal_id=signal_id@entry=140, detail=detail@entry=0, var_args=var_args@entry=0x7fffffff9b88) at /tmp/buildd/glib2.0-2.44.1/./gobject/gsignal.c:3214 #13 0x00007ffff53aae4a in g_signal_emit_by_name (instance=instance@entry=0xd41240, detailed_signal=detailed_signal@entry=0x7ffff67b319a "layout") at /tmp/buildd/glib2.0-2.44.1/./gobject/gsignal.c:3401 #14 0x00007ffff6747624 in gdk_frame_clock_paint_idle (data=0xd41240) at /tmp/buildd/gtk+3.0-3.16.6/./gdk/gdkframeclockidle.c:408 #15 0x00007ffff6736d88 in gdk_threads_dispatch (data=0xf55500, data@entry=<error reading variable: value has been optimized out>) at /tmp/buildd/gtk+3.0-3.16.6/./gdk/gdk.c:719 #16 0x00007ffff50bb5e3 in g_timeout_dispatch (source=0x1b50de0, callback=<optimized out>, user_data=<optimized out>) at /tmp/buildd/glib2.0-2.44.1/./glib/gmain.c:4545 #17 0x00007ffff50bab4d in g_main_dispatch (context=0xd1f0c0) at /tmp/buildd/glib2.0-2.44.1/./glib/gmain.c:3122 #18 g_main_context_dispatch (context=context@entry=0xd1f0c0) at /tmp/buildd/glib2.0-2.44.1/./glib/gmain.c:3737 #19 0x00007ffff50baf20 in g_main_context_iterate (context=context@entry=0xd1f0c0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at /tmp/buildd/glib2.0-2.44.1/./glib/gmain.c:3808 #20 0x00007ffff50bafcc in g_main_context_iteration (context=0xd1f0c0, context@entry=0x0, may_block=may_block@entry=1) at /tmp/buildd/glib2.0-2.44.1/./glib/gmain.c:3869 #21 0x00007ffff6be1ff5 in gtk_main_iteration () at /tmp/buildd/gtk+3.0-3.16.6/./gtk/gtkmain.c:1320 #22 0x000000000051b4f2 in XTread_socket (terminal=0x11fe6a0, hold_quit=0x7fffffff9ea0) at xterm.c:8644 #23 0x000000000055d733 in gobble_input () at keyboard.c:6929 #24 0x000000000055db1d in handle_async_input () at keyboard.c:7181 #25 0x000000000055db3c in process_pending_signals () at keyboard.c:7195 #26 0x000000000055db7c in unblock_input_to (level=0) at keyboard.c:7210 #27 0x000000000055dbb1 in totally_unblock_input () at keyboard.c:7238 #28 0x000000000051e920 in x_wait_for_event (f=0x12ac8d0, eventtype=22) at xterm.c:10318 #29 0x0000000000538b9a in xg_frame_set_char_size (f=0x12ac8d0, width=840, height=858) at gtkutil.c:1017 #30 0x000000000051f070 in x_set_window_size (f=0x12ac8d0, change_gravity=false, width=840, height=858, pixelwise=true) at xterm.c:10488 #31 0x00000000004260b0 in adjust_frame_size (f=0x12ac8d0, new_width=-1, new_height=-1, inhibit=2, pretend=false, parameter=44160) at frame.c:490 #32 0x0000000000541579 in update_frame_tool_bar (f=0x12ac8d0) at gtkutil.c:5009 #33 0x0000000000455710 in redisplay_tool_bar (f=0x12ac8d0) at xdisp.c:12281 ---Type <return> to continue, or q <return> to quit--- #34 0x0000000000462451 in redisplay_window (window=19585253, just_this_one_p=false) at xdisp.c:16795 #35 0x0000000000458f3f in redisplay_window_0 (window=19585253) at xdisp.c:14197 #36 0x00000000005e965b in internal_condition_case_1 (bfun=0x458efd <redisplay_window_0>, arg=19585253, handlers=13333075, hfun=0x458ec5 <redisplay_window_error>) at eval.c:1387 #37 0x0000000000458ea2 in redisplay_windows (window=19585253) at xdisp.c:14177 #38 0x000000000045806a in redisplay_internal () at xdisp.c:13769 #39 0x0000000000456365 in redisplay () at xdisp.c:13032 #40 0x0000000000554c0e in read_char (commandflag=1, map=17224723, prev_event=0, used_mouse_menu=0x7fffffffe3ff, end_time=0x0) at keyboard.c:2546 #41 0x0000000000561e62 in read_key_sequence (keybuf=0x7fffffffe5d0, bufsize=30, prompt=0, dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9191 #42 0x00000000005522b8 in command_loop_1 () at keyboard.c:1406 #43 0x00000000005e94e1 in internal_condition_case (bfun=0x551e8d <command_loop_1>, handlers=18672, hfun=0x551677 <cmd_error>) at eval.c:1363 #44 0x0000000000551b94 in command_loop_2 (ignore=0) at keyboard.c:1138 #45 0x00000000005e8c76 in internal_catch (tag=44496, func=0x551b6b <command_loop_2>, arg=0) at eval.c:1123 #46 0x0000000000551b36 in command_loop () at keyboard.c:1117 #47 0x000000000055123f in recursive_edit_1 () at keyboard.c:723 #48 0x00000000005513d3 in Frecursive_edit () at keyboard.c:794 #49 0x000000000054f20d in main (argc=4, argv=0x7fffffffea58) at emacs.c:1629 (gdb) c c Continuing. ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#21317: 25.0.50; frame-resize-pixelwise has no effect (GTK, no window manager) 2015-08-22 10:50 ` Pip Cet @ 2015-08-22 14:16 ` martin rudalics 2015-08-22 15:32 ` Pip Cet 0 siblings, 1 reply; 19+ messages in thread From: martin rudalics @ 2015-08-22 14:16 UTC (permalink / raw) To: Pip Cet; +Cc: 21317 > Thanks for responding! Thanks for investigating! > On Sat, Aug 22, 2015 at 6:40 AM, martin rudalics <rudalics@gmx.at> wrote: >>> When starting Emacs (GTK build) on an X server which has no window >>> manager (such as a newly-created Xnest session), setting >>> `frame-resize-pixelwise' to t followed by a resize operation often has >>> no effect. >> >> According to the manual >> >> Setting this variable usually causes the next resize operation to >> pass the corresponding size hints to the window manager. This >> means that this variable should be set only in a user's initial >> file; applications should never bind it temporarily. > > That documentation is outdated and does not apply to GTK builds in all > cases, I'm afraid. It is not the window manager that decides to honor > or dishonor frame-resize-pixelwise but GDK. "Window manager" was an attempt to catch the behavior of all toolkits including Windows which doesn't have a window manager either. Feel free to suggest a better term. > See x_wm_set_size_hint and > gtk_window_move_resize (gtkwindow.c, in the GTK sources). In > particular, gtk_window_compute_configure_request calls > gtk_window_constrain_size which calls gdk_window_constrain_size which > calculates > > width = base_width + FLOOR (width - base_width, xinc); > height = base_height + FLOOR (height - base_height, yinc); > > (where FLOOR is defined as #define FLOOR(value, base) ( ((gint) > ((value) / (base))) * (base) ) ) I can't find that in the version from https://github.com/GNOME/gtk/blob/master/gtk/gtkwindow.c and also must admit that I have forgotten most of the GTK code by now. IIRC base_width and base_height are somehow calculated from a minimum size and what Emacs requested earlier. If frame_resize_pixelwise is true we _should_ have requested 1 from this size_hints.width_inc = frame_resize_pixelwise ? 1 : FRAME_COLUMN_WIDTH (f); size_hints.height_inc = frame_resize_pixelwise ? 1 : FRAME_LINE_HEIGHT (f); Can you check how apparently an "integral" (the increment is a multiple of either FRAME_COLUMN_WIDTH or FRAME_LINE_HEIGHT) value gets passed via size_hints in your case? >> So it's possible that Xnest or some other X component refuses to resize >> your frame because the size hints were set up inappropriately. > > I'm pretty sure that's not what's happening, but I'll be happy to > provide traces to demonstrate my analysis is correct...or to prove it > wrong, of course! The attached gdb log shows quite clearly that it's > GDK making the second (erroneous) call to XResizeWindow, not Xnest > (there is no window manager). OK. I won't doubt what you say here. >> Does it also fail when `frame-resize-pixelwise' is set to t in your >> initial file? > > Yes, it does. That's bad. It can only mean that we send an integral resize request _before_ Emacs reads the initial file and the subsequent "real" resize request fails because the size hints have been already set up wrongly. >> Does it fail when you set `frame-resize-pixelwise' to t, request an >> integral resize first and a second non-integral one afterwards? > > I'm not sure I fully understand how you define "integral". See above. Also the "first and a second" above was meant to do this in two consecutive commands (that is, with a redisplay in between). Passing different size requests in one and the same command can have unpredictable consequences (at least on other platforms). > In short, > non-full-screen resize + redisplay + full-screen resize works, the > other combinations do not. > > If I run this code (Xnest running on display :3): > > DISPLAY=:3 emacs -Q --eval "(progn (setq frame-resize-pixelwise t) > (set-frame-height (selected-frame) (1+ (frame-pixel-height > (selected-frame))) nil t) (redisplay) (set-frame-parameter > (selected-frame) 'fullscreen 'fullboth))" > > Things work, but without the "(redisplay)" they don't. (So that's a > non-full-screen resize first, then a full-screen resize). Doing the > full-screen resize first breaks things. "Breaks" in what sense? That it does nothing or not fully resize? > I must also point out that without the "(redisplay)", there are > unexpected results: the full screen resize appears to be ignored > entirely. I'd have expected that. > But, again, I currently stand by my initial analysis of what's > happening. The problem is that we cannot simply do the right thing > because of the KWin bug... What is the "KWin bug"? I'm probably too silly to give you a good advice. However, in xg_frame_set_char_size (which is responsible for the resize in the GTK case) we could do the x_wm_set_size_hint (f, 0, 0); _before_ calling gtk_window_resize. Could you play around with that? BTW if you set `frame-size-history' to a non-nil value you should get a list of frame resizing operations you can watch with the function `frame--size-history'. IIRC I found GDB occasionally not 100% reliable to reproduce the actual history as of a normal, optimized build. martin ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#21317: 25.0.50; frame-resize-pixelwise has no effect (GTK, no window manager) 2015-08-22 14:16 ` martin rudalics @ 2015-08-22 15:32 ` Pip Cet 2015-08-22 17:46 ` martin rudalics 0 siblings, 1 reply; 19+ messages in thread From: Pip Cet @ 2015-08-22 15:32 UTC (permalink / raw) To: martin rudalics; +Cc: 21317 [-- Attachment #1: Type: text/plain, Size: 8017 bytes --] Let me just repeat my initial analysis, which I still believe is correct and which might have gotten lost somewhere. There are two problems: (1) x_check_fullscreen (xterm.c) calls XResizeWindow without first calling x_wm_set_size_hint (gtkutil.c), which would propagate the `frame-resize-pixelwise' flag to have an effect on GTK/GDK (2) x_wm_set_size_hint returns without propagating the `frame-resize-pixelwise' flag when the frame's fullscreen property is 'maximized or 'fullboth. The first appears to be simple oversight, but the second is intentional to work around a KWin bug. I've attached a patch which fixes things for me (at least when tool-bar-mode is disabled :( ), but presumably breaks things for KWin users, so it should not go in as it is until that matter has been cleared; maybe that'll help clarify matters. I take it something about that doesn't feel right to you, and that's reason enough to investigate further. On Sat, Aug 22, 2015 at 2:16 PM, martin rudalics <rudalics@gmx.at> wrote: >> On Sat, Aug 22, 2015 at 6:40 AM, martin rudalics <rudalics@gmx.at> wrote: >>>> When starting Emacs (GTK build) on an X server which has no window >>>> manager (such as a newly-created Xnest session), setting >>>> `frame-resize-pixelwise' to t followed by a resize operation often has >>>> no effect. >>> >>> According to the manual >>> >>> Setting this variable usually causes the next resize operation to >>> pass the corresponding size hints to the window manager. This >>> means that this variable should be set only in a user's initial >>> file; applications should never bind it temporarily. >> >> That documentation is outdated and does not apply to GTK builds in all >> cases, I'm afraid. It is not the window manager that decides to honor >> or dishonor frame-resize-pixelwise but GDK. > > "Window manager" was an attempt to catch the behavior of all toolkits > including Windows which doesn't have a window manager either. Feel free > to suggest a better term. Oh, I see! That makes sense, thank you and sorry for my narrow-mindedness in thinking only of X11 window managers. >> See x_wm_set_size_hint and >> gtk_window_move_resize (gtkwindow.c, in the GTK sources). In >> particular, gtk_window_compute_configure_request calls >> gtk_window_constrain_size which calls gdk_window_constrain_size which >> calculates >> >> width = base_width + FLOOR (width - base_width, xinc); >> height = base_height + FLOOR (height - base_height, yinc); >> >> (where FLOOR is defined as #define FLOOR(value, base) ( ((gint) >> ((value) / (base))) * (base) ) ) > > I can't find that in the version from > > https://github.com/GNOME/gtk/blob/master/gtk/gtkwindow.c Try https://github.com/GNOME/gtk/blob/master/gdk/gdkwindow.c ? > and also must admit that I have forgotten most of the GTK code by now. > > IIRC base_width and base_height are somehow calculated from a minimum > size and what Emacs requested earlier. If frame_resize_pixelwise is > true we _should_ have requested 1 from this > > size_hints.width_inc = frame_resize_pixelwise ? 1 : FRAME_COLUMN_WIDTH > (f); > size_hints.height_inc = frame_resize_pixelwise ? 1 : FRAME_LINE_HEIGHT > (f); We do hit that code (in gtkutil.c) twice: once during early initialization, when frame_resize_pixelwise is still false, and once after GDK has decided to resize us to not-quite-full-screen size, when it's too late. We should hit it once more, from x_check_fullscreen, but don't do so for the two reasons listed above. > Can you check how apparently an "integral" (the increment is a multiple > of either FRAME_COLUMN_WIDTH or FRAME_LINE_HEIGHT) value gets passed via > size_hints in your case? Oh, I see what you mean now. I'll investigate that next. >>> So it's possible that Xnest or some other X component refuses to resize >>> your frame because the size hints were set up inappropriately. >> >> I'm pretty sure that's not what's happening, but I'll be happy to >> provide traces to demonstrate my analysis is correct...or to prove it >> wrong, of course! The attached gdb log shows quite clearly that it's >> GDK making the second (erroneous) call to XResizeWindow, not Xnest >> (there is no window manager). > > OK. I won't doubt what you say here. Feel free to, of course, though I understand sifting through gdb logs is best avoided unless it's absolutely necessary. >>> Does it also fail when `frame-resize-pixelwise' is set to t in your >>> initial file? >> >> Yes, it does. > > That's bad. It can only mean that we send an integral resize request > _before_ Emacs reads the initial file and the subsequent "real" resize > request fails because the size hints have been already set up wrongly. No, we call Fsetq and so on fine, I think it's just that we never call x_set_wm_size_hints afterwards. >>> Does it fail when you set `frame-resize-pixelwise' to t, request an >>> integral resize first and a second non-integral one afterwards? >> >> I'm not sure I fully understand how you define "integral". > > See above. Also the "first and a second" above was meant to do this in > two consecutive commands (that is, with a redisplay in between). > Passing different size requests in one and the same command can have > unpredictable consequences (at least on other platforms). Noted. Thanks for that piece of advice, that really helps me make sense of what's going on. >> In short, >> non-full-screen resize + redisplay + full-screen resize works, the >> other combinations do not. >> >> If I run this code (Xnest running on display :3): >> >> DISPLAY=:3 emacs -Q --eval "(progn (setq frame-resize-pixelwise t) >> (set-frame-height (selected-frame) (1+ (frame-pixel-height >> (selected-frame))) nil t) (redisplay) (set-frame-parameter >> (selected-frame) 'fullscreen 'fullboth))" >> >> Things work, but without the "(redisplay)" they don't. (So that's a >> non-full-screen resize first, then a full-screen resize). Doing the >> full-screen resize first breaks things. > > "Breaks" in what sense? That it does nothing or not fully resize? It appears to ignore the fullscreen resize; as you point out, that's as expected, by the "don't resize twice without a redisplay" rule. >> I must also point out that without the "(redisplay)", there are >> unexpected results: the full screen resize appears to be ignored >> entirely. > > I'd have expected that. Good, that's one less thing to worry about then. >> But, again, I currently stand by my initial analysis of what's >> happening. The problem is that we cannot simply do the right thing >> because of the KWin bug... > > What is the "KWin bug"? http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14627, which introduced the conditional which prevents us from calling x_wm_size_hints > I'm probably too silly to give you a good advice. Not at all, it's much appreciated. > However, in > xg_frame_set_char_size (which is responsible for the resize in the GTK > case) we could do the That's a very interesting point, because xg_frame_set_char_size never appears to get called here after early initialization. Instead, we call XResizeWindow directly, then GDK catches the ConfigureNotify and decides it doesn't like it, so it sends another (erroneous) XResizeWindow. > x_wm_set_size_hint (f, 0, 0); > > _before_ calling gtk_window_resize. Could you play around with that? > > BTW if you set `frame-size-history' to a non-nil value you should get a > list of frame resizing operations you can watch with the function > `frame--size-history'. IIRC I found GDB occasionally not 100% reliable > to reproduce the actual history as of a normal, optimized build. Thanks, I never considered that possibility. I'm running an unoptimized debug build (-O0 -g3), but there might be useful information there. So far it appears not to contain anything unexpected (I'm looking at the variable directly, the function appears to have mysteriously vanished from the current git tree, except for a reference in the documentation...) Thanks for all your help! [-- Attachment #2: emacs-bug-008.diff --] [-- Type: text/plain, Size: 1762 bytes --] From 1f3f68b2a6da4c9d0b54f18b0bcc6c4dd2b243ad Mon Sep 17 00:00:00 2001 From: Philip <pipcet@gmail.com> Date: Sat, 22 Aug 2015 14:59:10 +0000 Subject: [PATCH] Do not apply this patch. See http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14627 --- src/gtkutil.c | 11 ----------- src/xterm.c | 2 ++ 2 files changed, 2 insertions(+), 11 deletions(-) diff --git a/src/gtkutil.c b/src/gtkutil.c index d684cd9..bdbfb0d 100644 --- a/src/gtkutil.c +++ b/src/gtkutil.c @@ -1364,7 +1364,6 @@ x_wm_set_size_hint (struct frame *f, long int flags, bool user_position) int base_width, base_height; int min_rows = 0, min_cols = 0; int win_gravity = f->win_gravity; - Lisp_Object fs_state, frame; int scale = xg_get_gdk_scale (); /* Don't set size hints during initialization; that apparently leads @@ -1373,16 +1372,6 @@ x_wm_set_size_hint (struct frame *f, long int flags, bool user_position) if (NILP (Vafter_init_time) || !FRAME_GTK_OUTER_WIDGET (f)) return; - XSETFRAME (frame, f); - fs_state = Fframe_parameter (frame, Qfullscreen); - if (EQ (fs_state, Qmaximized) || EQ (fs_state, Qfullboth)) - { - /* Don't set hints when maximized or fullscreen. Apparently KWin and - Gtk3 don't get along and the frame shrinks (!). - */ - return; - } - if (flags) { memset (&size_hints, 0, sizeof (size_hints)); diff --git a/src/xterm.c b/src/xterm.c index b7aacfa..0fd2464 100644 --- a/src/xterm.c +++ b/src/xterm.c @@ -10189,6 +10189,8 @@ x_check_fullscreen (struct frame *f) frame_size_history_add (f, Qx_check_fullscreen, width, height, Qnil); + x_wm_set_size_hint (f, 0, false); + XResizeWindow (FRAME_X_DISPLAY (f), FRAME_OUTER_WINDOW (f), width, height); -- 2.5.0 ^ permalink raw reply related [flat|nested] 19+ messages in thread
* bug#21317: 25.0.50; frame-resize-pixelwise has no effect (GTK, no window manager) 2015-08-22 15:32 ` Pip Cet @ 2015-08-22 17:46 ` martin rudalics 2015-08-23 9:45 ` Pip Cet 0 siblings, 1 reply; 19+ messages in thread From: martin rudalics @ 2015-08-22 17:46 UTC (permalink / raw) To: Pip Cet; +Cc: 21317 > Let me just repeat my initial analysis, which I still believe is > correct and which might have gotten lost somewhere. > > There are two problems: > (1) x_check_fullscreen (xterm.c) calls XResizeWindow without first > calling x_wm_set_size_hint (gtkutil.c), which would propagate the > `frame-resize-pixelwise' flag to have an effect on GTK/GDK I understand that now. You don't run do_ewmh_fullscreen. So the bug _only_ occurs when you want to make a fullscreen frame? This was not clear from you initial report. > (2) x_wm_set_size_hint returns without propagating the > `frame-resize-pixelwise' flag when the frame's fullscreen property is > 'maximized or 'fullboth. > > The first appears to be simple oversight, but the second is > intentional to work around a KWin bug. I faintly remember that bug now. What I don't understand is the remedy. When we do fs_state = Fframe_parameter (frame, Qfullscreen); if (EQ (fs_state, Qmaximized) || EQ (fs_state, Qfullboth)) the parameter has been already set but the frame is not yet fullscreen. Does this shrinking occur when the frame is already fullscreen or does it occur when a user wants to switch to fullscreen? > I've attached a patch which fixes things for me (at least when > tool-bar-mode is disabled :( ), but presumably breaks things for KWin > users, so it should not go in as it is until that matter has been > cleared; maybe that'll help clarify matters. When worse comes to worse we could condition that somehow: Invent an option which is off by default and call x_wm_set_size_hint when it's on. > We do hit that code (in gtkutil.c) twice: once during early > initialization, when frame_resize_pixelwise is still false, and once > after GDK has decided to resize us to not-quite-full-screen size, when > it's too late. We should hit it once more, from x_check_fullscreen, > but don't do so for the two reasons listed above. I see. If in frame.c you initialize frame_resize_pixelwise to 1 then everything works OK? >> Can you check how apparently an "integral" (the increment is a multiple >> of either FRAME_COLUMN_WIDTH or FRAME_LINE_HEIGHT) value gets passed via >> size_hints in your case? > > Oh, I see what you mean now. I'll investigate that next. Not necessary. It won't help anyway. >>>> So it's possible that Xnest or some other X component refuses to resize >>>> your frame because the size hints were set up inappropriately. >>> >>> I'm pretty sure that's not what's happening, but I'll be happy to >>> provide traces to demonstrate my analysis is correct...or to prove it >>> wrong, of course! The attached gdb log shows quite clearly that it's >>> GDK making the second (erroneous) call to XResizeWindow, not Xnest >>> (there is no window manager). >> >> OK. I won't doubt what you say here. > > Feel free to, of course, though I understand sifting through gdb logs > is best avoided unless it's absolutely necessary. Well... I didn't understand the problem at that time. >>>> Does it also fail when `frame-resize-pixelwise' is set to t in your >>>> initial file? >>> >>> Yes, it does. >> >> That's bad. It can only mean that we send an integral resize request >> _before_ Emacs reads the initial file and the subsequent "real" resize >> request fails because the size hints have been already set up wrongly. > > No, we call Fsetq and so on fine, I think it's just that we never call > x_set_wm_size_hints afterwards. We could invent a function `set-frame-resize-pixelwise' which sends the size hints (maybe iff when a frame is not fullscreen, or so to avoid the KWin bug). > It appears to ignore the fullscreen resize; as you point out, that's > as expected, by the "don't resize twice without a redisplay" rule. It's rather a don't resize and change the fullscreen status without a redisplay. >> However, in >> xg_frame_set_char_size (which is responsible for the resize in the GTK >> case) we could do the > > That's a very interesting point, because xg_frame_set_char_size never > appears to get called here after early initialization. Instead, we > call XResizeWindow directly, then GDK catches the ConfigureNotify and > decides it doesn't like it, so it sends another (erroneous) > XResizeWindow. Interesting indeed. Something's not right here, I'm afraid. I'll have to look into this. martin ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#21317: 25.0.50; frame-resize-pixelwise has no effect (GTK, no window manager) 2015-08-22 17:46 ` martin rudalics @ 2015-08-23 9:45 ` Pip Cet 2015-08-23 11:12 ` martin rudalics 0 siblings, 1 reply; 19+ messages in thread From: Pip Cet @ 2015-08-23 9:45 UTC (permalink / raw) To: martin rudalics; +Cc: 21317 [-- Attachment #1: Type: text/plain, Size: 6113 bytes --] Sorry this is getting a bit long, but unfortunately, another issue appeared. On Sat, Aug 22, 2015 at 5:46 PM, martin rudalics <rudalics@gmx.at> wrote: > I understand that now. You don't run do_ewmh_fullscreen. So the bug > _only_ occurs when you want to make a fullscreen frame? This was not > clear from you initial report. Sorry about that. You're right, I've only seen the problem when I make a fullscreen frame. That wasn't perfectly clear to me at the time, but I should have tested better. Thank you for your patience. >> (2) x_wm_set_size_hint returns without propagating the >> `frame-resize-pixelwise' flag when the frame's fullscreen property is >> 'maximized or 'fullboth. >> >> The first appears to be simple oversight, but the second is >> intentional to work around a KWin bug. > > I faintly remember that bug now. What I don't understand is the remedy. > When we do > > fs_state = Fframe_parameter (frame, Qfullscreen); > if (EQ (fs_state, Qmaximized) || EQ (fs_state, Qfullboth)) > > the parameter has been already set but the frame is not yet fullscreen. > Does this shrinking occur when the frame is already fullscreen or does > it occur when a user wants to switch to fullscreen? I'm not a hundred percent certain; from reading the thread, I think it's the former: the window is in full-screen mode and starts shrinking. I've installed KWin but have been unable to produce buggy behavior, so far, without the workaround in gtkutil.c. >> I've attached a patch which fixes things for me (at least when >> tool-bar-mode is disabled :( ), but presumably breaks things for KWin >> users, so it should not go in as it is until that matter has been >> cleared; maybe that'll help clarify matters. > > When worse comes to worse we could condition that somehow: Invent an > option which is off by default and call x_wm_set_size_hint when it's on. I do wonder how useful it is to support the case without a window manager; unfortunately, I think it is useful, much as I'd enjoy all that code going away and leaving things to the window manager. Anyway, if x_check_fullscreen is supposed to work the way it currently does, bypassing xg_frame_set_char_size, there's a third issue to add to my list: (3) x_check_fullscreen does not call store_frame_param, unlike x_set_window_size_1, so the frame has its 'fullscreen parameter cleared to nil by x_net_wm_state; the next `set-frame-font' call then results in an integral frame size rather than the full screen. If my understanding is correct, the best way forward is this: - skip the hints in maximized/fullscreen state if wm_supports(net_wm_state) || wm_supports(net_wm_state_fullscreen), it might be KWin - otherwise, set the hints - call x_wm_set_size_hint from x_check_fullscreen - call store_frame_param from x_check_fullscreen >> We do hit that code (in gtkutil.c) twice: once during early >> initialization, when frame_resize_pixelwise is still false, and once >> after GDK has decided to resize us to not-quite-full-screen size, when >> it's too late. We should hit it once more, from x_check_fullscreen, >> but don't do so for the two reasons listed above. > > I see. If in frame.c you initialize frame_resize_pixelwise to 1 then > everything works OK? ...Almost. Sorry. If I set frame_resize_pixelwise to 1 and run `set-frame-font' afterwards, the frame loses its full-screen resolution and changes to a similar resolution that's a multiple of the character size, as far as I can tell. This is due to issue (3), I believe. Similarly, we don't adjust for the tool bar size, which I also believe is due to issue (3) (I keep forgetting about that one since I don't usually use the tool bar). I have attached the minimal patch (as far as I know) that works: initialize frame_resize_pixelwise to 1, and fix issue (3). That works both with a tool bar and with `set-frame-font' (I'm not in the habit of running `set-frame-font', but it's run by the gconf code when gnome-settings-daemon is active and specifies a system font). >>>>> Does it also fail when `frame-resize-pixelwise' is set to t in your >>>>> initial file? >>>> >>>> Yes, it does. >>> >>> That's bad. It can only mean that we send an integral resize request >>> _before_ Emacs reads the initial file and the subsequent "real" resize >>> request fails because the size hints have been already set up wrongly. >> >> No, we call Fsetq and so on fine, I think it's just that we never call >> x_set_wm_size_hints afterwards. > > We could invent a function `set-frame-resize-pixelwise' which sends the > size hints (maybe iff when a frame is not fullscreen, or so to avoid the > KWin bug). How would that be different from x_wm_set_size_hints with FLAGS=0? I suppose we could modify only the increments and leave the rest of the size hints alone, but is that enough to prevent bad KWin behavior? >> It appears to ignore the fullscreen resize; as you point out, that's >> as expected, by the "don't resize twice without a redisplay" rule. > > It's rather a don't resize and change the fullscreen status without a > redisplay. Ah. Well, that doesn't really make sense anyway, so it's probably a good rule :-) >>> However, in >>> xg_frame_set_char_size (which is responsible for the resize in the GTK >>> case) we could do the >> >> That's a very interesting point, because xg_frame_set_char_size never >> appears to get called here after early initialization. Instead, we >> call XResizeWindow directly, then GDK catches the ConfigureNotify and >> decides it doesn't like it, so it sends another (erroneous) >> XResizeWindow. > Interesting indeed. Something's not right here, I'm afraid. I'll have > to look into this. It seems like the code in x_check_fullscreen was intended to work without a window manager (and without calling xg_frame_set_char_size), but never did. It didn't call x_wm_set_size_hints and it didn't clean up after x_net_wm_state by setting the 'fullscreen property again. Thank you for your assistance in this, it's very much appreciated. If you would like me to run more tests or provide debugging info, please let me know, I'll do my best. [-- Attachment #2: emacs-bug-009.diff --] [-- Type: text/plain, Size: 1671 bytes --] diff --git a/src/frame.c b/src/frame.c index 2044048..cac966d 100644 --- a/src/frame.c +++ b/src/frame.c @@ -5161,7 +5161,7 @@ With some window managers you may have to set this to non-nil in order to set the size of a frame in pixels, to maximize frames or to make them fullscreen. To resize your initial frame pixelwise, set this option to a non-nil value in your init file. */); - frame_resize_pixelwise = 0; + frame_resize_pixelwise = 1; DEFVAR_LISP ("frame-inhibit-implied-resize", frame_inhibit_implied_resize, doc: /* Whether frames should be resized implicitly. diff --git a/src/xterm.c b/src/xterm.c index b7aacfa..4c7aec4 100644 --- a/src/xterm.c +++ b/src/xterm.c @@ -10169,6 +10169,7 @@ x_check_fullscreen (struct frame *f) { int width = FRAME_PIXEL_WIDTH (f), height = FRAME_PIXEL_HEIGHT (f); struct x_display_info *dpyinfo = FRAME_DISPLAY_INFO (f); + Lisp_Object lval; switch (f->want_fullscreen) { @@ -10186,6 +10187,23 @@ x_check_fullscreen (struct frame *f) height = x_display_pixel_height (dpyinfo); } + lval = Qnil; + switch (f->want_fullscreen) + { + case FULLSCREEN_WIDTH: + lval = Qfullwidth; + break; + case FULLSCREEN_HEIGHT: + lval = Qfullheight; + break; + case FULLSCREEN_BOTH: + lval = Qfullboth; + break; + case FULLSCREEN_MAXIMIZED: + lval = Qmaximized; + break; + } + frame_size_history_add (f, Qx_check_fullscreen, width, height, Qnil); @@ -10200,6 +10218,8 @@ x_check_fullscreen (struct frame *f) false, true, false, true); x_sync (f); } + + store_frame_param (f, Qfullscreen, lval); } } ^ permalink raw reply related [flat|nested] 19+ messages in thread
* bug#21317: 25.0.50; frame-resize-pixelwise has no effect (GTK, no window manager) 2015-08-23 9:45 ` Pip Cet @ 2015-08-23 11:12 ` martin rudalics 2015-08-23 12:20 ` Pip Cet 0 siblings, 1 reply; 19+ messages in thread From: martin rudalics @ 2015-08-23 11:12 UTC (permalink / raw) To: Pip Cet; +Cc: 21317 [-- Attachment #1: Type: text/plain, Size: 6748 bytes --] > Sorry about that. You're right, I've only seen the problem when I make > a fullscreen frame. That wasn't perfectly clear to me at the time, but > I should have tested better. Thank you for your patience. It's not immediately clear that the problem happens only with attempts to make a fullscreen frame which, to be clear again, could mean any of maximized, fullheight, fullwidth and fullboth. So when you try to increase the height of a normal frame by one pixel, which is the resize operation you send? I suppose it's the last one from x_set_window_size_1 so Emacs correctly passes the size hint with frame_resize_pixelwise 1. Right? If this is the case, then Emacs should, for you, also handle fullwidth and fullheight requests correctly via the first and second of the requests in x_set_window_size_1. Right? So the two remaining cases Emacs can't handle for you are fullscreen and maximized requests. Right? >> I faintly remember that bug now. Rereading the corresponding thread I wonder how my memory could fail so miserably. > What I don't understand is the remedy. >> When we do >> >> fs_state = Fframe_parameter (frame, Qfullscreen); >> if (EQ (fs_state, Qmaximized) || EQ (fs_state, Qfullboth)) >> >> the parameter has been already set but the frame is not yet fullscreen. >> Does this shrinking occur when the frame is already fullscreen or does >> it occur when a user wants to switch to fullscreen? > > I'm not a hundred percent certain; from reading the thread, I think > it's the former: the window is in full-screen mode and starts > shrinking. I've installed KWin but have been unable to produce buggy > behavior, so far, without the workaround in gtkutil.c. I attach a patch that should handle the case where we want to switch from a non-fullscreen to a fullscreen frame. Please try it. FRAME_OUTER_WINDOW (f) should probably be replaced by some GTK-specific window but I don't yet know which one. >> When worse comes to worse we could condition that somehow: Invent an >> option which is off by default and call x_wm_set_size_hint when it's on. > > I do wonder how useful it is to support the case without a window > manager; unfortunately, I think it is useful, much as I'd enjoy all > that code going away and leaving things to the window manager. I miss you here: Which "case" do you mean? > Anyway, if x_check_fullscreen is supposed to work the way it currently > does, bypassing xg_frame_set_char_size, there's a third issue to add > to my list: > > (3) x_check_fullscreen does not call store_frame_param, unlike > x_set_window_size_1, so the frame has its 'fullscreen parameter > cleared to nil by x_net_wm_state; the next `set-frame-font' call then > results in an integral frame size rather than the full screen. Correct me if I'm wrong: We run x_check_fullscreen only when the window manager doesn't support fullscreen natively. WOW when we run x_check_fullscreen, we emulate the behavior of a window manager by calculating the respective sizes ourselves. Now when Emacs sets the fullscreen frame parameter itself, this action basically covers only what we get from the window manager. A user who wanted a fullscreen frame would have set the according frame parameter already. What am I missing? > If my understanding is correct, the best way forward is this: > > - skip the hints in maximized/fullscreen state if > wm_supports(net_wm_state) || wm_supports(net_wm_state_fullscreen), it > might be KWin > - otherwise, set the hints OK. These can be done easily, maybe in combination with my patch. > - call x_wm_set_size_hint from x_check_fullscreen OK. Funnily we call a function x_wm_set_size_hint to handle a scenario where there's no window manager. > - call store_frame_param from x_check_fullscreen It might not harm but, as mentioned above, this should not be necessary. Or, if it is necessary because the parameters are not in place yet, the bug seems to be elsewhere, >> I see. If in frame.c you initialize frame_resize_pixelwise to 1 then >> everything works OK? > > ...Almost. Sorry. If I set frame_resize_pixelwise to 1 and run > `set-frame-font' afterwards, Hmm.. so you insist. Can you tell me why `set-frame-font' can change a fullscreen frame's size? > the frame loses its full-screen > resolution and changes to a similar resolution that's a multiple of > the character size, as far as I can tell. This is due to issue (3), I > believe. Similarly, we don't adjust for the tool bar size, which I > also believe is due to issue (3) (I keep forgetting about that one > since I don't usually use the tool bar). Let's look into the toolbar issue later. What we have to check first is: (1) You have a "correctly" maximized frame and `frame-resize-pixelwise' is non-nil. What is the frame's fullscreen parameter's value? (2) If that value is non-nil, how comes `set-frame-font' can change the frame size? > I have attached the minimal patch (as far as I know) that works: > initialize frame_resize_pixelwise to 1, We can't do that. I mentioned that only so you can check whether it would work in principle. > and fix issue (3). That works > both with a tool bar and with `set-frame-font' (I'm not in the habit > of running `set-frame-font', but it's run by the gconf code when > gnome-settings-daemon is active and specifies a system font). OK. >> We could invent a function `set-frame-resize-pixelwise' which sends the >> size hints (maybe iff when a frame is not fullscreen, or so to avoid the >> KWin bug). > > How would that be different from x_wm_set_size_hints with FLAGS=0? It would modify the increments accordingly. That is `set-frame-resize-pixelwise' with a non-nil ARG would set the increments to 1 and with a nil ARG it would set them to the frame's column and line heights. > I > suppose we could modify only the increments and leave the rest of the > size hints alone, but is that enough to prevent bad KWin behavior? You mean calling `set-frame-resize-pixelwise' in a fullscreen state on KWin would produce the bug again. You're probably right. So this won't help much. > It seems like the code in x_check_fullscreen was intended to work > without a window manager (and without calling xg_frame_set_char_size), ... that's my impression too ... > but never did. It didn't call x_wm_set_size_hints and it didn't clean > up after x_net_wm_state by setting the 'fullscreen property again. Do I understand finally? x_net_wm_state resets the fullscreen state to nil via its store_frame_param? That would be the missing link then. But then there's no use to set the fullscreen parameter earlier. x_net_wm_state would annihilate that anyway. martin [-- Attachment #2: x_wm_size_hint.diff --] [-- Type: text/plain, Size: 2271 bytes --] --- a/src/gtkutil.c +++ b/src/gtkutil.c @@ -135,6 +135,8 @@ along with GNU Emacs. If not, see <http://www.gnu.org/licenses/>. */ static void update_theme_scrollbar_width (void); static void update_theme_scrollbar_height (void); +bool get_current_wm_state (struct frame *, Window, int *, bool *); + #define TB_INFO_KEY "xg_frame_tb_info" struct xg_frame_tb_info { @@ -1364,7 +1366,8 @@ x_wm_set_size_hint (struct frame *f, long int flags, bool user_position) int base_width, base_height; int min_rows = 0, min_cols = 0; int win_gravity = f->win_gravity; - Lisp_Object fs_state, frame; + int state = FULLSCREEN_NONE; + bool sticky = false; int scale = xg_get_gdk_scale (); /* Don't set size hints during initialization; that apparently leads @@ -1373,13 +1376,12 @@ x_wm_set_size_hint (struct frame *f, long int flags, bool user_position) if (NILP (Vafter_init_time) || !FRAME_GTK_OUTER_WIDGET (f)) return; - XSETFRAME (frame, f); - fs_state = Fframe_parameter (frame, Qfullscreen); - if (EQ (fs_state, Qmaximized) || EQ (fs_state, Qfullboth)) + get_current_wm_state (f, FRAME_OUTER_WINDOW (f), &state, &sticky); + if (state != FULLSCREEN_NONE) { - /* Don't set hints when maximized or fullscreen. Apparently KWin and - Gtk3 don't get along and the frame shrinks (!). - */ + /* Don't set hints when the frame currently is maximized or + fullscreen. Apparently KWin and Gtk3 don't get along and the + frame shrinks (!). */ return; } diff --git a/src/xterm.c b/src/xterm.c index b7aacfa..2e1c0b5 100644 --- a/src/xterm.c +++ b/src/xterm.c @@ -247,7 +247,7 @@ static void x_wm_set_window_state (struct frame *, int); static void x_wm_set_icon_pixmap (struct frame *, ptrdiff_t); static void x_initialize (void); -static bool get_current_wm_state (struct frame *, Window, int *, bool *); +bool get_current_wm_state (struct frame *, Window, int *, bool *); /* Flush display of frame F. */ @@ -9904,7 +9904,7 @@ x_set_sticky (struct frame *f, Lisp_Object new_value, Lisp_Object old_value) Return true iff we are not hidden. */ -static bool +bool get_current_wm_state (struct frame *f, Window window, int *size_state, ^ permalink raw reply related [flat|nested] 19+ messages in thread
* bug#21317: 25.0.50; frame-resize-pixelwise has no effect (GTK, no window manager) 2015-08-23 11:12 ` martin rudalics @ 2015-08-23 12:20 ` Pip Cet 2015-08-23 12:29 ` Pip Cet 2015-08-23 13:10 ` martin rudalics 0 siblings, 2 replies; 19+ messages in thread From: Pip Cet @ 2015-08-23 12:20 UTC (permalink / raw) To: martin rudalics; +Cc: 21317 Let me answer that email bottom-to-top, I think it makes most sense that way: On Sun, Aug 23, 2015 at 11:12 AM, martin rudalics <rudalics@gmx.at> wrote: >> but never did. It didn't call x_wm_set_size_hints and it didn't clean >> up after x_net_wm_state by setting the 'fullscreen property again. > > Do I understand finally? x_net_wm_state resets the fullscreen state to > nil via its store_frame_param? That would be the missing link then. Indeed. (Minor point of confusion here: there are two functions called `x_net_wm_state' and `x_handle_net_wm_state' which appear to do the same thing...) > But then there's no use to set the fullscreen parameter earlier. > x_net_wm_state would annihilate that anyway. I think you're right for X, but other toolkits might need the generic code that sets it earlier. >> Sorry about that. You're right, I've only seen the problem when I make >> a fullscreen frame. That wasn't perfectly clear to me at the time, but >> I should have tested better. Thank you for your patience. > > It's not immediately clear that the problem happens only with attempts > to make a fullscreen frame which, to be clear again, could mean any of > maximized, fullheight, fullwidth and fullboth. The problem appears with all of maximized, fullheight, fullwidth, and fullboth. > So when you try to increase the height of a normal frame by one pixel, > which is the resize operation you send? set_frame_height calls adjust_frame_size which calls x_set_window_size which calls xg_frame_set_char_size. x_set_window_size_1 is NOT being called in this case. > I suppose it's the last one > from x_set_window_size_1 so Emacs correctly passes the size hint with > frame_resize_pixelwise 1. Right? No, x_set_window_size_1 never is called here. It's the last case in xg_frame_set_char_size, which calls gtk_window_resize FIRST, then calls x_wm_set_size_hints. I do not understand why that works, but it appears to. (Is this another bug? I'm seriously confused at this point). > If this is the case, then Emacs should, for you, also handle fullwidth > and fullheight requests correctly via the first and second of the > requests in x_set_window_size_1. Right? No. x_set_window_size_1 isn't called at all. xg_frame_set_char_size isn't called for fullscreen requests at all. > So the two remaining cases Emacs can't handle for you are fullscreen and > maximized requests. Right? No, it's all four fullscreen settings. >> What I don't understand is the remedy. >>> When we do >>> >>> fs_state = Fframe_parameter (frame, Qfullscreen); >>> if (EQ (fs_state, Qmaximized) || EQ (fs_state, Qfullboth)) >>> >>> the parameter has been already set but the frame is not yet fullscreen. >>> Does this shrinking occur when the frame is already fullscreen or does >>> it occur when a user wants to switch to fullscreen? >> >> I'm not a hundred percent certain; from reading the thread, I think >> it's the former: the window is in full-screen mode and starts >> shrinking. I've installed KWin but have been unable to produce buggy >> behavior, so far, without the workaround in gtkutil.c. > > I attach a patch that should handle the case where we want to switch > from a non-fullscreen to a fullscreen frame. Please try it. Th > FRAME_OUTER_WINDOW (f) should probably be replaced by some GTK-specific > window but I don't yet know which one. > >>> When worse comes to worse we could condition that somehow: Invent an >>> option which is off by default and call x_wm_set_size_hint when it's on. >> >> I do wonder how useful it is to support the case without a window >> manager; unfortunately, I think it is useful, much as I'd enjoy all >> that code going away and leaving things to the window manager. > > I miss you here: Which "case" do you mean? I was considering whether it might be best to remove the no-window-manager code entirely, but I don't think we should. >> Anyway, if x_check_fullscreen is supposed to work the way it currently >> does, bypassing xg_frame_set_char_size, there's a third issue to add >> to my list: >> >> (3) x_check_fullscreen does not call store_frame_param, unlike >> x_set_window_size_1, so the frame has its 'fullscreen parameter >> cleared to nil by x_net_wm_state; the next `set-frame-font' call then >> results in an integral frame size rather than the full screen. > > Correct me if I'm wrong: We run x_check_fullscreen only when the window > manager doesn't support fullscreen natively. Right. x_check_fullscreen exits very early unless the window manager fails to support fullscreen. > WOW when we run > x_check_fullscreen, we emulate the behavior of a window manager by > calculating the respective sizes ourselves. Correct. > Now when Emacs sets the fullscreen frame parameter itself, this action > basically covers only what we get from the window manager. A user who > wanted a fullscreen frame would have set the according frame parameter > already. What am I missing? I think it's that x_net_wm_state clears the fullscreen flag in the middle of our operation. >> If my understanding is correct, the best way forward is this: >> >> - skip the hints in maximized/fullscreen state if >> wm_supports(net_wm_state) || wm_supports(net_wm_state_fullscreen), it >> might be KWin >> - otherwise, set the hints > > OK. These can be done easily, maybe in combination with my patch. I think your patch actually solves that problem: if there's no WM, get_current_wm_state will always return FULLSCREEN_NONE, so we set the size hints appropriately. >> - call x_wm_set_size_hint from x_check_fullscreen > > OK. Funnily we call a function x_wm_set_size_hint to handle a scenario > where there's no window manager. > >> - call store_frame_param from x_check_fullscreen > > It might not harm but, as mentioned above, this should not be > necessary. Or, if it is necessary because the parameters are not in > place yet, the bug seems to be elsewhere, Again, I think it makes sense once you take into account x_net_wm_state. >>> I see. If in frame.c you initialize frame_resize_pixelwise to 1 then >>> everything works OK? >> >> ...Almost. Sorry. If I set frame_resize_pixelwise to 1 and run >> `set-frame-font' afterwards, > > Hmm.. so you insist. Can you tell me why `set-frame-font' can change a > fullscreen frame's size? Missing link :-) >> the frame loses its full-screen >> resolution and changes to a similar resolution that's a multiple of >> the character size, as far as I can tell. This is due to issue (3), I >> believe. Similarly, we don't adjust for the tool bar size, which I >> also believe is due to issue (3) (I keep forgetting about that one >> since I don't usually use the tool bar). > > Let's look into the toolbar issue later. What we have to check first > is: > > (1) You have a "correctly" maximized frame and `frame-resize-pixelwise' > is non-nil. What is the frame's fullscreen parameter's value? > > (2) If that value is non-nil, how comes `set-frame-font' can change the > frame size? > >> I have attached the minimal patch (as far as I know) that works: >> initialize frame_resize_pixelwise to 1, > > We can't do that. I mentioned that only so you can check whether it > would work in principle. Oh, I agree, but I was sufficiently confused I thought it important to be sure what needed changing before actually working out how to do it cleanly. >>> We could invent a function `set-frame-resize-pixelwise' which sends the >>> size hints (maybe iff when a frame is not fullscreen, or so to avoid the >>> KWin bug). >> >> How would that be different from x_wm_set_size_hints with FLAGS=0? > > It would modify the increments accordingly. That is > `set-frame-resize-pixelwise' with a non-nil ARG would set the increments > to 1 and with a nil ARG it would set them to the frame's column and line > heights. > >> I >> suppose we could modify only the increments and leave the rest of the >> size hints alone, but is that enough to prevent bad KWin behavior? > > You mean calling `set-frame-resize-pixelwise' in a fullscreen state on > KWin would produce the bug again. You're probably right. So this won't > help much. > > martin ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#21317: 25.0.50; frame-resize-pixelwise has no effect (GTK, no window manager) 2015-08-23 12:20 ` Pip Cet @ 2015-08-23 12:29 ` Pip Cet 2015-08-23 13:23 ` martin rudalics 2015-08-23 13:10 ` martin rudalics 1 sibling, 1 reply; 19+ messages in thread From: Pip Cet @ 2015-08-23 12:29 UTC (permalink / raw) To: martin rudalics; +Cc: 21317 [-- Attachment #1: Type: text/plain, Size: 809 bytes --] Sorry, I accidentally sent that email half-finished. On Sun, Aug 23, 2015 at 12:20 PM, Pip Cet <pipcet@gmail.com> wrote: >>> I'm not a hundred percent certain; from reading the thread, I think >>> it's the former: the window is in full-screen mode and starts >>> shrinking. I've installed KWin but have been unable to produce buggy >>> behavior, so far, without the workaround in gtkutil.c. >> >> I attach a patch that should handle the case where we want to switch >> from a non-fullscreen to a fullscreen frame. Please try it. That patch has no effect, but that's consistent with my understanding of the situation; it might have an effect on users of the buggy KWin version. I've attached a patch that combines your patch with the minor fixes I suggested in the previous email. It appears to work here. [-- Attachment #2: 0001-Fix-fullscreen-issue.patch --] [-- Type: text/x-patch, Size: 3735 bytes --] From af8d69d52190a98264cfc0ef9ceedcfbd2f0d37d Mon Sep 17 00:00:00 2001 From: Philip <pipcet@gmail.com> Date: Sun, 23 Aug 2015 12:24:04 +0000 Subject: [PATCH] Fix fullscreen issue --- src/gtkutil.c | 16 +++++++++------- src/xterm.c | 27 +++++++++++++++++++++++++-- 2 files changed, 34 insertions(+), 9 deletions(-) diff --git a/src/gtkutil.c b/src/gtkutil.c index d684cd9..8e53a16 100644 --- a/src/gtkutil.c +++ b/src/gtkutil.c @@ -135,6 +135,8 @@ along with GNU Emacs. If not, see <http://www.gnu.org/licenses/>. */ static void update_theme_scrollbar_width (void); static void update_theme_scrollbar_height (void); +bool get_current_wm_state (struct frame *, Window, int *, bool *); + #define TB_INFO_KEY "xg_frame_tb_info" struct xg_frame_tb_info { @@ -1364,7 +1366,8 @@ x_wm_set_size_hint (struct frame *f, long int flags, bool user_position) int base_width, base_height; int min_rows = 0, min_cols = 0; int win_gravity = f->win_gravity; - Lisp_Object fs_state, frame; + int state = FULLSCREEN_NONE; + bool sticky = false; int scale = xg_get_gdk_scale (); /* Don't set size hints during initialization; that apparently leads @@ -1373,13 +1376,12 @@ x_wm_set_size_hint (struct frame *f, long int flags, bool user_position) if (NILP (Vafter_init_time) || !FRAME_GTK_OUTER_WIDGET (f)) return; - XSETFRAME (frame, f); - fs_state = Fframe_parameter (frame, Qfullscreen); - if (EQ (fs_state, Qmaximized) || EQ (fs_state, Qfullboth)) + get_current_wm_state (f, FRAME_OUTER_WINDOW (f), &state, &sticky); + if (state != FULLSCREEN_NONE) { - /* Don't set hints when maximized or fullscreen. Apparently KWin and - Gtk3 don't get along and the frame shrinks (!). - */ + /* Don't set hints when the frame currently is maximized or + fullscreen. Apparently KWin and Gtk3 don't get along and the + frame shrinks (!). */ return; } diff --git a/src/xterm.c b/src/xterm.c index b7aacfa..60e72a9 100644 --- a/src/xterm.c +++ b/src/xterm.c @@ -247,7 +247,7 @@ static void x_wm_set_window_state (struct frame *, int); static void x_wm_set_icon_pixmap (struct frame *, ptrdiff_t); static void x_initialize (void); -static bool get_current_wm_state (struct frame *, Window, int *, bool *); +bool get_current_wm_state (struct frame *, Window, int *, bool *); /* Flush display of frame F. */ @@ -9904,7 +9904,7 @@ x_set_sticky (struct frame *f, Lisp_Object new_value, Lisp_Object old_value) Return true iff we are not hidden. */ -static bool +bool get_current_wm_state (struct frame *f, Window window, int *size_state, @@ -10155,6 +10155,8 @@ x_handle_net_wm_state (struct frame *f, const XPropertyEvent *event) static void x_check_fullscreen (struct frame *f) { + Lisp_Object lval; + if (do_ewmh_fullscreen (f)) return; @@ -10189,6 +10191,8 @@ x_check_fullscreen (struct frame *f) frame_size_history_add (f, Qx_check_fullscreen, width, height, Qnil); + x_wm_set_size_hint (f, 0, false); + XResizeWindow (FRAME_X_DISPLAY (f), FRAME_OUTER_WINDOW (f), width, height); @@ -10201,6 +10205,25 @@ x_check_fullscreen (struct frame *f) x_sync (f); } } + + lval = Qnil; + switch (f->want_fullscreen) + { + case FULLSCREEN_WIDTH: + lval = Qfullwidth; + break; + case FULLSCREEN_HEIGHT: + lval = Qfullheight; + break; + case FULLSCREEN_BOTH: + lval = Qfullboth; + break; + case FULLSCREEN_MAXIMIZED: + lval = Qmaximized; + break; + } + + store_frame_param (f, Qfullscreen, lval); } /* This function is called by x_set_offset to determine whether the window -- 2.5.0 ^ permalink raw reply related [flat|nested] 19+ messages in thread
* bug#21317: 25.0.50; frame-resize-pixelwise has no effect (GTK, no window manager) 2015-08-23 12:29 ` Pip Cet @ 2015-08-23 13:23 ` martin rudalics 2015-08-23 13:47 ` Pip Cet 0 siblings, 1 reply; 19+ messages in thread From: martin rudalics @ 2015-08-23 13:23 UTC (permalink / raw) To: Pip Cet; +Cc: 21317 > I've attached a patch that combines your patch with the minor fixes I > suggested in the previous email. It appears to work here. Thanks. This + lval = Qnil; + switch (f->want_fullscreen) + { + case FULLSCREEN_WIDTH: + lval = Qfullwidth; + break; + case FULLSCREEN_HEIGHT: + lval = Qfullheight; + break; + case FULLSCREEN_BOTH: + lval = Qfullboth; + break; + case FULLSCREEN_MAXIMIZED: + lval = Qmaximized; + break; + } looks a bit ugly. Can't we set lval in the switch above? If f->want_fullscreen changed in between we'd get in hot water anyway. (Also I'd like to keep the patch resonably small so I can install it as a "tiny change". Or do you have copyright papers signed for Emacs?) martin ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#21317: 25.0.50; frame-resize-pixelwise has no effect (GTK, no window manager) 2015-08-23 13:23 ` martin rudalics @ 2015-08-23 13:47 ` Pip Cet 2015-08-23 14:09 ` martin rudalics 0 siblings, 1 reply; 19+ messages in thread From: Pip Cet @ 2015-08-23 13:47 UTC (permalink / raw) To: martin rudalics; +Cc: 21317 [-- Attachment #1: Type: text/plain, Size: 1034 bytes --] On Sun, Aug 23, 2015 at 1:23 PM, martin rudalics <rudalics@gmx.at> wrote: >> I've attached a patch that combines your patch with the minor fixes I >> suggested in the previous email. It appears to work here. > > Thanks. This > > + lval = Qnil; > + switch (f->want_fullscreen) > + { > + case FULLSCREEN_WIDTH: > + lval = Qfullwidth; > + break; > + case FULLSCREEN_HEIGHT: > + lval = Qfullheight; > + break; > + case FULLSCREEN_BOTH: > + lval = Qfullboth; > + break; > + case FULLSCREEN_MAXIMIZED: > + lval = Qmaximized; > + break; > + } > > looks a bit ugly. Can't we set lval in the switch above? I agree. > If f->want_fullscreen changed in between we'd get in hot water anyway. > > (Also I'd like to keep the patch resonably small so I can install it as > a "tiny change". Or do you have copyright papers signed for Emacs?) (No, but soon, hopefully.) I've attached the patch with a suggested ChangeLog entry (though of course you should change it to your own name). [-- Attachment #2: 0001-Fix-full-screen-code-when-there-is-no-window-manager.patch --] [-- Type: text/x-patch, Size: 4582 bytes --] From 2d9a0eaf55ceca3c3bb93a508f115b4d9ee28a95 Mon Sep 17 00:00:00 2001 From: Philip <pipcet@gmail.com> Date: Sun, 23 Aug 2015 12:24:04 +0000 Subject: [PATCH] Fix full-screen code when there is no window manager. * xterm.c (get_current_wm_state): Export function. (x_check_fullscreen): Call `x_wm_set_size_hint', restore `fullscreen' frame parameter. * gtkutil.c (x_wm_set_size_hint): Set size hints when running without a window manager. --- src/gtkutil.c | 16 +++++++++------- src/xterm.c | 21 ++++++++++++++++++--- 2 files changed, 27 insertions(+), 10 deletions(-) diff --git a/src/gtkutil.c b/src/gtkutil.c index d684cd9..8e53a16 100644 --- a/src/gtkutil.c +++ b/src/gtkutil.c @@ -135,6 +135,8 @@ along with GNU Emacs. If not, see <http://www.gnu.org/licenses/>. */ static void update_theme_scrollbar_width (void); static void update_theme_scrollbar_height (void); +bool get_current_wm_state (struct frame *, Window, int *, bool *); + #define TB_INFO_KEY "xg_frame_tb_info" struct xg_frame_tb_info { @@ -1364,7 +1366,8 @@ x_wm_set_size_hint (struct frame *f, long int flags, bool user_position) int base_width, base_height; int min_rows = 0, min_cols = 0; int win_gravity = f->win_gravity; - Lisp_Object fs_state, frame; + int state = FULLSCREEN_NONE; + bool sticky = false; int scale = xg_get_gdk_scale (); /* Don't set size hints during initialization; that apparently leads @@ -1373,13 +1376,12 @@ x_wm_set_size_hint (struct frame *f, long int flags, bool user_position) if (NILP (Vafter_init_time) || !FRAME_GTK_OUTER_WIDGET (f)) return; - XSETFRAME (frame, f); - fs_state = Fframe_parameter (frame, Qfullscreen); - if (EQ (fs_state, Qmaximized) || EQ (fs_state, Qfullboth)) + get_current_wm_state (f, FRAME_OUTER_WINDOW (f), &state, &sticky); + if (state != FULLSCREEN_NONE) { - /* Don't set hints when maximized or fullscreen. Apparently KWin and - Gtk3 don't get along and the frame shrinks (!). - */ + /* Don't set hints when the frame currently is maximized or + fullscreen. Apparently KWin and Gtk3 don't get along and the + frame shrinks (!). */ return; } diff --git a/src/xterm.c b/src/xterm.c index b7aacfa..dcd457f 100644 --- a/src/xterm.c +++ b/src/xterm.c @@ -247,7 +247,7 @@ static void x_wm_set_window_state (struct frame *, int); static void x_wm_set_icon_pixmap (struct frame *, ptrdiff_t); static void x_initialize (void); -static bool get_current_wm_state (struct frame *, Window, int *, bool *); +bool get_current_wm_state (struct frame *, Window, int *, bool *); /* Flush display of frame F. */ @@ -9904,7 +9904,7 @@ x_set_sticky (struct frame *f, Lisp_Object new_value, Lisp_Object old_value) Return true iff we are not hidden. */ -static bool +bool get_current_wm_state (struct frame *f, Window window, int *size_state, @@ -10155,6 +10155,8 @@ x_handle_net_wm_state (struct frame *f, const XPropertyEvent *event) static void x_check_fullscreen (struct frame *f) { + Lisp_Object lval = Qnil; + if (do_ewmh_fullscreen (f)) return; @@ -10173,22 +10175,31 @@ x_check_fullscreen (struct frame *f) switch (f->want_fullscreen) { /* No difference between these two when there is no WM */ - case FULLSCREEN_BOTH: case FULLSCREEN_MAXIMIZED: + lval = Qmaximized; + width = x_display_pixel_width (dpyinfo); + height = x_display_pixel_height (dpyinfo); + break; + case FULLSCREEN_BOTH: + lval = Qfullboth; width = x_display_pixel_width (dpyinfo); height = x_display_pixel_height (dpyinfo); break; case FULLSCREEN_WIDTH: + lval = Qfullwidth; width = x_display_pixel_width (dpyinfo); height = height + FRAME_MENUBAR_HEIGHT (f); break; case FULLSCREEN_HEIGHT: + lval = Qfullheight; height = x_display_pixel_height (dpyinfo); } frame_size_history_add (f, Qx_check_fullscreen, width, height, Qnil); + x_wm_set_size_hint (f, 0, false); + XResizeWindow (FRAME_X_DISPLAY (f), FRAME_OUTER_WINDOW (f), width, height); @@ -10201,6 +10212,10 @@ x_check_fullscreen (struct frame *f) x_sync (f); } } + + /* `x_net_wm_state' might have reset the fullscreen frame parameter, + restore it. */ + store_frame_param (f, Qfullscreen, lval); } /* This function is called by x_set_offset to determine whether the window -- 2.5.0 ^ permalink raw reply related [flat|nested] 19+ messages in thread
* bug#21317: 25.0.50; frame-resize-pixelwise has no effect (GTK, no window manager) 2015-08-23 13:47 ` Pip Cet @ 2015-08-23 14:09 ` martin rudalics 2015-08-23 14:44 ` Pip Cet 0 siblings, 1 reply; 19+ messages in thread From: martin rudalics @ 2015-08-23 14:09 UTC (permalink / raw) To: Pip Cet; +Cc: 21317 > (No, but soon, hopefully.) Please do that. We might need it. > I've attached the patch with a suggested ChangeLog entry (though of > course you should change it to your own name). Thinking about this twice: Could you please also send a patch that's based on your earlier proposal, namely to "skip the hints in maximized/fullscreen state if wm_supports(net_wm_state) || wm_supports(net_wm_state_fullscreen), it might be KWin" and leaves out any of the changes I proposed. I think it would be cleaner and not change anything for KWin users who apparently are happy with the current state of affairs. Thanks, martin ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#21317: 25.0.50; frame-resize-pixelwise has no effect (GTK, no window manager) 2015-08-23 14:09 ` martin rudalics @ 2015-08-23 14:44 ` Pip Cet 2015-08-23 17:55 ` martin rudalics 0 siblings, 1 reply; 19+ messages in thread From: Pip Cet @ 2015-08-23 14:44 UTC (permalink / raw) To: martin rudalics; +Cc: 21317 [-- Attachment #1: Type: text/plain, Size: 969 bytes --] On Sun, Aug 23, 2015 at 2:09 PM, martin rudalics <rudalics@gmx.at> wrote: >> (No, but soon, hopefully.) > > Please do that. We might need it. I sent the email last week, so it's beyond my control :-) >> I've attached the patch with a suggested ChangeLog entry (though of >> course you should change it to your own name). > > Thinking about this twice: Could you please also send a patch that's > based on your earlier proposal, namely to "skip the hints in > maximized/fullscreen state if wm_supports(net_wm_state) || > wm_supports(net_wm_state_fullscreen), it might be KWin" and leaves out > any of the changes I proposed. I think it would be cleaner and not > change anything for KWin users who apparently are happy with the current > state of affairs. Attached. I feel a bit uneasy about making wm_supports a global symbol, maybe it should be x_wm_supports? In any case, please do let me know what else needs changing and I'll be happy to do it. Thanks again! [-- Attachment #2: 0001-Fix-full-screen-code-when-there-is-no-window-manager.patch --] [-- Type: text/x-patch, Size: 3653 bytes --] From 0ee7d8c5b3bb63fbed9264eb3facab010b136ca1 Mon Sep 17 00:00:00 2001 From: Philip <pipcet@gmail.com> Date: Sun, 23 Aug 2015 14:37:41 +0000 Subject: [PATCH] Fix full-screen code when there is no window manager. * xterm.c (wm_suppports): Export function. (x_check_fullscreen): Call `x_wm_set_size_hint', restore `fullscreen' frame parameter. * gtkutil.c (x_wm_set_size_hint): Set size hints when running without a window manager. --- src/gtkutil.c | 6 +++++- src/xterm.c | 19 +++++++++++++++++-- 2 files changed, 22 insertions(+), 3 deletions(-) diff --git a/src/gtkutil.c b/src/gtkutil.c index d684cd9..33f2a02 100644 --- a/src/gtkutil.c +++ b/src/gtkutil.c @@ -135,6 +135,8 @@ along with GNU Emacs. If not, see <http://www.gnu.org/licenses/>. */ static void update_theme_scrollbar_width (void); static void update_theme_scrollbar_height (void); +bool wm_supports (struct frame *f, Atom want_atom); + #define TB_INFO_KEY "xg_frame_tb_info" struct xg_frame_tb_info { @@ -1375,7 +1377,9 @@ x_wm_set_size_hint (struct frame *f, long int flags, bool user_position) XSETFRAME (frame, f); fs_state = Fframe_parameter (frame, Qfullscreen); - if (EQ (fs_state, Qmaximized) || EQ (fs_state, Qfullboth)) + if ((EQ (fs_state, Qmaximized) || EQ (fs_state, Qfullboth)) && + (wm_supports (f, FRAME_DISPLAY_INFO (f)->Xatom_net_wm_state) || + wm_supports (f, FRAME_DISPLAY_INFO (f)->Xatom_net_wm_state_fullscreen))) { /* Don't set hints when maximized or fullscreen. Apparently KWin and Gtk3 don't get along and the frame shrinks (!). diff --git a/src/xterm.c b/src/xterm.c index b7aacfa..9139758 100644 --- a/src/xterm.c +++ b/src/xterm.c @@ -9782,7 +9782,7 @@ x_set_offset (struct frame *f, register int xoff, register int yoff, int change_ Specification/Extended Window Manager Hints at http://freedesktop.org/wiki/Specifications/wm-spec. */ -static bool +bool wm_supports (struct frame *f, Atom want_atom) { Atom actual_type; @@ -10155,6 +10155,8 @@ x_handle_net_wm_state (struct frame *f, const XPropertyEvent *event) static void x_check_fullscreen (struct frame *f) { + Lisp_Object lval = Qnil; + if (do_ewmh_fullscreen (f)) return; @@ -10173,22 +10175,31 @@ x_check_fullscreen (struct frame *f) switch (f->want_fullscreen) { /* No difference between these two when there is no WM */ - case FULLSCREEN_BOTH: case FULLSCREEN_MAXIMIZED: + lval = Qmaximized; + width = x_display_pixel_width (dpyinfo); + height = x_display_pixel_height (dpyinfo); + break; + case FULLSCREEN_BOTH: + lval = Qfullboth; width = x_display_pixel_width (dpyinfo); height = x_display_pixel_height (dpyinfo); break; case FULLSCREEN_WIDTH: + lval = Qfullwidth; width = x_display_pixel_width (dpyinfo); height = height + FRAME_MENUBAR_HEIGHT (f); break; case FULLSCREEN_HEIGHT: + lval = Qfullheight; height = x_display_pixel_height (dpyinfo); } frame_size_history_add (f, Qx_check_fullscreen, width, height, Qnil); + x_wm_set_size_hint (f, 0, false); + XResizeWindow (FRAME_X_DISPLAY (f), FRAME_OUTER_WINDOW (f), width, height); @@ -10201,6 +10212,10 @@ x_check_fullscreen (struct frame *f) x_sync (f); } } + + /* `x_net_wm_state' might have reset the fullscreen frame parameter, + restore it. */ + store_frame_param (f, Qfullscreen, lval); } /* This function is called by x_set_offset to determine whether the window -- 2.5.0 ^ permalink raw reply related [flat|nested] 19+ messages in thread
* bug#21317: 25.0.50; frame-resize-pixelwise has no effect (GTK, no window manager) 2015-08-23 14:44 ` Pip Cet @ 2015-08-23 17:55 ` martin rudalics 2015-08-23 19:43 ` Pip Cet 0 siblings, 1 reply; 19+ messages in thread From: martin rudalics @ 2015-08-23 17:55 UTC (permalink / raw) To: Pip Cet; +Cc: 21317 > I sent the email last week, so it's beyond my control :-) Fine. > Attached. I feel a bit uneasy about making wm_supports a global > symbol, maybe it should be x_wm_supports? x_wm_supports sounds indeed better. > In any case, please do let > me know what else needs changing and I'll be happy to do it. Everything else is perfect now (IMHO). martin ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#21317: 25.0.50; frame-resize-pixelwise has no effect (GTK, no window manager) 2015-08-23 17:55 ` martin rudalics @ 2015-08-23 19:43 ` Pip Cet 2015-08-24 8:17 ` martin rudalics 0 siblings, 1 reply; 19+ messages in thread From: Pip Cet @ 2015-08-23 19:43 UTC (permalink / raw) To: martin rudalics; +Cc: 21317 [-- Attachment #1: Type: text/plain, Size: 539 bytes --] On Sun, Aug 23, 2015 at 5:55 PM, martin rudalics <rudalics@gmx.at> wrote: >> Attached. I feel a bit uneasy about making wm_supports a global >> symbol, maybe it should be x_wm_supports? > > x_wm_supports sounds indeed better. Patch attached. Still works, too! >> In any case, please do let >> me know what else needs changing and I'll be happy to do it. > > Everything else is perfect now (IMHO). Well, let's hope there won't be a flood of bug reports from KWin users. Thanks again for all your help in this very confusing matter, Pip [-- Attachment #2: 0002-Rename-wm_supports-to-x_wm_supports.patch --] [-- Type: text/x-patch, Size: 3608 bytes --] From e4dc0fd8787208488912c9d0e56d83fbcf9c34dd Mon Sep 17 00:00:00 2001 From: Philip <pipcet@gmail.com> Date: Sun, 23 Aug 2015 19:27:09 +0000 Subject: [PATCH 2/2] Rename `wm_supports' to `x_wm_supports' * xterm.c (x_wm_supports): Renamed from `wm_supports'. (x_ewmh_activate_frame): Adjust for rename. * gtkutil.c (x_wm_set_size_hint): Adjust for rename. --- src/gtkutil.c | 6 ++---- src/xterm.c | 8 ++++---- src/xterm.h | 1 + 3 files changed, 7 insertions(+), 8 deletions(-) diff --git a/src/gtkutil.c b/src/gtkutil.c index 33f2a02..5fc2beb 100644 --- a/src/gtkutil.c +++ b/src/gtkutil.c @@ -135,8 +135,6 @@ along with GNU Emacs. If not, see <http://www.gnu.org/licenses/>. */ static void update_theme_scrollbar_width (void); static void update_theme_scrollbar_height (void); -bool wm_supports (struct frame *f, Atom want_atom); - #define TB_INFO_KEY "xg_frame_tb_info" struct xg_frame_tb_info { @@ -1378,8 +1376,8 @@ x_wm_set_size_hint (struct frame *f, long int flags, bool user_position) XSETFRAME (frame, f); fs_state = Fframe_parameter (frame, Qfullscreen); if ((EQ (fs_state, Qmaximized) || EQ (fs_state, Qfullboth)) && - (wm_supports (f, FRAME_DISPLAY_INFO (f)->Xatom_net_wm_state) || - wm_supports (f, FRAME_DISPLAY_INFO (f)->Xatom_net_wm_state_fullscreen))) + (x_wm_supports (f, FRAME_DISPLAY_INFO (f)->Xatom_net_wm_state) || + x_wm_supports (f, FRAME_DISPLAY_INFO (f)->Xatom_net_wm_state_fullscreen))) { /* Don't set hints when maximized or fullscreen. Apparently KWin and Gtk3 don't get along and the frame shrinks (!). diff --git a/src/xterm.c b/src/xterm.c index 9139758..7bb2032 100644 --- a/src/xterm.c +++ b/src/xterm.c @@ -9783,7 +9783,7 @@ x_set_offset (struct frame *f, register int xoff, register int yoff, int change_ http://freedesktop.org/wiki/Specifications/wm-spec. */ bool -wm_supports (struct frame *f, Atom want_atom) +x_wm_supports (struct frame *f, Atom want_atom) { Atom actual_type; unsigned long actual_size, bytes_remaining; @@ -9976,7 +9976,7 @@ static bool do_ewmh_fullscreen (struct frame *f) { struct x_display_info *dpyinfo = FRAME_DISPLAY_INFO (f); - bool have_net_atom = wm_supports (f, dpyinfo->Xatom_net_wm_state); + bool have_net_atom = x_wm_supports (f, dpyinfo->Xatom_net_wm_state); int cur; bool dummy; @@ -9985,7 +9985,7 @@ do_ewmh_fullscreen (struct frame *f) /* Some window managers don't say they support _NET_WM_STATE, but they do say they support _NET_WM_STATE_FULLSCREEN. Try that also. */ if (!have_net_atom) - have_net_atom = wm_supports (f, dpyinfo->Xatom_net_wm_state_fullscreen); + have_net_atom = x_wm_supports (f, dpyinfo->Xatom_net_wm_state_fullscreen); if (have_net_atom && cur != f->want_fullscreen) { @@ -10579,7 +10579,7 @@ x_ewmh_activate_frame (struct frame *f) struct x_display_info *dpyinfo = FRAME_DISPLAY_INFO (f); - if (FRAME_VISIBLE_P (f) && wm_supports (f, dpyinfo->Xatom_net_active_window)) + if (FRAME_VISIBLE_P (f) && x_wm_supports (f, dpyinfo->Xatom_net_active_window)) { Lisp_Object frame; XSETFRAME (frame, f); diff --git a/src/xterm.h b/src/xterm.h index 5622344..6165906 100644 --- a/src/xterm.h +++ b/src/xterm.h @@ -1072,6 +1072,7 @@ x_display_set_last_user_time (struct x_display_info *dpyinfo, Time t) } extern void x_set_sticky (struct frame *, Lisp_Object, Lisp_Object); +extern bool x_wm_supports (struct frame *, Atom); extern void x_wait_for_event (struct frame *, int); extern void x_clear_under_internal_border (struct frame *f); -- 2.5.0 ^ permalink raw reply related [flat|nested] 19+ messages in thread
* bug#21317: 25.0.50; frame-resize-pixelwise has no effect (GTK, no window manager) 2015-08-23 19:43 ` Pip Cet @ 2015-08-24 8:17 ` martin rudalics 2015-08-24 10:45 ` Pip Cet 0 siblings, 1 reply; 19+ messages in thread From: martin rudalics @ 2015-08-24 8:17 UTC (permalink / raw) To: Pip Cet; +Cc: 21317 > Well, let's hope there won't be a flood of bug reports from KWin users. Installed on master/trunk so let's wait for the flood. Please have a look and if everything's OK close the bug. martin ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#21317: 25.0.50; frame-resize-pixelwise has no effect (GTK, no window manager) 2015-08-24 8:17 ` martin rudalics @ 2015-08-24 10:45 ` Pip Cet 0 siblings, 0 replies; 19+ messages in thread From: Pip Cet @ 2015-08-24 10:45 UTC (permalink / raw) To: martin rudalics; +Cc: 21317-done Everything seems to be working fine here, hopefully this will close the bug properly. Thank you again, Pip On Mon, Aug 24, 2015 at 8:17 AM, martin rudalics <rudalics@gmx.at> wrote: >> Well, let's hope there won't be a flood of bug reports from KWin users. > > Installed on master/trunk so let's wait for the flood. Please have a > look and if everything's OK close the bug. > > martin ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#21317: 25.0.50; frame-resize-pixelwise has no effect (GTK, no window manager) 2015-08-23 12:20 ` Pip Cet 2015-08-23 12:29 ` Pip Cet @ 2015-08-23 13:10 ` martin rudalics 1 sibling, 0 replies; 19+ messages in thread From: martin rudalics @ 2015-08-23 13:10 UTC (permalink / raw) To: Pip Cet; +Cc: 21317 >> Do I understand finally? x_net_wm_state resets the fullscreen state to >> nil via its store_frame_param? That would be the missing link then. > > Indeed. Aha. > (Minor point of confusion here: there are two functions called > `x_net_wm_state' and `x_handle_net_wm_state' which appear to do the > same thing...) The other one handles the sticky value. I've no idea whether it's useful, though. > The problem appears with all of maximized, fullheight, fullwidth, and fullboth. Because in all of these cases setting the size hint is suppressed and/or the parameter is reset. This is quite a mess. >> So when you try to increase the height of a normal frame by one pixel, >> which is the resize operation you send? > > set_frame_height calls adjust_frame_size which calls x_set_window_size > which calls xg_frame_set_char_size. > x_set_window_size_1 is NOT being called in this case. Aha. >> I suppose it's the last one >> from x_set_window_size_1 so Emacs correctly passes the size hint with >> frame_resize_pixelwise 1. Right? > > No, x_set_window_size_1 never is called here. Obviously. > It's the last case in xg_frame_set_char_size, which calls > gtk_window_resize FIRST, then calls x_wm_set_size_hints. I do not > understand why that works, but it appears to. (Is this another bug? > I'm seriously confused at this point). I too. But I already mentioned that in my second mail ;-) >> If this is the case, then Emacs should, for you, also handle fullwidth >> and fullheight requests correctly via the first and second of the >> requests in x_set_window_size_1. Right? > > No. x_set_window_size_1 isn't called at all. xg_frame_set_char_size > isn't called for fullscreen requests at all. OK >> So the two remaining cases Emacs can't handle for you are fullscreen and >> maximized requests. Right? > > No, it's all four fullscreen settings. OK >>> I do wonder how useful it is to support the case without a window >>> manager; unfortunately, I think it is useful, much as I'd enjoy all >>> that code going away and leaving things to the window manager. >> >> I miss you here: Which "case" do you mean? > > I was considering whether it might be best to remove the > no-window-manager code entirely, but I don't think we should. IIRC we earlier never asked a window manager and emulated the fullscreen stuff ourselves. Currently we still emulate fullheight and fullwidth on Windows for example. >>> If my understanding is correct, the best way forward is this: >>> >>> - skip the hints in maximized/fullscreen state if >>> wm_supports(net_wm_state) || wm_supports(net_wm_state_fullscreen), it >>> might be KWin >>> - otherwise, set the hints >> >> OK. These can be done easily, maybe in combination with my patch. > > I think your patch actually solves that problem: if there's no WM, > get_current_wm_state will always return FULLSCREEN_NONE, ... via is_hidden ... > so we set the > size hints appropriately. Hopefully. So let me summarize what's needed: (1) x_check_fullscreen has to call x_wm_set_size_hint before it calls x_wm_set_size_hint. (2) x_wm_set_size_hint should set the increments as long as the window is not fullscreen-something. (3) x_check_fullscreen has to restore the fullscreen frame parameter mangled by x_net_wm_state. (4) (Possibly unrelated) xg_frame_set_char_size should call x_wm_set_size_hint before calling gtk_window_resize. If you come up with a patch for (1)-(3) I'll install it and we can see what kind of breakage it gets us. --- I see you've done that already. --- We can do (4) later. martin ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2015-08-24 10:45 UTC | newest] Thread overview: 19+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-08-21 22:34 bug#21317: 25.0.50; frame-resize-pixelwise has no effect (GTK, no window manager) Pip Cet 2015-08-22 6:40 ` martin rudalics 2015-08-22 10:50 ` Pip Cet 2015-08-22 14:16 ` martin rudalics 2015-08-22 15:32 ` Pip Cet 2015-08-22 17:46 ` martin rudalics 2015-08-23 9:45 ` Pip Cet 2015-08-23 11:12 ` martin rudalics 2015-08-23 12:20 ` Pip Cet 2015-08-23 12:29 ` Pip Cet 2015-08-23 13:23 ` martin rudalics 2015-08-23 13:47 ` Pip Cet 2015-08-23 14:09 ` martin rudalics 2015-08-23 14:44 ` Pip Cet 2015-08-23 17:55 ` martin rudalics 2015-08-23 19:43 ` Pip Cet 2015-08-24 8:17 ` martin rudalics 2015-08-24 10:45 ` Pip Cet 2015-08-23 13:10 ` martin rudalics
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).