From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#21317: 25.0.50; frame-resize-pixelwise has no effect (GTK, no window manager) Date: Sun, 23 Aug 2015 13:12:29 +0200 Message-ID: <55D9AA9D.9030807@gmx.at> References: <55D8196B.3010206@gmx.at> <55D8844F.4080508@gmx.at> <55D8B57E.3010400@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------000604030305040202000404" X-Trace: ger.gmane.org 1440328406 10440 80.91.229.3 (23 Aug 2015 11:13:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 23 Aug 2015 11:13:26 +0000 (UTC) Cc: 21317@debbugs.gnu.org To: Pip Cet Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Aug 23 13:13:15 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZTTD8-0004ac-SF for geb-bug-gnu-emacs@m.gmane.org; Sun, 23 Aug 2015 13:13:15 +0200 Original-Received: from localhost ([::1]:33098 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZTTD7-0004Cn-TG for geb-bug-gnu-emacs@m.gmane.org; Sun, 23 Aug 2015 07:13:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39631) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZTTCz-000498-7k for bug-gnu-emacs@gnu.org; Sun, 23 Aug 2015 07:13:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZTTCv-0003Ea-TN for bug-gnu-emacs@gnu.org; Sun, 23 Aug 2015 07:13:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:43399) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZTTCv-0003EW-Qt for bug-gnu-emacs@gnu.org; Sun, 23 Aug 2015 07:13:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZTTCv-0002Xb-Jw for bug-gnu-emacs@gnu.org; Sun, 23 Aug 2015 07:13:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 23 Aug 2015 11:13:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21317 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21317-submit@debbugs.gnu.org id=B21317.14403283659739 (code B ref 21317); Sun, 23 Aug 2015 11:13:01 +0000 Original-Received: (at 21317) by debbugs.gnu.org; 23 Aug 2015 11:12:45 +0000 Original-Received: from localhost ([127.0.0.1]:35609 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZTTCe-0002X0-6Z for submit@debbugs.gnu.org; Sun, 23 Aug 2015 07:12:44 -0400 Original-Received: from mout.gmx.net ([212.227.17.21]:52550) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZTTCb-0002Wp-0U for 21317@debbugs.gnu.org; Sun, 23 Aug 2015 07:12:42 -0400 Original-Received: from [62.47.254.18] ([62.47.254.18]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M93Jp-1ZarBS3nAL-00CTmL; Sun, 23 Aug 2015 13:12:40 +0200 In-Reply-To: X-Provags-ID: V03:K0:n+pAw5BZbJskmqPy4G6K9MsYSiiBoy2hXvXKuO64mGRnn+hhWlB Z9bU1HIBAHW3fauhDKm0BlqNv3nApQKbGwhTOn3/oAX8DSF+V1f0+1+fLo9LUNyENMvnmU8 Rz9Vc769LTcXLHC/Zk9V35v504buPamGYqi36XN43i+/OjbY+ZCMmb8gkxqr8uLhA3hIwMC xtz+lqQcKwBtqK0mlm2Jg== X-UI-Out-Filterresults: notjunk:1;V01:K0:JcMrxukgnB8=:j/ySa5n6qLvOxYGT7PGNkm g5cJ5yKZ981045/9rLY5k2YP/+Tt+O6IRRKYhO9LqaZahd/HxyIuQPIBVv4xS3frXRug7RrbI WePS3XriZ3tLF6vzpB0sG/wQbp5HQdfEjcn/Tp4HmTYV6Tr9Q6JI6F+9bHc4gxYkB/KxRdsdU h1ZIp3Gg+2fS0Ey+RPgGMrrCbn903IFviRXC/YDbfeqjP7e2rRtJT1fQDr/L6FbXS90TUfhwx 5vmI2SppIysPgwJv5q4NlBLuJklzGNLLymycdgGo0pJRPFMdb9rrpq4iCS076zApl5e1oSSxx hj4DrxenkMnOvTWcj4iLJOHJw4vKwZHdUD2s+PxaGgNwF+/4JSLayqPD3NoX07Qn2LNjbrsSV aNsFbcwUNM1iLRWfOK2hSBOKuTq5J8BZhNjq7zktfe9g6DaOasm3h3CzwJMP4yCxRoIIQDk+D hzALmo7DNVwQA6VqPISvE8670ThBCs6tLpdHPdK7ZGx7H7abeJmUDnL74Uhix1NJ6KMbfRsuH nesFjmzQ23GlvrsagwBSb6Hrw60pwpawdkXccVgYaACqFplEhuHnfRZMD+fpg9jSWlMFWfIn8 V9JscBe+mOa8kye0ELTCqclOJ0pIAIGn1g+h1n1zXCCUV4xlP19QIBhb7JLFBINOwVNJ0LQFo Vbz69jDRVb6yF2gcaXdX1fkVkFfofx2sTtvi5TANhnA2DmbFWB4UCpmVW4SAp22sSJDyfHweQ m6Ua2V/AojGHLHso X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:105721 Archived-At: This is a multi-part message in MIME format. --------------000604030305040202000404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > 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 --------------000604030305040202000404 Content-Type: text/plain; charset=windows-1252; name="x_wm_size_hint.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="x_wm_size_hint.diff" --- a/src/gtkutil.c +++ b/src/gtkutil.c @@ -135,6 +135,8 @@ along with GNU Emacs. If not, see . */ 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, --------------000604030305040202000404--