GNU bug report logs -
#76120
[PATCH] Expose the native sharing dialog (macOS)
Previous Next
Full log
Message #77 received at 76120 <at> debbugs.gnu.org (full text, mbox):
> 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.
This bug report was last modified 4 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.