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
Subject: bug#76120: [PATCH] Expose the native sharing dialog (macOS)
Date: Tue, 11 Feb 2025 21:45:04 +0200

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

>> From: Björn Bidar <bjorn.bidar <at> thaodan.de>
>> Cc: alvaro <at> xenodium.com,  stefankangas <at> gmail.com,  76120 <at> debbugs.gnu.org
>> Date: Tue, 11 Feb 2025 19:14:30 +0200
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> > IOW, would you please describe the general functionality that the
>> > proposed "sharing" offers and xdg-open doesn't?
>> 
>> Sharing offers a list of specific action available to all program
>> using the framework e.g.
>> 
>> - Share using app, opens a dialog of the app to select the target
>>   where the file is supposed to go and in case the user confirms the
>>   target the file is send of, the dialog is closed.
>>   The specific application isn't opened at all or only exist as this
>>   sharing dialog or other desktop widgets with an application window in
>>   the classical sense.
>>   
>> - Send file using Bluetooth. Very similar to the example above except
>>   that the platforms or desktop environments Bluetooth Ui's file share
>>   dialog opens.
>> 
>> These two are not possible in xdg-open at all even if it would contain a
>> list of specific applications to choose from.
>
> Sending a file via a communication channel can be done in Emacs
> without xdg-open.  Our context menu already includes items that are
> not necessarily xdg-open (and users can extend that).

> And what an application does when some object is "shared" with it
> depends on the application and the object; opening a dialog is not
> necessary, and in many cases there's no dialog at all.
>
> More importantly, these capabilities are not special in any way, they
> are just brought together under the umbrella of "sharing", but each
> capability is simple and most of them are already available in Emacs.
> Which application or communications channel is used is immaterial for
> the purposes of this particular discussion.

Sure but the functionaity provided by Apple share API talks to the
operating system to pupulate the menu which isn't possible right now
on Linux outside of using the KDE Purpose API. The point is the
operating system integration which only would be available for macOS.

> So this argument that adding "share" somehow adds something on macOS
> features that are not available elsewhere is simply wrong.

If only want to add equivalent features why not add a menu entry which
uses xdg-open on Linux and open(1) on macOS? The open shell command on
macOS is the 100% equivalent to xdg-open on Linux.

https://ss64.com/mac/open.html

Previous Next

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