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

Previous Next

Full log

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

From: Visuwesh <visuweshm <at> gmail.com>
To: Alvaro Ramirez <alvaro <at> xenodium.com>
Cc: 76120 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, stefankangas <at> gmail.com,
 rms <at> gnu.org, shipmints <at> gmail.com
Subject: Re: bug#76120: This feature is not about "sharing", or a "native"
 anything.
Date: Thu, 20 Feb 2025 23:29:02 +0530

[வியாழன் பிப்ரவரி 20, 2025] Alvaro Ramirez wrote:

> Visuwesh <visuweshm <at> gmail.com> writes:
> [...]
>> Thinking about this a bit more, I wonder if this and
>> send-to-handler-function should be unified?
>
> Ah, right. That was my initial approach. Splitting into two functions
> came later when I needed the context menu to be a little smarter and
> only show the "Send to..." menu if the required infrastructure is
> truly available.

We could check if send-to-handler-function is non-nil and ensure we set
a non-nil default value iff the share/send-to feature is available.

>> If s-t-h-f doesn't have
>> xdg-open in GNU/Linux, it could signal an error.  I don't see why
>> this
>> should be a defcustom, this isn't something the user should be
>> configuring IMO.  At least, as a user, I don't want to configure a
>> test
>> function such as this.
>
> I'm typically grateful for the variety of defcustom's available across
> packages. Most of them, I don't have to change as I'm happy with the
> defaults chosen by the author. My thinking here was to offer an
> appealing default, but offer optional customizations, should users
> chose to bring their own "Send to..." implementation. The KDE Connect
> integration you mentioned is a good example (if we don't end up
> bundling by default).

Sure.  It could be equally well be a defvar.  I just don't see why it
should be a defcustom.  But I won't insist on this.

>>>>> +(defcustom send-to-handler-function #'send-to--default-handler
>>>>> +  "A function handling `send-to' external routing.
>>>>> +
>>>>> +The function receives a list of items to send.
>>>>> +
>>>>> +Each item can be a either a filename or plain text."
>>
>> ...which leads me to: should we rather have separate handler
>> functions
>> instead of grouping everything together in a single big one?
>
> 24 lines of code is a big function? ;)

I confused this and send-to-context-items-function.  That said, it could
grow out of hand when we add support for other platforms/send-to
mechanisms.

>> The default value could depend on system-type and availability of
>> the
>> required binaries.  This would be easier for package developers and
>> users (e.g., a user could more easily choose between KDE Connect or
>> xdg-open).
>
> We can maybe consolidate configuration into a single variable (a list
> of handlers), but each handler would likely still need to implement at
> least two operations (supported-p + send).

I hope you will consider combining these two.  The default value could
check the existence of necessary conditions which would circumvent the
need for an extra supported-p.  If push comes to shove, the send
function could signal an error.  Provided that we have separate handler
function for each share-to mechanism.

Previous Next

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