From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jan =?UTF-8?Q?Dj=C3=A4rv?= Newsgroups: gmane.emacs.bugs Subject: bug#14233: 24.3; Don't constrain frame size to character multiples Date: Mon, 22 Apr 2013 15:11:26 +0200 Message-ID: <5064BF03-8A61-4C0E-AA6C-5197A177B61A@swipnet.se> References: <2r7gjy2gyy.fsf@fencepost.gnu.org> <83bo991z00.fsf@gnu.org> <517257A0.4080607@gmx.at> <071A708E-3A98-4D11-A15F-7AB92D5200DD@swipnet.se> <51727563.70905@gmx.at> <5172908F.7090206@swipnet.se> <83sj2lz6nm.fsf@gnu.org> <5172EBEF.7030301@swipnet.se> <5173B0D8.4010408@gmx.at> <9CE9273D-8550-478F-8CB9-0C0D693C0BB8@swipnet.se> <5175042E.5020508@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1366636340 25537 80.91.229.3 (22 Apr 2013 13:12:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 22 Apr 2013 13:12:20 +0000 (UTC) Cc: esabof@gmail.com, 14233@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Apr 22 15:12:23 2013 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 1UUGXf-0005HX-61 for geb-bug-gnu-emacs@m.gmane.org; Mon, 22 Apr 2013 15:12:23 +0200 Original-Received: from localhost ([::1]:39719 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UUGXe-0001UJ-Jq for geb-bug-gnu-emacs@m.gmane.org; Mon, 22 Apr 2013 09:12:22 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:44196) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UUGXZ-0001SF-Hr for bug-gnu-emacs@gnu.org; Mon, 22 Apr 2013 09:12:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UUGXU-0006bl-2o for bug-gnu-emacs@gnu.org; Mon, 22 Apr 2013 09:12:17 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:60840) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UUGXT-0006bS-VX for bug-gnu-emacs@gnu.org; Mon, 22 Apr 2013 09:12:11 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UUGcA-0005Cn-Gd for bug-gnu-emacs@gnu.org; Mon, 22 Apr 2013 09:17:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Jan =?UTF-8?Q?Dj=C3=A4rv?= Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 22 Apr 2013 13:17:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 14233 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 14233-submit@debbugs.gnu.org id=B14233.136663658419896 (code B ref 14233); Mon, 22 Apr 2013 13:17:02 +0000 Original-Received: (at 14233) by debbugs.gnu.org; 22 Apr 2013 13:16:24 +0000 Original-Received: from localhost ([127.0.0.1]:36714 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UUGbW-0005Ap-MQ for submit@debbugs.gnu.org; Mon, 22 Apr 2013 09:16:23 -0400 Original-Received: from mailout.melmac.se ([62.20.26.67]:61765) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UUGbT-0005AS-Qr for 14233@debbugs.gnu.org; Mon, 22 Apr 2013 09:16:21 -0400 Original-Received: from mail01.melmac.se (mail01.melmac.se [62.20.26.80]) by mailout.melmac.se (Postfix) with ESMTP id EFF14C29F for <14233@debbugs.gnu.org>; Mon, 22 Apr 2013 15:11:26 +0200 (CEST) Original-Received: (qmail 19739 invoked by uid 89); 22 Apr 2013 13:10:34 -0000 Original-Received: from h-46-59-42-18.na.cust.bahnhof.se (HELO coolsville.localdomain) (boel.djarv@bdtv.se@46.59.42.18) by mail01.melmac.se with ESMTPA; 22 Apr 2013 13:10:34 -0000 Original-Received: from [172.20.199.13] (zeplin [172.20.199.13]) by coolsville.localdomain (Postfix) with ESMTPSA id 45E6D7FA058; Mon, 22 Apr 2013 15:11:26 +0200 (CEST) In-Reply-To: <5175042E.5020508@gmx.at> X-Mailer: Apple Mail (2.1503) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.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:73570 Archived-At: Hello. 22 apr 2013 kl. 11:34 skrev martin rudalics : > > For NS a maximized and fullscreen requests comes in as separate > > requests, for X they are normal resize request. > [...] > > The problem is that you think from the W32 point of view where (if I > > interepret you correctly), Emacs applies size hints after the resize > > request has been delivered. >=20 > I think so. >=20 > > This is not so for NS and X. Any size in a resize request is > > accepted. If it follows WM size hints, great, if it don't, who > > cares?. The frame size is set to the size in the request anyway. >=20 > IIUC we do care because we want to fit the frame's windows according = to > the incoming request. In the future, yes, but we can't resize windows pixelwise yet. >=20 > > So for NS and X, fullscreen, maximized and such is no problem. A > > minor glitch in NS is that we calculate the maximized sizes ourself, > > and these are rounded to character sizes. If windows could handle > > pixel sizes, we could easily fix this. >=20 > In any case, the maximized size of the frame is not necessarily an > integral multiple of character sizes so the frame gets or should get > resized pixelwise. We don't do that now because we can't resize windows pixelwise yet. >=20 > > But there is no restriction on NS and X11 frames to resize by pixel > > (i.e. not character multiples). >=20 > So by default, on Windows I always accept a maximize request and = resize > windows accordingly. For any other size request I process a = non-rounded > size iff the variable `frame-resize-pixelwise' is non-nil. >=20 > On all other platforms, `frame-resize-pixelwise' has no impact. If = and > whether size hints are turned on and have any impact depends on = settings > for the window manager used and is of no concern to me. Whatever size > is requested by the WM is processed without any rounding. >=20 > The interface to the window subsystem will be the function >=20 > change_frame_size (struct frame *f, int new_width, int new_height, > bool pretend, bool delay, bool safe, bool pixelwise) >=20 > which processes new_width and new_height in terms of pixels if = pixelwise > is non-nil. >=20 This is insane. it means changing lots and lots of calls, and makes = merging between branches harder. Make a new function (change_frame_size_pixelwise for example), with the = arguments above, and let change_frame_size call it with the last = argument false. Jan D.