From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Anders Lindgren Newsgroups: gmane.emacs.devel Subject: Re: recent change to nsterm.m: four pixels where the Dock is hidden Date: Fri, 25 Mar 2016 22:13:35 +0100 Message-ID: References: <25AFEF78-9B39-41F1-BC01-0208500E2711@gmail.com> <49D19730-400B-4456-AAEC-17CC8F84233D@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1143e9b630f4d6052ee60986 X-Trace: ger.gmane.org 1458940429 27404 80.91.229.3 (25 Mar 2016 21:13:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 25 Mar 2016 21:13:49 +0000 (UTC) Cc: Emacs-Devel devel To: David Reitter Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 25 22:13:45 2016 Return-path: Envelope-to: ged-emacs-devel@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 1ajZ3A-0007gY-Jl for ged-emacs-devel@m.gmane.org; Fri, 25 Mar 2016 22:13:44 +0100 Original-Received: from localhost ([::1]:58000 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ajZ38-0007gD-UP for ged-emacs-devel@m.gmane.org; Fri, 25 Mar 2016 17:13:42 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46571) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ajZ34-0007fu-2K for emacs-devel@gnu.org; Fri, 25 Mar 2016 17:13:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ajZ32-0004sP-2b for emacs-devel@gnu.org; Fri, 25 Mar 2016 17:13:37 -0400 Original-Received: from mail-vk0-x22a.google.com ([2607:f8b0:400c:c05::22a]:36741) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ajZ31-0004sK-SE for emacs-devel@gnu.org; Fri, 25 Mar 2016 17:13:36 -0400 Original-Received: by mail-vk0-x22a.google.com with SMTP id z68so102186485vkg.3 for ; Fri, 25 Mar 2016 14:13:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=hlzXTUCaHMJ71cB3EvR3eTgALmaOCcZMWBBoND6QR3g=; b=0sr190KQN9NTn2r2AvO9ap3fK1UByVqnYhAIkcSWrAuAIenVHxnSqeYCuztP9XiyBV PCA6nsmQZJ8zqQol2i8c+kPxRlUXwaBrOBbEz31n9JRtgkc4uy5fNqei5cjkr1xFVvGo LAXcBpFLzQkAIl2cL8mXh9YopwRehrrkzK9SZIIrq5tE01eg5i7OPPriLTRXneFbCXTx 6cnAzOlT/s1UTZ0D+d6AQ8XvzVeuqZxySm6MRzX5fFux7frl0iVIkw3DHnBWQvHbJF+k dRH59Ea+sI3v0o9pFQeFh1aIa0HoYPVvMV1s+tRgXK+P1hAwuVi+y/P8T5dRzsGHKbyd 4Ipw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=hlzXTUCaHMJ71cB3EvR3eTgALmaOCcZMWBBoND6QR3g=; b=fJkfjLUX0GuA0tj0G1e6k6yoF9k+m6BKZ81MMQ3J1TzMfVV3O0Sl/q8OZyJHzWzB4W jpUDpYYI+PGMdfd+/mqfdtUdH7BgCBFdWMVqa15DSApM1VWp7H7PgBabIDj+zsixuCG6 0Ho2ct7D9AwSj6CzYonyBTYyzyP9H0e4Z+Rg4bG1dDXSbvBnSetQTJI610VahTErCVXM OkNTlWmH/SvcLk0wlEecUjgyl4n92cFFBDYkbpSC6K7Aq/OJuXqRJeot095ao1n9760Y lIdi+kP1teEZHETYzurd0GQOtuB3Fu5YSwXkKdd29oDWlMno2lgLszIyDbVP6DDOyDwK g82g== X-Gm-Message-State: AD7BkJJE5Lh/PkRP5AX7aRaVM+PanNr1lBYq9b2V3rii6Nj74oyyiYxjvxnbsrzVdRIPHZl0v/oGt2VgyycI7g== X-Received: by 10.31.56.10 with SMTP id f10mr8405335vka.23.1458940415110; Fri, 25 Mar 2016 14:13:35 -0700 (PDT) Original-Received: by 10.31.214.131 with HTTP; Fri, 25 Mar 2016 14:13:35 -0700 (PDT) In-Reply-To: <49D19730-400B-4456-AAEC-17CC8F84233D@gmail.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:400c:c05::22a X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:202249 Archived-At: --001a1143e9b630f4d6052ee60986 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi! > The original change is difficult to read as it conflates the NSTRACE code > (a lot) with the more meaningful change. > Unfortunately, I enhanced and used the trace system while rewriting the zoom system, so it would have been very hard to do separate commits. > What I find problematic is that you=E2=80=99re trying to micro-manage the= position > and size of the frame when the system provides high-level functions such = as > [NSScreen visibleFrame] that essentially tell you what is available. The > comment with that commit suggests that you=E2=80=99re going over the Dock= (when > it=E2=80=99s not hidden), and if that is indeed the case, that would be a= mistake. Oh, it's quite the opposite. When the dock is visible, Emacs respect [NSScreen visibleFrame]. (Before the last commit, it didn't -- which caused the dock to overlap the Emacs frame.) However, when the dock is hidden, Emacs use the full height and width of the screen. > I would argue that one shouldn=E2=80=99t draw into a space the system con= siders > unsafe. > I agree that you have a point there. I'm open to reverting this change (or adding a variable controlling it) -- if people feel strongly about this. Personally, it feels odd not to use the full screen, though. (Of course, a user would still be able create a frame covering the entire screen using `set-frame-size' et.c., or use a package like my `multicolumn'.) Before I rewrote the zoom system, I looked around and checked how other applications worked. Many applications respect the four pixels reserved for the hidden dock, but far from all. One application that use a normal window, but still use the entire screen is Lightroom from Adobe, so I thought that we would be in good company. Anyway, I really appreciate that you take time to review the OS X-related changes! Sincerely, Anders > DR > > > [1] > https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Wi= nPanel/Tasks/SizingPlacingWindows.html > > > > On Mar 25, 2016, at 3:05 AM, Anders Lindgren wrote: > > > > Hi! > > > > The change to make `toggle-frame-maximized' cover the entire screen > (when the dock was hidden) was done much earlier, in 2015-10-23 (see link > to commit below), after a discussion that started in bug 21415 (see link)= . > At the time, everybody involved in the discussion thought that it was a > good idea for Emacs to cover the full height of the screen, when the dock > was hidden. > > > > When the pretest was released, a user reported that the code didn't wor= k > properly when the dock was visible. Effectively, the dock would cover par= ts > of Emacs. The commit you referred to is a fix for that problem. > > > > When investigating how an application could check if the dock was > hidden, it turned out that there is no standard API for this, but the > normal way this is checked is to compare the result of [screen frame] (i.= e. > the size of a display) with [screen visibleFrame] (i.e. the size, excludi= ng > the parts occupied by the OS). The OS reserves four pixels at the edge > where a hidden dock resides, my code use six as a break-off value in case > this is changed in future OS versions. > > > > I don't consider this a big change -- the fact that the change is 50 > lines is that I prefer a style where each logical step is isolated, well > documented, and there is a natural place for trace output. In this case I > decided to represent the margins using a new struct, and place the margin > calculation into two functions `ns_screen_margins' and > `ns_screen_margins_ignoring_hidden_dock'. Of course, I could easily have > written the code in a very condensed manner, inlining all calculations, b= ut > that wouldn't have been maintainable. > > > > This is the original change: > > > > > http://git.savannah.gnu.org/cgit/emacs.git/commit/?h=3Demacs-25&id=3Dba24= d35a3e82cdeba4be5bd794f7f48bbfa5498e > > > > Discussion: > > > > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D21415 > > > > -- Anders Lindgren > > > > On Fri, Mar 25, 2016 at 3:59 AM, David Reitter > wrote: > > Anders, > > > > I appreciate your work on the NS/OSX port. > > Reviewing a recent change, I can=E2=80=99t help but wonder: Do we real= ly need > 50 lines of a hack to counteract design decisions made at the system leve= l? > > > > If [NSScreen visibleFrame] tells us not to occupy certain space on the > screen - four pixels where the Dock is hidden - then that=E2=80=99s a sta= ndard that > all applications should adhere to. It=E2=80=99s probably done for a reas= on (such > as being able to un-hide the Dock and to grab the lower horizontal edge o= f > the window for resizing). > > > > ns_screen_margins_ignoring_hidden_dock is, excuse my bluntness, ugly as > it hardcodes some numbers that can change any time with a new OS version. > It=E2=80=99s a burden for future maintenance. > > > > If this is what #22988 really was about, then it=E2=80=99s not a bug an= d we > shouldn=E2=80=99t mess with it. Also not in 25.1. > > > > If I=E2=80=99m wrong, please excuse me. Could you explain if there is = some > deeper reasoning that I=E2=80=99m missing? > > > > Thanks, > > David > > > > > > > Author: Anders Lindgren > > > Date: Tue Mar 22 20:18:33 2016 +0100 > > > > > > Make `toggle-frame-maximized' respect the dock on OS X (bug#22988= ). > > > > > > * src/nsterm.m (ns_screen_margins): New function. > > > (ns_screen_margins_ignoring_hidden_dock): New function. > > > (ns_menu_bar_height): Reimplement in terms of `ns_screen_margins'= . > > > ([EmacsWindow zoom:]): Take all screen margins (except those > > > originating from a hidden dock) into account. > > > > > > > --001a1143e9b630f4d6052ee60986 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi!
=C2=A0
The original change is difficult to re= ad as it conflates the NSTRACE code (a lot) with the more meaningful change= .

