bug#24579: [PATCH] borderless windows on OS X

bug#24579: [PATCH] borderless windows on OS X

[Jay McCarthy]

[-- Attachment #1: Type: text/plain, Size: 1190 bytes --]

There are two popular Emacs patches for OS X that make all its windows
have no title bar:

https://github.com/nikhilunni/BorderlessEmacs

https://github.com/gwydirsam/emacs-mac-borderless

This patch integrates these by providing a variable
(ns-use-titled-windows) that allows this decision to be controlled at
runtime. The default is to use titles, like normal.

-- Some comments on the patch

This is my first Emacs patch. I hope it's okay.

The only difference between EmacsFSWindow and EmacsWindow is
explicitly telling OS X that the window can be the subject of focus,
which is required for borderless windows. (EmacsFSWindow has nothing
to do with being fullscreen.)

A toolbar can't be used without a title bar. If this isn't included,
then the console prints an error, but nothing bad happens. I think it
is a bit ugly to `if` out this, but not as ugly as an expected error
message.

I included a note in the Changelog, because it looks like all
variables like this get put in, but it could be removed from my
perspective... I have no need to satisfy my pride with my name in the
log. However, I didn't add anything to NEWS, because it seems to not
always mention things like this.

[-- Attachment #2: ns-use-titled-windows.patch --]
[-- Type: application/octet-stream, Size: 2744 bytes --]

diff --git a/ChangeLog.2 b/ChangeLog.2
index 3f3d558..b0bfdc6 100644
--- a/ChangeLog.2
+++ b/ChangeLog.2
@@ -1,3 +1,7 @@
+2016-09-30  Jay McCarthy  <jay.mccarthy@gmail.com)
+
+	* cus-start.el (all): Add ns-use-titled-windows
+
 2016-09-26  Nicolas Petton  <nicolas@petton.fr>
 
 	* Version 25.1 released.
diff --git a/lisp/cus-start.el b/lisp/cus-start.el
index d9ad0a5..9e52d0f 100644
--- a/lisp/cus-start.el
+++ b/lisp/cus-start.el
@@ -446,6 +446,7 @@ minibuffer-prompt-properties--setter
 	     (ns-use-native-fullscreen ns boolean "24.4")
              (ns-use-fullscreen-animation ns boolean "25.1")
              (ns-use-srgb-colorspace ns boolean "24.4")
+             (ns-use-titled-windows ns boolean "25.2")
 	     ;; process.c
 	     (delete-exited-processes processes-basics boolean)
 	     ;; syntax.c
diff --git a/src/nsterm.m b/src/nsterm.m
index 1b44a73..d013101 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -6775,11 +6775,13 @@ - (BOOL)isOpaque
   maximizing_resize = NO;
 #endif
 
-  win = [[EmacsWindow alloc]
+  win = [[EmacsFSWindow alloc]
             initWithContentRect: r
                       styleMask: (NSWindowStyleMaskResizable |
 #if MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_7
-                                  NSWindowStyleMaskTitled |
+                                  (ns_use_titled_windows ?
+                                   NSWindowStyleMaskTitled :
+                                   NSWindowStyleMaskBorderless) |
 #endif
                                   NSWindowStyleMaskMiniaturizable |
                                   NSWindowStyleMaskClosable)
@@ -6812,6 +6814,7 @@ - (BOOL)isOpaque
   [win setTitle: name];
 
   /* toolbar support */
+  if ( ns_use_titled_windows ) {
   toolbar = [[EmacsToolbar alloc] initForView: self withIdentifier:
                          [NSString stringWithFormat: @"Emacs Frame %d",
                                    ns_window_num]];
@@ -6833,6 +6836,7 @@ This avoids an extra clear and redraw (flicker) at frame creation.  */
   }
 #endif
   FRAME_TOOLBAR_HEIGHT (f) = 0;
+  }
 
   tem = f->icon_name;
   if (!NILP (tem))
@@ -8759,6 +8763,12 @@ Nil means use fullscreen the old (< 10.7) way.  The old way works better with
 This variable is ignored on OSX < 10.7 and GNUstep.  */);
   ns_use_srgb_colorspace = YES;
 
+  DEFVAR_BOOL ("ns-use-titled-windows", ns_use_titled_windows,
+     doc: /*Non-nil means to include a title on windows.  Nil means to
+omit the title on OSX >= 10.7.  This variable is ignored on OSX <
+10.7.  Default is t.  */);
+  ns_use_titled_windows = YES;
+
   /* TODO: move to common code */
   DEFVAR_LISP ("x-toolkit-scroll-bars", Vx_toolkit_scroll_bars,
 	       doc: /* Which toolkit scroll bars Emacs uses, if any.

bug#24579: [PATCH] borderless windows on OS X

[martin rudalics]

 > There are two popular Emacs patches for OS X that make all its windows
 > have no title bar:
 >
 > https://github.com/nikhilunni/BorderlessEmacs
 >
 > https://github.com/gwydirsam/emacs-mac-borderless
 >
 > This patch integrates these by providing a variable
 > (ns-use-titled-windows) that allows this decision to be controlled at
 > runtime. The default is to use titles, like normal.

Thank you.  I have a couple of questions:

(1) Is there a way to mix behaviors in one and the same session - that
is have at the same time a window with a title bar and one without?
It's possible under X and Windows as can be seen with tooltip frames.

(2) Is there an option to draw borders and, if so, borders of different
width on a borderless frame?  Latter are available via X but not on
Windows.

(3) IIUC setting your option does not toggle titles/borders on existing
frames.  Would it be possible to do so?  We could do that on Windows but
it seems impossible with GNU/Linux window managers.

Thanks again, martin

bug#24579: [PATCH] borderless windows on OS X

[Jay McCarthy]

On Sat, Oct 1, 2016 at 4:44 AM, martin rudalics <rudalics@gmx.at> wrote:
>> There are two popular Emacs patches for OS X that make all its windows
>> have no title bar:
>>
>> https://github.com/nikhilunni/BorderlessEmacs
>>
>> https://github.com/gwydirsam/emacs-mac-borderless
>>
>> This patch integrates these by providing a variable
>> (ns-use-titled-windows) that allows this decision to be controlled at
>> runtime. The default is to use titles, like normal.
>
> Thank you.  I have a couple of questions:
>
> (1) Is there a way to mix behaviors in one and the same session - that
> is have at the same time a window with a title bar and one without?
> It's possible under X and Windows as can be seen with tooltip frames.

Yes, because as implemented the variable only affects new frames, so
you can switch it on and off as you create frames to get both styles.
Thus, it could be a frame parameter as well. I didn't do it this way
because I personally want it to be a global setting and because I
didn't see the existing window creation code looking at the frame
parameter alist and I didn't look around the file much to get a bigger
picture of how it works.

> (2) Is there an option to draw borders and, if so, borders of different
> width on a borderless frame?  Latter are available via X but not on
> Windows.

Yes, I believe that the

setContentBorderThickness:forEdge:

function on the win object would let you do that, but I haven't test
that. I know that iTerm2's title-less option gives the ability to add
a border, but I worry it is implement with a custom renderer.

https://developer.apple.com/reference/appkit/nswindow/1419541-setcontentborderthickness?language=objc

> (3) IIUC setting your option does not toggle titles/borders on existing
> frames.  Would it be possible to do so?  We could do that on Windows but
> it seems impossible with GNU/Linux window managers.

It is possible to do that with [win setStyleMask:
NSBorderlessWindowMask], so it would be conceivable to add some
functions that would flip that setting on real frames. Although, I
don't see a way to go from an Emacs frame structure to the window
object. So, this seems like it would be a big patch (because you'd
want to do it in as cross-platform a way as possible) and different
than this one, so I hope the current patch is judged independently.

> Thanks again, martin

FWIW, I am not an OS X developer, so I don't know all the ins-and-outs of this.

My preference would be for this patch to go in if someone isn't going
to immediately do the frame parameter thing, because I don't have the
bandwidth to do it, I don't think.

Jay

-- 
Jay McCarthy
Associate Professor
PLT @ CS @ UMass Lowell
http://jeapostrophe.github.io

           "Wherefore, be not weary in well-doing,
      for ye are laying the foundation of a great work.
And out of small things proceedeth that which is great."
                          - D&C 64:33

bug#24579: [PATCH] borderless windows on OS X

[martin rudalics]

 >> (1) Is there a way to mix behaviors in one and the same session - that
 >> is have at the same time a window with a title bar and one without?
 >> It's possible under X and Windows as can be seen with tooltip frames.
 >
 > Yes, because as implemented the variable only affects new frames, so
 > you can switch it on and off as you create frames to get both styles.
 > Thus, it could be a frame parameter as well. I didn't do it this way
 > because I personally want it to be a global setting and because I
 > didn't see the existing window creation code looking at the frame
 > parameter alist and I didn't look around the file much to get a bigger
 > picture of how it works.

So once installed, binding your variable around ‘make-frame’ calls
should do the trick, I presume.

 >> (2) Is there an option to draw borders and, if so, borders of different
 >> width on a borderless frame?  Latter are available via X but not on
 >> Windows.
 >
 > Yes, I believe that the
 >
 > setContentBorderThickness:forEdge:
 >
 > function on the win object would let you do that, but I haven't test
 > that. I know that iTerm2's title-less option gives the ability to add
 > a border, but I worry it is implement with a custom renderer.
 >
 > https://developer.apple.com/reference/appkit/nswindow/1419541-setcontentborderthickness?language=objc
 >

In my experience, completely border-less frames are disorienting unless
they completely fill the display.

 >> (3) IIUC setting your option does not toggle titles/borders on existing
 >> frames.  Would it be possible to do so?  We could do that on Windows but
 >> it seems impossible with GNU/Linux window managers.
 >
 > It is possible to do that with [win setStyleMask:
 > NSBorderlessWindowMask], so it would be conceivable to add some
 > functions that would flip that setting on real frames. Although, I
 > don't see a way to go from an Emacs frame structure to the window
 > object. So, this seems like it would be a big patch (because you'd
 > want to do it in as cross-platform a way as possible)

It wouldn't be done anyway because it would fail on GNU/Linux.

 > and different
 > than this one, so I hope the current patch is judged independently.

I cannot test this because I don't use OS X.  So anyone who is able to
judge this, please disregard my questions and the corresponding answers.

 >> Thanks again, martin
 >
 > FWIW, I am not an OS X developer, so I don't know all the ins-and-outs of this.
 >
 > My preference would be for this patch to go in if someone isn't going
 > to immediately do the frame parameter thing, because I don't have the
 > bandwidth to do it, I don't think.

No need for the frame parameter thing.  It's more distracting than
doing any good.

Thanks for answering, martin

bug#24579: [PATCH] borderless windows on OS X

[Jay McCarthy]

On Sat, Oct 1, 2016 at 9:41 AM, martin rudalics <rudalics@gmx.at> wrote:
>>> (1) Is there a way to mix behaviors in one and the same session - that
>>> is have at the same time a window with a title bar and one without?
>>> It's possible under X and Windows as can be seen with tooltip frames.
>
> So once installed, binding your variable around ‘make-frame’ calls
> should do the trick, I presume.

Yes

> In my experience, completely border-less frames are disorienting unless
> they completely fill the display.

I know what you mean, but I use this plus Spectacle to simulate a
tiling window manager on OS X, so it's fine. The title bar doesn't add
anything for me, because the modeline says the file name and I use the
WM key bindings to move and resize the window.

Jay

-- 
Jay McCarthy
Associate Professor
PLT @ CS @ UMass Lowell
http://jeapostrophe.github.io

           "Wherefore, be not weary in well-doing,
      for ye are laying the foundation of a great work.
And out of small things proceedeth that which is great."
                          - D&C 64:33

bug#24579: [PATCH] borderless windows on OS X

[martin rudalics]

 >> In my experience, completely border-less frames are disorienting unless
 >> they completely fill the display.
 >
 > I know what you mean, but I use this plus Spectacle to simulate a
 > tiling window manager on OS X, so it's fine. The title bar doesn't add
 > anything for me, because the modeline says the file name and I use the
 > WM key bindings to move and resize the window.

Once your patch has been applied, please consider implementing the
‘border-width’ frame parameter for such "border-less" frames.  Even if
you don't use it, we could get a more unified behavior of such frames on
all our platforms.

Thanks, martin

bug#24579: [PATCH] borderless windows on OS X

[Jay McCarthy]

I was dropped from the reply-chain, but I noticed there were some
messages on the mailing list after our discussion that seem to imply
this will languish uncommitted. Is there anything I can do to prevent
that?

Jay

On Sun, Oct 2, 2016 at 4:29 AM, martin rudalics <rudalics@gmx.at> wrote:
>>> In my experience, completely border-less frames are disorienting unless
>>> they completely fill the display.
>>
>> I know what you mean, but I use this plus Spectacle to simulate a
>> tiling window manager on OS X, so it's fine. The title bar doesn't add
>> anything for me, because the modeline says the file name and I use the
>> WM key bindings to move and resize the window.
>
> Once your patch has been applied, please consider implementing the
> ‘border-width’ frame parameter for such "border-less" frames.  Even if
> you don't use it, we could get a more unified behavior of such frames on
> all our platforms.
>
> Thanks, martin
>



-- 
Jay McCarthy
Associate Professor
PLT @ CS @ UMass Lowell
http://jeapostrophe.github.io

           "Wherefore, be not weary in well-doing,
      for ye are laying the foundation of a great work.
And out of small things proceedeth that which is great."
                          - D&C 64:33

bug#24579: [PATCH] borderless windows on OS X

[martin rudalics]

 > I was dropped from the reply-chain,

Sorry for that, I didn't notice.  Could people please care that the
submitter of a patch is not dropped from the list of recipients.  IMHO
this is the least thing we should do even we happen to dislike a patch.

 > but I noticed there were some
 > messages on the mailing list after our discussion that seem to imply
 > this will languish uncommitted. Is there anything I can do to prevent
 > that?

There were objections because people think that the patch does something
on OS X which is not possible on free systems.  I presented my arguments
in favor of its application but since I cannot test it I cannot apply it
either.

Could one of our maintainers kindly decide how to proceed?

TIA, martin

bug#24579: [PATCH] borderless windows on OS X

[Jay McCarthy]

On Thu, Oct 13, 2016 at 2:36 PM, martin rudalics <rudalics@gmx.at> wrote:
>> but I noticed there were some
>> messages on the mailing list after our discussion that seem to imply
>> this will languish uncommitted. Is there anything I can do to prevent
>> that?
>
> There were objections because people think that the patch does something
> on OS X which is not possible on free systems.  I presented my arguments
> in favor of its application but since I cannot test it I cannot apply it
> either.

This sounds like a holy war and not a technical argument about the patch.

As far as I can tell, most of the 'ns-' variables only work on OS X
and their documentation only references versions of OS X and not
versions of GNUstep. GNUstep clearly is trying to mimic OS X on this
API, so if the attribute masks don't work, that's an error in GNUstep,
rather than something Emacs shouldn't do.

-- 
Jay McCarthy
Associate Professor
PLT @ CS @ UMass Lowell
http://jeapostrophe.github.io

           "Wherefore, be not weary in well-doing,
      for ye are laying the foundation of a great work.
And out of small things proceedeth that which is great."
                          - D&C 64:33

bug#24579: [PATCH] borderless windows on OS X

[Alan Third]

On Fri, Sep 30, 2016 at 09:31:09PM -0400, Jay McCarthy wrote:
> There are two popular Emacs patches for OS X that make all its windows
> have no title bar:
> 
> https://github.com/nikhilunni/BorderlessEmacs
> 
> https://github.com/gwydirsam/emacs-mac-borderless
> 
> This patch integrates these by providing a variable
> (ns-use-titled-windows) that allows this decision to be controlled at
> runtime. The default is to use titles, like normal.

I’d prefer a variable name more like ‘ns-use-titlebar’, as
‘titled-windows’ doesn’t mean very much to me.

> -- Some comments on the patch
> 
> This is my first Emacs patch. I hope it's okay.
> 
> The only difference between EmacsFSWindow and EmacsWindow is
> explicitly telling OS X that the window can be the subject of focus,
> which is required for borderless windows. (EmacsFSWindow has nothing
> to do with being fullscreen.)

I’d no idea about this, do we even need both types?

> I included a note in the Changelog, because it looks like all
> variables like this get put in, but it could be removed from my
> perspective... I have no need to satisfy my pride with my name in the
> log. However, I didn't add anything to NEWS, because it seems to not
> always mention things like this.

The changelog is automatically updated from the git repository log, as
I understand it. We’ll commit it using your name so you’ll be credited
anyway. :)

Also, I don’t think this patch will be included before Emacs 26.1 as
it’s a new feature, not a bug fix, so the entry in cus-start.el may
need to read 26.1.

This one’s a real nit‐pick: I don’t like the version number being on
the next line in the variable doctype. I don’t see any reason why it
can’t be moved up on to the previous line next to the greater‐than
sign. And also change ‘windows’ to ‘frames’ and ‘title’ to ‘titlebar’.

I can’t see anything wrong other than my little moans above, and it
certainly looks like it does what it’s supposed to do. Thanks for
doing this.
-- 
Alan Third

bug#24579: [PATCH] borderless windows on OS X

[Jay McCarthy]

[-- Attachment #1: Type: text/plain, Size: 2719 bytes --]

I've attached a modified version with your requests.

Regarding EmacsWindow, I think it would be good to keep it around and
separate, so I didn't remove it in the patch.

Jay

On Sat, Oct 1, 2016 at 5:26 PM, Alan Third <alan@idiocy.org> wrote:
> On Fri, Sep 30, 2016 at 09:31:09PM -0400, Jay McCarthy wrote:
>> There are two popular Emacs patches for OS X that make all its windows
>> have no title bar:
>>
>> https://github.com/nikhilunni/BorderlessEmacs
>>
>> https://github.com/gwydirsam/emacs-mac-borderless
>>
>> This patch integrates these by providing a variable
>> (ns-use-titled-windows) that allows this decision to be controlled at
>> runtime. The default is to use titles, like normal.
>
> I’d prefer a variable name more like ‘ns-use-titlebar’, as
> ‘titled-windows’ doesn’t mean very much to me.
>
>> -- Some comments on the patch
>>
>> This is my first Emacs patch. I hope it's okay.
>>
>> The only difference between EmacsFSWindow and EmacsWindow is
>> explicitly telling OS X that the window can be the subject of focus,
>> which is required for borderless windows. (EmacsFSWindow has nothing
>> to do with being fullscreen.)
>
> I’d no idea about this, do we even need both types?
>
>> I included a note in the Changelog, because it looks like all
>> variables like this get put in, but it could be removed from my
>> perspective... I have no need to satisfy my pride with my name in the
>> log. However, I didn't add anything to NEWS, because it seems to not
>> always mention things like this.
>
> The changelog is automatically updated from the git repository log, as
> I understand it. We’ll commit it using your name so you’ll be credited
> anyway. :)
>
> Also, I don’t think this patch will be included before Emacs 26.1 as
> it’s a new feature, not a bug fix, so the entry in cus-start.el may
> need to read 26.1.
>
> This one’s a real nit‐pick: I don’t like the version number being on
> the next line in the variable doctype. I don’t see any reason why it
> can’t be moved up on to the previous line next to the greater‐than
> sign. And also change ‘windows’ to ‘frames’ and ‘title’ to ‘titlebar’.
>
> I can’t see anything wrong other than my little moans above, and it
> certainly looks like it does what it’s supposed to do. Thanks for
> doing this.
> --
> Alan Third



-- 
Jay McCarthy
Associate Professor
PLT @ CS @ UMass Lowell
http://jeapostrophe.github.io

           "Wherefore, be not weary in well-doing,
      for ye are laying the foundation of a great work.
And out of small things proceedeth that which is great."
                          - D&C 64:33

[-- Attachment #2: 0001-Add-ns-use-titlebar.patch --]
[-- Type: application/octet-stream, Size: 2736 bytes --]

From 9dc69fa971b85617f2a1af638e2ea41aeea06862 Mon Sep 17 00:00:00 2001
From: Jay McCarthy <jay.mccarthy@gmail.com>
Date: Fri, 30 Sep 2016 21:08:27 -0400
Subject: [PATCH 1/1] Add ns-use-titlebar

---
 lisp/cus-start.el |  1 +
 src/nsterm.m      | 14 ++++++++++++--
 2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/lisp/cus-start.el b/lisp/cus-start.el
index d9ad0a5..67bbba6 100644
--- a/lisp/cus-start.el
+++ b/lisp/cus-start.el
@@ -446,6 +446,7 @@ minibuffer-prompt-properties--setter
 	     (ns-use-native-fullscreen ns boolean "24.4")
              (ns-use-fullscreen-animation ns boolean "25.1")
              (ns-use-srgb-colorspace ns boolean "24.4")
+             (ns-use-title-bar ns boolean "26.1")
 	     ;; process.c
 	     (delete-exited-processes processes-basics boolean)
 	     ;; syntax.c
diff --git a/src/nsterm.m b/src/nsterm.m
index 1b44a73..cd78294 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -6775,11 +6775,13 @@ - (BOOL)isOpaque
   maximizing_resize = NO;
 #endif
 
-  win = [[EmacsWindow alloc]
+  win = [[EmacsFSWindow alloc]
             initWithContentRect: r
                       styleMask: (NSWindowStyleMaskResizable |
 #if MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_7
-                                  NSWindowStyleMaskTitled |
+                                  (ns_use_titlebar ?
+                                   NSWindowStyleMaskTitled :
+                                   NSWindowStyleMaskBorderless) |
 #endif
                                   NSWindowStyleMaskMiniaturizable |
                                   NSWindowStyleMaskClosable)
@@ -6812,6 +6814,7 @@ - (BOOL)isOpaque
   [win setTitle: name];
 
   /* toolbar support */
+  if ( ns_use_titlebar ) {
   toolbar = [[EmacsToolbar alloc] initForView: self withIdentifier:
                          [NSString stringWithFormat: @"Emacs Frame %d",
                                    ns_window_num]];
@@ -6833,6 +6836,7 @@ This avoids an extra clear and redraw (flicker) at frame creation.  */
   }
 #endif
   FRAME_TOOLBAR_HEIGHT (f) = 0;
+  }
 
   tem = f->icon_name;
   if (!NILP (tem))
@@ -8759,6 +8763,12 @@ Nil means use fullscreen the old (< 10.7) way.  The old way works better with
 This variable is ignored on OSX < 10.7 and GNUstep.  */);
   ns_use_srgb_colorspace = YES;
 
