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

Previous Next

Full log

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

From: Alvaro Ramirez <alvaro <at> xenodium.com>
To: Visuwesh <visuweshm <at> gmail.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 22:14:56 +0000

Thanks for this Visuwesh.

Visuwesh <visuweshm <at> gmail.com> writes:

> [வியாழன் பிப்ரவரி 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.

This may sort itself out with a list of handlers. I'll have a play 
with it, though will wait a bit for other's feedback before the 
next patch iteration.

>>> 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.

Ah yes. I was thinking of defvar and defcustom as somewhat 
equivalent customization points. Defvar SGTM.

>>>>>> +(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.

Maybe. If it's not growing here, it'll grow somewhere else. Let's 
see how it pans out with the handler list. There may be 
suggestions from others. Let's see.

>
>>> 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.

If possible, I'd prefer hiding the "Send to..." menu item if the 
feature isn't supported on the platform. Signaling errors out of 
the box may not be a great first experience.

Previous Next

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