Unfortunately, I enhanced and used th= e trace system while rewriting the zoom system, so it would have been very = hard to do separate commits.

=C2=A0
What I find problematic is that you=E2=80=99re trying to micro-manage the p= osition and size of the frame when the system provides high-level functions= such as [NSScreen visibleFrame] that essentially tell you what is availabl= e.=C2=A0 The comment with that commit suggests that you=E2=80=99re going ov= er the Dock (when it=E2=80=99s not hidden), and if that is indeed the case,= that would be a mistake.

Oh, it's quit= e the opposite. When the dock is visible, Emacs respect [NSScreen visibleFr= ame]. (Before the last commit, it didn't -- which caused the dock to ov= erlap the Emacs frame.)

However, when the dock is = hidden, Emacs use the full height and width of the screen.

=C2=A0
I would argue that one shouldn=E2=80= =99t draw into a space the system considers unsafe.
I agree that you have a point there. I'm open to reverting= this change (or adding a variable controlling it) -- if people feel strong= ly about this. Personally, it feels odd not to use the full screen, though.= (Of course, a user would still be able create a frame covering the entire = screen using `set-frame-size' et.c., or use a package like my `multicol= umn'.)

Before I rewrote the zoom system, I loo= ked around and checked how other applications worked. Many applications res= pect the four pixels reserved for the hidden dock, but far from all. One ap= plication that use a normal window, but still use the entire screen is Ligh= troom from Adobe, so I thought that we would be in good company.
<= div>

Anyway, I really appreciate that you take= time to review the OS X-related changes!

Sincerel= y,
=C2=A0 =C2=A0 Anders
=C2=A0

=C2=A0
DR


[1] https://developer.apple.com/library/mac/documentation/Cocoa/= Conceptual/WinPanel/Tasks/SizingPlacingWindows.html


> On Mar 25, 2016, at 3:05 AM, Anders Lindgren <andlind@gmail.com> wrote:
>
> Hi!
>
> The change to make `toggle-frame-maximized' cover the entire scree= n (when the dock was hidden) was done much earlier, in 2015-10-23 (see link= to commit below), after a discussion that started in bug 21415 (see link).= At the time, everybody involved in the discussion thought that it was a go= od idea for Emacs to cover the full height of the screen, when the dock was= hidden.
>
> When the pretest was released, a user reported that the code didn'= t work properly when the dock was visible. Effectively, the dock would cove= r parts of Emacs. The commit you referred to is a fix for that problem.
>
> When investigating how an application could check if the dock was hidd= en, it turned out that there is no standard API for this, but the normal wa= y this is checked is to compare the result of [screen frame] (i.e. the size= of a display) with [screen visibleFrame] (i.e. the size, excluding the par= ts occupied by the OS). The OS reserves four pixels at the edge where a hid= den dock resides, my code use six as a break-off value in case this is chan= ged in future OS versions.
>
> I don't consider this a big change -- the fact that the change is = 50 lines is that I prefer a style where each logical step is isolated, well= documented, and there is a natural place for trace output. In this case I = decided to represent the margins using a new struct, and place the margin c= alculation into two functions `ns_screen_margins' and `ns_screen_margin= s_ignoring_hidden_dock'. Of course, I could easily have written the cod= e in a very condensed manner, inlining all calculations, but that wouldn= 9;t have been maintainable.
>
> This is the original change:
>
>=C2=A0 =C2=A0 =C2=A0http://git.savannah.gnu.org/cgit/emacs= .git/commit/?h=3Demacs-25&id=3Dba24d35a3e82cdeba4be5bd794f7f48bbfa5498e=
>
> Discussion:
>
>=C2=A0 =C2=A0 =C2=A0http://debbugs.gnu.org/c= gi/bugreport.cgi?bug=3D21415
>
>=C2=A0 =C2=A0 =C2=A0-- Anders Lindgren
>
> On Fri, Mar 25, 2016 at 3:59 AM, David Reitter <david.reitter@gmail.com> wrote:
> Anders,
>
> I appreciate your work on the NS/OSX port.
> Reviewing a recent change, I can=E2=80=99t help but wonder:=C2=A0 Do w= e really need 50 lines of a hack to counteract design decisions made at the= system level?
>
> If [NSScreen visibleFrame] tells us not to occupy certain space on the= screen - four pixels where the Dock is hidden - then that=E2=80=99s a stan= dard that all applications should adhere to.=C2=A0 It=E2=80=99s probably do= ne for a reason (such as being able to un-hide the Dock and to grab the low= er horizontal edge of the window for resizing).
>
> ns_screen_margins_ignoring_hidden_dock is, excuse my bluntness, ugly a= s it hardcodes some numbers that can change any time with a new OS version.= It=E2=80=99s a burden for future maintenance.
>
> If this is what #22988 really was about, then it=E2=80=99s not a bug a= nd we shouldn=E2=80=99t mess with it.=C2=A0 Also not in 25.1.
>
> If I=E2=80=99m wrong, please excuse me.=C2=A0 Could you explain if the= re is some deeper reasoning that I=E2=80=99m missing?
>
> Thanks,
> David
>
>
> > Author: Anders Lindgren <= andlind@gmail.com>
> > Date:=C2=A0 =C2=A0Tue Mar 22 20:18:33 2016 +0100
> >
> >=C2=A0 =C2=A0 =C2=A0Make `toggle-frame-maximized' respect the = dock on OS X (bug#22988).
> >
> >=C2=A0 =C2=A0 =C2=A0* src/nsterm.m (ns_screen_margins): New functi= on.
> >=C2=A0 =C2=A0 =C2=A0(ns_screen_margins_ignoring_hidden_dock): New = function.
> >=C2=A0 =C2=A0 =C2=A0(ns_menu_bar_height): Reimplement in terms of = `ns_screen_margins'.
> >=C2=A0 =C2=A0 =C2=A0([EmacsWindow zoom:]): Take all screen margins= (except those
> >=C2=A0 =C2=A0 =C2=A0originating from a hidden dock) into account.<= br> > >
>


--001a1143e9b630f4d6052ee60986--