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>
> Cc: stefankangas <at> gmail.com, 76120 <at> debbugs.gnu.org, alvaro <at> xenodium.com
> Date: Tue, 11 Feb 2025 18:34:13 +0200
>
> > 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.
No, the context menu is not static. For example, in the case of
Dired, it depends on the type of the file on which the user clicks.
So we have this functionality, we just didn't call it "share".
And if you still disagree, then let's agree to disagree, because we
already repeat ourselves.
This bug report was last modified 20 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.