GNU bug report logs - #76120
[PATCH] Expose the native sharing dialog (macOS)

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alvaro Ramirez <alvaro <at> xenodium.com>
Cc: bjorn.bidar <at> thaodan.de, stefankangas <at> gmail.com, 76120 <at> debbugs.gnu.org
Subject: bug#76120: [PATCH] Expose the native sharing dialog (macOS)
Date: Mon, 10 Feb 2025 16:31:22 +0200

> From: Alvaro Ramirez <alvaro <at> xenodium.com>
> Cc: Björn Bidar <bjorn.bidar <at> thaodan.de>,
>   stefankangas <at> gmail.com,
>   76120 <at> debbugs.gnu.org
> Date: Mon, 10 Feb 2025 14:09:35 +0000
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > I think we should get our terminology right, because the "share"
> > business is replete with hype which muddies the waters.  In
> > particular, quite a few "sharing" options are another word with 
> > "open
> > with", and we already have that (see my other message 
> > up-thread).
> > Examples:
> >
> >   . "sharing" with a printer means printing, which is the same 
> >   as
> >     "opening" by a printer
> >   . "sharing" with an email program means sending as an email 
> >   message,
> >     which is the same as "opening" by a MUA
> >   . "sharing" a selection of text is the same a drag-n-drop the 
> >   text
> >     onto an application
> >
> > etc., etc.  So what exactly is the "sharing" we are talking 
> > about
> > here?  I very much hope that it doesn't just mean show a menu 
> > whose
> > caption says "Share with" (which would mean it's another 
> > hype)...
> 
> Thanks for highlighting this Eli. "Sharing" is indeed an 
> overloaded term and can invite unrelated discussion.
> 
> What's available in this macOS dialog is a context menu of 
> sorts. It more or less aggregates "open with", "send to", or "drag 
> and drop" for external (non-Emacs) applications.
> 
> My initial integration approached things by enumerating available 
> context actions from the system and pipe through existing Emacs 
> infrastructure (context-menu-mode or completing-read). However, 
> this route is a dead end on macOS as the API is now deprecated 
> https://developer.apple.com/documentation/appkit/nssharingservice/sharingservices(foritems:)?language=objc 
> in favor of using the picker dialog 
> https://developer.apple.com/documentation/appkit/nssharingservicepicker?language=objc 
> which is included in the current proposal.

Does an application have any control which contacts are shown in this
dialog?  If so, then I think you could make this dialog pop up as one
(system-specific) selections in the existing Emacs context menu, and
remove from the list the contacts that are already available in the
existing context menu.  If the application cannot control that list, I
think it's very bad, because it would mean the same contact will
appear more than once under different names.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.