+  DEFVAR_BOOL ("ns-use-titlebar", ns_use_titlebar,
+     doc: /*Non-nil means to include a titlebar on frames.  Nil means
+to omit the titlebar on OSX >= 10.7.
+This variable is ignored on OSX < 10.7.  Default is t.  */);
+  ns_use_titlebar = YES;
+
   /* TODO: move to common code */
   DEFVAR_LISP ("x-toolkit-scroll-bars", Vx_toolkit_scroll_bars,
 	       doc: /* Which toolkit scroll bars Emacs uses, if any.
-- 
2.10.0

bug#24579: [PATCH] borderless windows on OS X

[Alan Third]

On Sat, Oct 01, 2016 at 06:18:00PM -0400, Jay McCarthy wrote:
> I've attached a modified version with your requests.
> 
> Regarding EmacsWindow, I think it would be good to keep it around and
> separate, so I didn't remove it in the patch.

Looks good, so if nobody objects I’ll push it to master in a few days.

I think this is small enough that it will be exempt from copyright
assignment, but if you send in any more patches you’ll have to get the
paperwork signed.

Thank you!
-- 
Alan Third

bug#24579: [PATCH] borderless windows on OS X

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 699 bytes --]

On 2016-10-01 19:04, Alan Third wrote:
> On Sat, Oct 01, 2016 at 06:18:00PM -0400, Jay McCarthy wrote:
>> I've attached a modified version with your requests.
>>
>> Regarding EmacsWindow, I think it would be good to keep it around and
>> separate, so I didn't remove it in the patch.
> 
> Looks good, so if nobody objects I’ll push it to master in a few days.

This looks good indeed, but we don't have the same thing exposed to ELisp for GNU/Linux, do we? (https://emacs.stackexchange.com/questions/20167/how-do-i-create-a-borderless-frame was about this).  Isn't that a prerequisite before merging this feature?

Or am I misunderstanding what the patch does?

Cheers,
Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#24579: [PATCH] borderless windows on OS X

[martin rudalics]

 > This looks good indeed, but we don't have the same thing exposed to
 > ELisp for GNU/Linux, do we?

We do: Emacs' native tooltip frames with a ‘border-width’ of zero should
accomplish precisely that.

 > (https://emacs.stackexchange.com/questions/20167/how-do-i-create-a-borderless-frame
 > was about this).

The recipes there don't work: The ‘border-width’ parameter is usually
ignored by the window manager for "normal" frames and replaced by the
standard border.  You have to create a CWOverrideRedirect window - a
frame that is _not_ handled by the window manager.

 > Isn't that a prerequisite before merging this
 > feature?

It would be.  But in fact the patch has NS still lag behind slightly
because it doesn't allow to set the border width.

martin

bug#24579: [PATCH] borderless windows on OS X

[Alan Third]

On Sun, Oct 02, 2016 at 10:30:26AM +0200, martin rudalics wrote:
> > This looks good indeed, but we don't have the same thing exposed to
> > ELisp for GNU/Linux, do we?
> 
> We do: Emacs' native tooltip frames with a ‘border-width’ of zero should
> accomplish precisely that.

Do we not have them in NS too? If so that would make this patch rather
superfluous.

> > Isn't that a prerequisite before merging this
> > feature?

I hadn’t even really thought about this, I figured that on GNU/Linux
systems you can get the same behaviour through the window manager, but
that’s impossible on OS X. I can see the other argument, though.

I’ll hold off committing until there’s some sort of agreement.
-- 
Alan Third

bug#24579: [PATCH] borderless windows on OS X

[martin rudalics]

 >> We do: Emacs' native tooltip frames with a ‘border-width’ of zero should
 >> accomplish precisely that.
 >
 > Do we not have them in NS too? If so that would make this patch rather
 > superfluous.

NS tooltips are toolkit based.  To my knowledge you can't emulate
neither "normal frames" nor Emacs' native tooltip frames with them.

 > I hadn’t even really thought about this, I figured that on GNU/Linux
 > systems you can get the same behaviour through the window manager, but
 > that’s impossible on OS X. I can see the other argument, though.

Which one is the "other argument"?

 > I’ll hold off committing until there’s some sort of agreement.

As I stated earlier, my remarks should be disregarded in any form of such
agreement.

martin

bug#24579: [PATCH] borderless windows on OS X

[Alan Third]

On Sun, Oct 02, 2016 at 06:39:25PM +0200, martin rudalics wrote:
> > I hadn’t even really thought about this, I figured that on GNU/Linux
> > systems you can get the same behaviour through the window manager, but
> > that’s impossible on OS X. I can see the other argument, though.
> 
> Which one is the "other argument"?

That we’re doing it from within Emacs, so it’s an Emacs feature, and
therefore needs to be available on a Free platform first.

(For the record, I tested this patch with GNUStep on GNU/Linux, which
I imagine counts as Free, and it didn’t remove the titlebar, even with
some fiddling. That may have been my WM refusing to play along,
though.)

> > I’ll hold off committing until there’s some sort of agreement.
> 
> As I stated earlier, my remarks should be disregarded in any form of such
> agreement.

I don’t feel I understand the politics enough to make any useful
contribution.
-- 
Alan Third

bug#24579: [PATCH] borderless windows on OS X

[martin rudalics]

 > That we’re doing it from within Emacs, so it’s an Emacs feature, and
 > therefore needs to be available on a Free platform first.

I hope I answered this one.  You can create a borderless frame without
titlebar on GNU/Linux - it's the native Emacs tooltip frame.

 > (For the record, I tested this patch with GNUStep on GNU/Linux, which
 > I imagine counts as Free, and it didn’t remove the titlebar, even with
 > some fiddling. That may have been my WM refusing to play along,
 > though.)

My GNUStep Emacs is dysfunctional for quite some time so I wouldn't even
try.

martin

bug#24579: [PATCH] borderless windows on OS X

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 438 bytes --]

On 2016-10-02 14:10, martin rudalics wrote:
>> That we’re doing it from within Emacs, so it’s an Emacs feature, and
>> therefore needs to be available on a Free platform first.
> 
> I hope I answered this one.  You can create a borderless frame without
> titlebar on GNU/Linux - it's the native Emacs tooltip frame.

Can you really?  More precisely, can you create and display more than one at a time?

Cheers,
Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#24579: [PATCH] borderless windows on OS X

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 832 bytes --]

On 2016-10-02 04:30, martin rudalics wrote:
>> This looks good indeed, but we don't have the same thing exposed to
>> ELisp for GNU/Linux, do we?
> 
> We do: Emacs' native tooltip frames with a ‘border-width’ of zero should
> accomplish precisely that.

I meant the feature to create an arbitrary frame without a border, from ELisp.  We don't have this, AFAICT.

>> (https://emacs.stackexchange.com/questions/20167/how-do-i-create-a-borderless-frame
>> was about this).
> 
> The recipes there don't work: The ‘border-width’ parameter is usually
> ignored by the window manager for "normal" frames and replaced by the
> standard border.  You have to create a CWOverrideRedirect window - a
> frame that is _not_ handled by the window manager. 

Right.  Do we have a way to do this from ELisp?

Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#24579: [PATCH] borderless windows on OS X

[martin rudalics]

 >> We do: Emacs' native tooltip frames with a ‘border-width’ of zero should
 >> accomplish precisely that.
 >
 > I meant the feature to create an arbitrary frame without a border, from ELisp.  We don't have this, AFAICT.

What is an arbitrary frame?  A frame without the window manager's title
bar can't be dragged with the mouse.  A frame without an external border
can't be resized with the mouse.

 >> The recipes there don't work: The ‘border-width’ parameter is usually
 >> ignored by the window manager for "normal" frames and replaced by the
 >> standard border.  You have to create a CWOverrideRedirect window - a
 >> frame that is _not_ handled by the window manager.
 >
 > Right.  Do we have a way to do this from ELisp?

Add a (border-width . 0) entry to `tooltip-frame-parameters' and show a
native Emacs tooltip.

martin

bug#24579: [PATCH] borderless windows on OS X

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 1397 bytes --]

On 2016-10-02 12:39, martin rudalics wrote:
>>> We do: Emacs' native tooltip frames with a ‘border-width’ of zero should
>>> accomplish precisely that.
>>
>> I meant the feature to create an arbitrary frame without a border, from ELisp.  We don't have this, AFAICT.
> 
> What is an arbitrary frame?  A frame without the window manager's title
> bar can't be dragged with the mouse.  A frame without an external border
> can't be resized with the mouse.

Doesn't that depend on the window manager? For example, I can press Meta while dragging a frame to move it on my distro.
By arbitrary frame, I meant the kind of frame that you can create with make-frame (as opposed to a tooltip frame).  IIUC, the main difference is whether you can create multiple of them at the same time.

>>> The recipes there don't work: The ‘border-width’ parameter is usually
>>> ignored by the window manager for "normal" frames and replaced by the
>>> standard border.  You have to create a CWOverrideRedirect window - a
>>> frame that is _not_ handled by the window manager.
>>
>> Right.  Do we have a way to do this from ELisp?
> 
> Add a (border-width . 0) entry to `tooltip-frame-parameters' and show a
> native Emacs tooltip.

Can we show multiple of these at once? I thought we were limited to having a single one shown at any time, unlike regular frames.

Cheers,
Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#24579: [PATCH] borderless windows on OS X

[martin rudalics]

 > Doesn't that depend on the window manager? For example, I can press
 > Meta while dragging a frame to move it on my distro.

Whatever we do has to work with most window managers.  If most window
managers allow Meta dragging, we can drop this issue.

 > By arbitrary
 > frame, I meant the kind of frame that you can create with make-frame
 > (as opposed to a tooltip frame).  IIUC, the main difference is whether
 > you can create multiple of them at the same time.

Agreed.  However, such frames will never be as functional as a standard
graphical frame which is controlled by the window manager.  We have to
make a checklist for what we expect such frames to accomplish and what
Emacs has to do to manage them.

But remember that the topic of the present thread is to implement frames
without titlebars and external borders on OS X.  We can, in principle,
do that on GNU/Linux and Windows.  We cannot do that, so far, on OS X.

 >> Add a (border-width . 0) entry to `tooltip-frame-parameters' and show a
 >> native Emacs tooltip.
 >
 > Can we show multiple of these at once? I thought we were limited to having a single one shown at any time, unlike regular frames.

Yes, there can be only one tooltip frame.  I posted a feature to show
multiple such frames in the "Latest master broken on Cocoa/NS" thread
but IIRC never got a response from you.

martin

bug#24579: [PATCH] borderless windows on OS X

[Alan Third]

Jay McCarthy <jay.mccarthy@gmail.com> writes:

> There are two popular Emacs patches for OS X that make all its windows
> have no title bar:

This has now been implemented in a cross-platform manner. See here for
more info:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25408#77

-- 
Alan Third