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

Previous Next

Full log

Message #241 received at 76120 <at> debbugs.gnu.org (full text, mbox):

From: Björn Bidar <bjorn.bidar <at> thaodan.de>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 76120 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, alvaro <at> xenodium.com,
 stefankangas <at> gmail.com
Subject: Re: bug#76120: [PATCH] Expose the native sharing dialog (macOS)
Date: Thu, 13 Feb 2025 19:53:02 +0200

Po Lu <luangruo <at> yahoo.com> writes:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> From: Po Lu <luangruo <at> yahoo.com>
>>> Cc: bjorn.bidar <at> thaodan.de,  76120 <at> debbugs.gnu.org,  alvaro <at> xenodium.com,
>>>   stefankangas <at> gmail.com
>>> Date: Thu, 13 Feb 2025 16:12:54 +0800
>>> 
>>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>> 
>>> But we're not judging features by intimate details, and we won't have to
>>> remove the MS-Windows or DJGPP ports, because they create no incentive
>>> for users to migrate to MS-Windows or MS-DOS, in contrast to user-facing
>>> amenities provided by the operating system's GUI.
>>
>> That's your opinion, and you are entitled to it.  But it doesn't mean
>> it is universally true: how can we know what does and doesn't give
>> users incentives?
>>
>> I'm having hard time to believe that seeing "Share" is such an
>> incentive.
>
> I'm sure you'll agree that it is much more plausible for this to be an
> incentive than for a choice of thread library or DOS extender, which
> makes not a whit of a difference in actually running Emacs.  At any
> rate, this sentiment is everywhere to be found in on-line Emacs forums
> and chatrooms, and you need look no further than the popularity of the
> Carbon Emacs port, which is integrated with the Mac OS dictionary, share
> dialog, and animation framework.  Minor frivolities such as this do play
> an active role in enticing users to proprietary operating systems, and
> we cannot be consistent without categorically refusing to endorse them.
>
> And no, personally, I would not be moved by a Share dialog.
>
>>> (In fact I've lately discovered that it is FreeDOS where the Emacs
>>> port is most useful, and that operating system is 100% Free
>>> Software.)
>>
>> Try to count how many users of DJGPP Emacs actually do that on
>> FreeDOS.
>
> [...]
>
>>> We decide whether to reject features by the probability that they
>>> will induce users to another, proprietary, operating system.  The
>>> fact that Emacs's GUI backend executes in threads created by
>>> proprietary C runtime alone is clearly not applicable to this
>>> criterion, but GUI file sharing capabilities are.  The rather when
>>> they amount to an endorsement of a proprietary file sharing service.
>>
>> You are being subjective here because you want to make a point.
>
> Then, in the spirit of your question above, I ask, how many people will
> agree that being able to link Emacs against a particular C runtime and
> threading library will prepossesses users towards a new operating
> system?
>
>>> > Emacs's architecture and expectations from the underlying platform are
>>> > so Posix-centric that emulating them without resorting to proprietary
>>> > system-specific mechanisms is practically impossible.  Anyone who
>>> > demands us to avoid such interfaces and mechanisms basically tells us
>>> > to stop supporting those systems in a way that makes Emacs useful and
>>> > its features reasonably portable.
>>> 
>>> Mac OS is a POSIX system, just as much as GNU/Linux, if not more.
>>
>> Not in its GUI system.
>
> If so, how is POSIX relevant at all?  POSIX standardizes no windowing
> system, and those POSIX-portable windowing systems which Emacs does
> support on GNU/Linux systems are equally functional on Mac OS, not to
> mention such non-POSIX systems as OpenVMS, and even MS-DOS.

>>> We are speaking of user-visible productivity features provided by
>>> the GUI, not internal porting details, and I find it difficult to
>>> accept that a one-click interface to "cloud" file storage and to the
>>> iPhone Simulator is fundamental to Emacs's architecture or way of
>>> life, as it were.
>>
>> It is neither fundamental nor an incentive to migrate.
>
> The implication I was addressing was that a Share dialog could be
> equally fundamental to Emacs as the POSIX `open' or `fstat' system
> calls.  Moreover, it _is_ capable of being such an incentive, or this
> patch would not exist.

I think the difficulty to come to a conscious could be related to that
this is one of the features coming from mobile platform which has
different UX implications which my be not apparent without trying them
by oneself first or putting themselves in the POV of a user who might
want to use these. The documentation that is available shows the
differences also.

As mobile developer I know that these are essential for modern messaging
apps for example to forward content to others. Without them you have
safe the thing you want to share if you can, some mobile platforms such
as iOS make that hard, and then open the app you want to send the thing
with. That the feature in the case of macOS originates from iOS should
tell enough that this isn't just open, file access between apps on iOS
with the open command isn't possible as they can't reach out of their
sandbox.

Even for a desktop use case this can be quite useful although much less
required.

From this patch a user could for example write a document or share a
piece of code with another user on iMessage.

But lets turn this around: Would it be ok to implement this for the
Android port and lets say enable deeper integration with Google Drive
this way? 


>> So let's drop this futile argument, okay?  We have gobs of real work
>> on our hands.
>
> The easiest means of doing this would be to shelve this proposal till a
> comparable file-sharing system appears on the X desktop.

I agree this would relay on clarifying the semantics here.

Previous Next

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