From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#25408: Remove Decorations Around Emacs Frame (NS port) Date: Sun, 11 Jun 2017 10:10:44 +0200 Message-ID: <593CFB04.8000600@gmx.at> References: <20170417145613.GA78089@breton.holly.idiocy.org> <58F4E2BD.3090704@gmx.at> <20170417162149.GB78089@breton.holly.idiocy.org> <58F4F954.10709@gmx.at> <20170417185537.GA78689@breton.holly.idiocy.org> <58F7111F.6050004@gmx.at> <20170419143316.GB10595@breton.holly.idiocy.org> <58F789F0.9000608@gmx.at> <20170419170420.GA12166@breton.holly.idiocy.org> <58F7A749.6070906@gmx.at> <20170610153853.GA95401@breton.holly.idiocy.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1497168732 2164 195.159.176.226 (11 Jun 2017 08:12:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 11 Jun 2017 08:12:12 +0000 (UTC) Cc: Arthur Miller , 25408@debbugs.gnu.org, =?UTF-8?Q?Cl=C3=A9ment?= Pit--Claudel , Anders Lindgren To: Alan Third Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Jun 11 10:12:08 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1dJxyg-0000GM-NS for geb-bug-gnu-emacs@m.gmane.org; Sun, 11 Jun 2017 10:12:06 +0200 Original-Received: from localhost ([::1]:33183 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dJxym-00045z-3A for geb-bug-gnu-emacs@m.gmane.org; Sun, 11 Jun 2017 04:12:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54562) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dJxyf-00045j-Mk for bug-gnu-emacs@gnu.org; Sun, 11 Jun 2017 04:12:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dJxyc-0007A5-Cj for bug-gnu-emacs@gnu.org; Sun, 11 Jun 2017 04:12:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:37041) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dJxyc-0007A1-9N for bug-gnu-emacs@gnu.org; Sun, 11 Jun 2017 04:12:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dJxyc-0004wA-4i for bug-gnu-emacs@gnu.org; Sun, 11 Jun 2017 04:12:02 -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, 11 Jun 2017 08:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25408 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 25408-submit@debbugs.gnu.org id=B25408.149716867218922 (code B ref 25408); Sun, 11 Jun 2017 08:12:02 +0000 Original-Received: (at 25408) by debbugs.gnu.org; 11 Jun 2017 08:11:12 +0000 Original-Received: from localhost ([127.0.0.1]:39718 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dJxxo-0004v8-FW for submit@debbugs.gnu.org; Sun, 11 Jun 2017 04:11:12 -0400 Original-Received: from mout.gmx.net ([212.227.17.22]:55510) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dJxxj-0004uq-UF for 25408@debbugs.gnu.org; Sun, 11 Jun 2017 04:11:08 -0400 Original-Received: from [192.168.1.101] ([46.125.249.57]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MaE4a-1dZHur21UG-00JrE9; Sun, 11 Jun 2017 10:10:49 +0200 In-Reply-To: <20170610153853.GA95401@breton.holly.idiocy.org> X-Provags-ID: V03:K0:AScoI3/wmxAP8nPJTry0XOqV60eB8ODfmAZ1PzQcVEpLYDzipFf fChI8g/lWPwURfUGPSJuLOe92phu9CFV8auBBYlbWLhYgO1sob5s5hhZutcUHZTWSLXfRr/ /WP+vxRbUaYC7I38DIHpBbFET7UQE6Lvz8nQLXe6A6/K8KwI7lqthstnHO0vK8TLyTGUDg3 2dWQdlhMsz1zmzMswdwaQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:YB0bAaPDQc4=:YmoJxE0M+d5tNrHrzy/fB1 Vt6r66KtNv+GEEsOrpEyG1eEdEH/eOGH69HBIWLXVE//nksoJ+bN3UM5l3ByUf5/9gsnSsltM 6eO0ebXfFaeUHrOeJZTZ9JtHVdtKhxNiLFBPxaOxb+TDaSkZoZnoV0G+9d/idhoRO4IuDWpx0 y+Py/e52dZruGqlc4QAFqWNMPnr48BiAb8e0Fj1N45RTAXehtOHdv8bqP2yXJNWr1cnNqLRfp LHOsIoivcz2DIwO9/4+YTpX35vMFhASi5GteLpRtqj5MUNqXlgpG0LaXFPu0p4JznTct6nbB/ GF9/vDhB2MKWL0EmP1jOWGJynwIjtZM0P/Z7Qm7gfMsmus2B8WZRx1AdQ6V73IOKzLoB9dLqD azSpRomI0gSMz8Na+yFeE1tt3253RQHNyYxlbd9D39niuNdNxxBZqCawzLnvQ1eOpZ85lc+3G zlMYl0pCoEF6LI73DBL9pB7WOZ0+A2gOODls1ENEuFSYaIDdprtCxjq3MIdaZWOc8TfH9lvp9 l9JccbMriJsSZUiLz9OupcyGEMFzlE/lY+tofun4zlo0MuL1MRC82fB3pPsHhG00NH8ruQ6Br de1RA3x3sQ6iplois1tLUU+1ISOaGmAqeVXPagMB+iNJj8QVSi43tkOPTDparn5xxJbM7hWDt kPBJ0eRxHATZSuJd11/ltFjpoKFoQgsOaTpf9D9z8Rzez1nv6kBRYuOXoScMip3NiQOpN6zrC eLu12cb53N+k4WYbRULQcY9Hflg+yBsVQqqUGzwJAO4F6sRfJlSoEe7E2mtJ1L1ddQB2rgvf X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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" Xref: news.gmane.org gmane.emacs.bugs:133465 Archived-At: > I forgot that this bug is still open. Is it waiting for me to finish > up the NS stuff? By no means. You've already accomplished much more than I would have expected. I still want to check in the =E2=80=98no-special-glyphs=E2=80=99= parameter code mentioned elsewhere in this thread. Then I intend to close this bug. >>> Should I look into no-focus-on-map and no-accept-focus too? >> >> That would be fine. There's also the 'skip-taskbar' parameter but I >> have no idea whether NS allows that and whether NS provides Alt-tabbi= ng. > > no-accept-focus is done, but no-focus-on-map is harder. I believe I > can get a new frame to not be focused on creation, but I don=E2=80=99t= see any > way to prevent a minimized frame from becoming focused when > unminimized. Don't worry. Unminimizing is different from mapping. The former works on already mapped frames only, the latter on invisible frames only. "on-map" stands for "on making the frame visible" which might happen some time after the frame was created. Once visible you cannot map the frame until you make it invisible again. Alt-tabbing and unminimizing OTOH work on visible frames only, you cannot really unminimize an invisible window (although the window manager might remember the requested fullscreen status somewhere and later, when it makes the window visible, apply that state). =E2=80=98no-focus-on-map=E2=80=99 behaves well for all platforms and buil= ds I tried so far. It would be nice to have it for NS builds too. So all that is afforded by =E2=80=98no-focus-on-map=E2=80=99 is that, whenever a frame c= hanges from the invisible to the visible state, it does not get focus. > macOS has alt=E2=80=90tabbing between applications, but also alt=E2=80= =90` switches > between application windows. I haven=E2=80=99t yet found a way to disa= ble > this. There's certainly no need to do that. I wouldn't even know how to type alt-` with my keyboard layout. > FWIW, no-accept-focus, as implemented, prevents a frame from *ever* > accepting focus (although it can still accept input, which is > strange!). Rereading your description makes me wonder if I=E2=80=99ve = done > that wrong and the current behaviour is closer to no-accept-focus, > no-focus-on-map and skip-taskbar all being on? =E2=80=98no-accept-focus=E2=80=99 is not overly dear to me. I provided i= t because it works out of the box on GNU Linux. But the workaround I wrote for Windows is very harsh and I don't recommend it. The idea is to provide a behavior similar to tooltips - you cannot focus a tooltip window - with something like "but you can still focus it via C-x 5 o, if you need to". > I=E2=80=99m not sure I can do it any other way, though. Never mind. If it has some very special behavior and you feel like it, add a remark about it in the Elisp documentation. >> And please have a look into the Elisp manual: Maybe you find somethin= g >> worth mentioning (the fact that removing decorations removes the tool= >> bar should certainly go there). This one still stupefies me because it's a deviation from the other builds. It certainly should be documented. Did you document that a fullscreen NS screen doesn't have a toolbar either? BTW, I meanwhile wrote some code to resize and move undecorated frames with the mouse. For this purpose I need some mouse pointers indicating that a frame corner (not a frame edge) can be dragged. Under X I use XC_top_left_corner, XC_top_right_corner, ... On Windows I use the IDC_SIZENWSE and IDC_SIZENESW arrows. I have not found any equivalent for NS. How does NS indicate that the corner of a decorated frame can be dragged when the mouse is over it? Thanks for all your work, martin