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 18:34:13 +0200

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

>> From: Björn Bidar <bjorn.bidar <at> thaodan.de>
>> Cc: stefankangas <at> gmail.com,  76120 <at> debbugs.gnu.org,  alvaro <at> xenodium.com
>> Date: Mon, 10 Feb 2025 22:23:51 +0200
>> 
>> >   . "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
>> 
>> In this context the MUA would be opened with the to be shared file
>> in a new message window, removing the step in between opening and
>> attaching the file.
>> More like a mailto: link rather than manually "opening".
>
> I think you interpret "open" too literally.  In this case it is just a
> verb; in particular, it does NOT mean just starting the program.  It
> means telling the program to do its thing with the stuff that Emacs
> submits to it.

You seam to misunderstand me: If the program is started or doesn't
matter the point is that the interaction with the program to pass an
item to the program is curated between the programs. The programs in the
share menu offer predefined dialogues and actions which can be selected
by the user to interact with the file.

>> >   . "sharing" a selection of text is the same a drag-n-drop the text
>> >     onto an application
>> 
>> It's the same but the program which is the direction would receive the
>> input prepared by the sending program e.g. any kind of content not just
>> text.
>
> I was responding to the images posted, where the selection was plain
> text.  I realize that it's an example, but so are my examples.
>
>> > 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)...
>> 
>> Well it's certainly not another hype since a feature like it or similar
>> has been implemented across all major operating systems.
>
> (We just saw that GNU/Linux doesn't really implement it yet...)

I should have written desktop operating system but none the less Linux
isn't one unified platform. KDE has implemented the feature so KDE based
Linux distributions or those hat offer KDE could  fit into that category.

>> The point is that there's a direct interaction from the user in the
>> current program they use to programs offering methods of interaction so
>> kinda like open with but with a specific action in mind.
>
> That's the same idea that is behind shell-command-do-open.

>> E.g. instead of print menu there's a menu to show various actions
>> such as printing or forwarding the file. The purpose is that such action
>> are in central location instead of a button for every specific action
>> specific to each program.
>
> I didn't say anything about separate buttons.  We also have this in a
> central location: the context menu.
>
> So I still don't see the difference, except in terminology.

Please look at the link I posted a few mails eariler but KDE's Purpose
framework.
It contains a link with a few example screenshots, I added the link to
this mail too.

You can see that in the third screenshot from the top that in the
context menu there is an item called "Share".

The items are not static, each item in the list is populated by the
underlying framework, in this case KDE's Purpose, to fit the current
context.
Each share option has to accept the file or uri type of the current
context, the URI type matters for link sharing.

A share option could be open file in a program with a specific dialog or
an action such as upload file, paste to clipboard or send to device via
technology such as Bluetooth or app.
For the latter case a dialog to select the target device would open.

In contrast the regular context menu is mostly static and specific to
each application. E.g. to achieve the same feature using a context menu
without a share framework each item in the menu would have to be added
explicitly by Emacs for each platform.

[1] https://userbase.kde.org/Tips/Transfer_files_between_phone_and_PC_using_Wi-Fi

Previous Next

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