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: Tue, 23 Apr 2013 13:58:07 +0200 Message-ID: <868917EF-7586-4F0D-BCDA-0B6F83FBB0A6@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> <5064BF03-8A61-4C0E-AA6C-5197A177B61A@swipnet.se> <517558ED.7080907@gmx.at> <5175679B.8010903@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 1366718351 18430 80.91.229.3 (23 Apr 2013 11:59:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 23 Apr 2013 11:59:11 +0000 (UTC) Cc: "esabof@gmail.com" , "14233@debbugs.gnu.org" <14233@debbugs.gnu.org> To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Apr 23 13:59:14 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 1UUbsQ-000656-H1 for geb-bug-gnu-emacs@m.gmane.org; Tue, 23 Apr 2013 13:59:14 +0200 Original-Received: from localhost ([::1]:32870 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UUbsQ-0003HJ-7J for geb-bug-gnu-emacs@m.gmane.org; Tue, 23 Apr 2013 07:59:14 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:57866) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UUbsM-0003Ct-Ae for bug-gnu-emacs@gnu.org; Tue, 23 Apr 2013 07:59:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UUbsI-0003Zw-LE for bug-gnu-emacs@gnu.org; Tue, 23 Apr 2013 07:59:10 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:34429) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UUbsI-0003Zl-If for bug-gnu-emacs@gnu.org; Tue, 23 Apr 2013 07:59:06 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UUbx4-0006JU-Dq for bug-gnu-emacs@gnu.org; Tue, 23 Apr 2013 08:04: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: Tue, 23 Apr 2013 12:04: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.136671858824105 (code B ref 14233); Tue, 23 Apr 2013 12:04:02 +0000 Original-Received: (at 14233) by debbugs.gnu.org; 23 Apr 2013 12:03:08 +0000 Original-Received: from localhost ([127.0.0.1]:38538 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UUbwC-0006Gi-1a for submit@debbugs.gnu.org; Tue, 23 Apr 2013 08:03:08 -0400 Original-Received: from mailout.melmac.se ([62.20.26.67]:49207) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UUbw8-0006GM-Ol for 14233@debbugs.gnu.org; Tue, 23 Apr 2013 08:03:06 -0400 Original-Received: from mail01.melmac.se (mail01.melmac.se [62.20.26.80]) by mailout.melmac.se (Postfix) with ESMTP id 197F899E8 for <14233@debbugs.gnu.org>; Tue, 23 Apr 2013 13:58:06 +0200 (CEST) Original-Received: (qmail 27578 invoked by uid 89); 23 Apr 2013 11:57:10 -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; 23 Apr 2013 11:57:10 -0000 Original-Received: from [172.20.199.13] (zeplin [172.20.199.13]) by coolsville.localdomain (Postfix) with ESMTPSA id C6F7B7FA058; Tue, 23 Apr 2013 13:58:05 +0200 (CEST) In-Reply-To: <5175679B.8010903@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:73600 Archived-At: Hello. 22 apr 2013 kl. 18:38 skrev martin rudalics : > >>> This is insane. it means changing lots and lots of calls, and = makes merging between branches harder. > >> Currently, change_frame_size doesn't know anything about the = various > >> platforms' requirements going beyond those of the frame's text = area. > > > > I don't understand what you are trying to say. >=20 > change_frame_size has no idea whether it is called for a text or a > graphical frame. Text frames might want to call it as before using > character sizes. Callers that are able to process pixels and want = them > applied will call it with pixel sizes. In any case, the callers have = to > strip space used for tool- or menubars because change_frame_size does > not know whether these are part of the frame or not. We do have macros like FRAME_MENUBAR_HEIGHT and FRAME_TOOLBAR_HEIGHT = that can be used. It is better to have that calculation in one place, = rather than in each port, so this might be a good time to move it. >=20 > >>> 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. > >> And how would change_frame_size know what the new pixel dimensions = of > >> the frame's text area are? > > > > As Emacs has always done, multiply by canonical character pixel = size. >=20 > Doing that would just leave things as they are now. >=20 > When I maximize a frame, that frame may get a new pixel size which is > not necessarily a multiple of the frame's character size. If I now = want > to resize that frame's windows (and not leave some spare pixels at the > bottom of the frame as we do now) I have to communicate the new pixel > size of the frame's root window to the window resizing mechanism. The > function that does that is change_frame_size. That is one occasion where a pixel-function is needed. But for most = calls, pixel precision is not needed. These are the = non-tile/fullscreen/maxmimized cases in X and NS. Jan D.