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

Previous Next

Full log

View this message in rfc822 format

From: Björn Bidar <bjorn.bidar <at> thaodan.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76120 <at> debbugs.gnu.org, alvaro <at> xenodium.com, stefankangas <at> gmail.com, Visuwesh <visuweshm <at> gmail.com>
Subject: bug#76120: [PATCH] Expose the native sharing dialog (macOS)
Date: Tue, 11 Feb 2025 19:27:12 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Visuwesh <visuweshm <at> gmail.com>
>> Cc: Björn Bidar <bjorn.bidar <at> thaodan.de>,
>>   76120 <at> debbugs.gnu.org,
>>   alvaro <at> xenodium.com,  stefankangas <at> gmail.com
>> Date: Tue, 11 Feb 2025 20:25:35 +0530
>> 
>> [செவ்வாய் பிப்ரவரி 11, 2025] Eli Zaretskii wrote:
>> 
>> >> From: Björn Bidar <bjorn.bidar <at> thaodan.de>
>> >> Cc: Stefan Kangas <stefankangas <at> gmail.com>,  76120 <at> debbugs.gnu.org,  Eli
>> >>  Zaretskii <eliz <at> gnu.org>
>> >> Date: Tue, 11 Feb 2025 00:14:22 +0200
>> >> 
>> >> Since xdg-open isn't the same as "sharing" doesn't that only circumvent
>> >> the policy to not add functionality that is only supported on non-free
>> >> platforms?
>> >
>> > After all the discussions we had about the meaning of "sharing" in
>> > this case, what exactly makes you say xdg-open etc. are not equivalent
>> > to this "sharing"? just the fact that xdg-open doesn't have an option
>> > called literally "share", or something else?
>> >
>> > IOW, would you please describe the general functionality that the
>> > proposed "sharing" offers and xdg-open doesn't?
>> 
>> xdg-open simply opens the given file in the most suitable application
>> (if you ask me how it is determined, I can only tell it is dark arts).
>> So, `xdg-open ~/somepdf.pdf' will open the file in a PDF reader,
>
> That's "sharing" the file with that program.
>
>> `xdg-open ~/img.png' will open it in an image viewer, etc.
>
> That'd be "sharing" the image with the viewer.

No that's not the same that's opening it. Sharing in this context would
mean to send the file or specific parts of the current thing that the
user does such as an exerb of the current conversation that the user
has.

The Android developer documentation explains this quite well[1]:

> Android uses intents and their associated extras to let users share information quickly and easily using their favorite apps.

> Android provides two ways for users to share data between apps:

> The Android Sharesheet is primarily designed for sending content outside
> your app and/or directly to another user.
> For example, sharing a URL with a friend. The Android intent resolver is
> best suited for passing data to the next stage of a well-defined task.
> For example, opening a PDF from your app and letting users pick their
> preferred viewer.

The latter example is actually very similar to the open-with dialogues
in most desktop environments however the other examples are still
different.

The Android developer documentation is Android specific but explains the
general purpose of this kind of feature as all platforms follow the same
paradigm. 

The Apple documentation goes deeper into the UX part of the topic but
the intention is the same. [2]

Please read some of the documentation (I linked now and earlier) to understand this type of feature
better, it is not the same open-with it can do much more.

>
>> However, I
>> see an "Airdrop" option in the MacOS's share menu which AFAIK/U is akin
>> to "Share to device" which xdg-open cannot do.  For this, we need to
>> rely on KDE Connect or something similar for which Emacs does not have
>> support for OOTB.
>
> Every platform has specialized "sharing target" that other platforms
> don't.  That doesn't mean there's some functionality here that is
> specific to macOS.
>
> Moreover, our shell-command-do-open and other similar features,
> especially when accessed from a context menu, provide more
> possibilities than just xdg-open, see the "Guess shell command"
> portion of dired-aux.el.  They are also extensible.

The difference is that the point of this patch is to invoke the platform
specific sharing dialog and not relay on Emacs to decide how to interact
with the file 

And also as said now multiple times, the sharing dialogues do more than
just open the file but to somehow send it using a program, using
bluetooth, upload or whatever this not what any of the examples you have
do.


[1] https://developer.android.com/training/sharing/send
[2] https://developer.apple.com/design/human-interface-guidelines/collaboration-and-sharing

Previous Next

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