From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: YAMAMOTO Mitsuharu Newsgroups: gmane.emacs.devel Subject: Re: Emacs Mac port Date: Mon, 19 Sep 2016 11:01:33 +0900 Organization: Faculty of Science, Chiba University Message-ID: References: <57DE4306.6060904@gmx.at> <57DE4D33.6070201@gmx.at> <57DE63EC.3010305@gmx.at> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Trace: blaine.gmane.org 1474250517 11888 195.159.176.226 (19 Sep 2016 02:01:57 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 19 Sep 2016 02:01:57 +0000 (UTC) User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Cc: emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 19 04:01:52 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1blnu3-0002FO-HO for ged-emacs-devel@m.gmane.org; Mon, 19 Sep 2016 04:01:51 +0200 Original-Received: from localhost ([::1]:52303 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1blnu1-0006IP-Oc for ged-emacs-devel@m.gmane.org; Sun, 18 Sep 2016 22:01:49 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36922) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1blntv-0006IB-1u for emacs-devel@gnu.org; Sun, 18 Sep 2016 22:01:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1blntq-0005Hg-Qg for emacs-devel@gnu.org; Sun, 18 Sep 2016 22:01:41 -0400 Original-Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]:49527) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1blntq-0005Ge-Dv for emacs-devel@gnu.org; Sun, 18 Sep 2016 22:01:38 -0400 Original-Received: from fermat1.math.s.chiba-u.ac.jp (fermat [192.168.32.10]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id A5DA9F08EA; Mon, 19 Sep 2016 11:01:33 +0900 (JST) (envelope-from mituharu@math.s.chiba-u.ac.jp) In-Reply-To: <57DE63EC.3010305@gmx.at> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 133.82.132.2 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:207596 Archived-At: >>>>> On Sun, 18 Sep 2016 11:52:44 +0200, martin rudalics said: >> (Actually, the way to implement this screen updating during mouse >> dragging on the Mac port interferes with "window snapping" introduced >> in macOS 10.12, so it is disabled if running on that version.) > So what do you do with "window snapping"? Can you ask for a "white > out"? For "window snapping" introduced in macOS Sierra, see https://www.youtube.com/watch?v=pzJGeTS49f4 . The difficulty in updating the frame contents during resize by mouse dragging on OS X/macOS comes from the fact that it is processed in a modal loop. To reflect the frame size change in Emacs, we have to go back to Lisp event loop so it triggers redisplay, but the modal loop does not allow us to do so. Screen updating during mouse dragging is handled by generating fake events press -> drag -> release -> press -> drag -> release -> ... internally during a single dragging session. Between (fake) release and press, we go back to the Lisp event loop to trigger redisplay. Unfortunately, this fake event generation does not work with "window snapping" introduced in upcoming macOS 10.12 Sierra, probably because the contextual information is lost by fragmented drag events. I don't want to make a frame all white as in the NS port, so I capture the frame contents as a bitmap, decompose it to window (Emacs terminology) contents, and distribute them proportionally during resize by mouse dragging. >> Rounding does not happen for the axis that is specified to be >> maximized/full so that it does not leave spaces. So, rounding happens >> only for horizontal axis when the fullscreen frame parameter is set to >> 'fullheight if `frame-resize-pixelwise' is nil. > Sounds reasonable. Hmm... > Leaves me with one question: When do you suppress rounding with > `frame-resize-pixelwise' nil? Only for "for the axis that is specified > to be maximized/full"? Or are there other cases? No other cases. It is handled in the delegate method windowWillResize:toSize: (you can think it as a callback) at https://bitbucket.org/mituharu/emacs-mac/src/550234fa179601d4bace2cf32b693fc33f3d1266/src/macappkit.m?at=master&fileviewer=file-view-default#macappkit.m-2915 . Rounding is done in the method hintedWindowFrameSize:allowsLarger: at https://bitbucket.org/mituharu/emacs-mac/src/550234fa179601d4bace2cf32b693fc33f3d1266/src/macappkit.m?at=master&fileviewer=file-view-default#macappkit.m-2302 . YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp