Can you please explain what use case do you have in mind? How do you usually use this feature in another MUA?

Technical stuff -- this is tricky to do in a cross-platform way. I've got no clue how it works on Windows or Mac, but a XDG-compatible system ("desktop Linux") usually uses `xdg-open` for accessing remote content, and that's what Trojita uses as well. Technically, it's wrapped by a QDesktopServices::openUrl and it might end up calling a DE-specific script and following the user's preferences. These facilities however do not distinguish between a "please open this URL" and a "please download content from this location".

When such a feature exists I'll be happy to use it, but I don't see us actually driving and pushing the standardization effort.

But I see that our pop-up menu offers a lot of options when clicking a link; that could probably be downscaled a bit.

"Freestyle", ie. allow to add custom menu items based on a filter, maybe.
On POSIX systems one would likely use wget or curl - trojita is no download manager (nor does it provide one)

(In reply to Jan Kundrát from comment #1)
> Can you please explain what use case do you have in mind? How do you usually
> use this feature in another MUA?

Right click on a URL, select 'Save link as', which opens a save-file dialog window that lets me choose where I want to save the file.

> Right click on a URL, select 'Save link as', which opens a save-file dialog
> window that lets me choose where I want to save the file.

That was sort of obvious :), but I wonder what do you want/use this for. 
What's wrong with a roundtrip through your browser? Click a link -> your 
browser asks you what to do -> the browser performs the required work.

As an anecdotal data point about my specific usage patterns: when a link 
refers to something which is not a web page, it's very often something 
which requires authentication anyway. Trojita won't know what to do in that 
case.

We also do not want to deal with showing a progress GUI of possibly N 
concurrent downloads, to track their state, to make this list persistent 
and to recover from OS/session restarts, etc. In short, as Thomas said, 
Trojita is not a download manager.

(In reply to Jan Kundrát from comment #4)
> > Right click on a URL, select 'Save link as', which opens a save-file dialog
> > window that lets me choose where I want to save the file.
> 
> That was sort of obvious :), but I wonder what do you want/use this for. 
> What's wrong with a roundtrip through your browser? Click a link -> your 
> browser asks you what to do -> the browser performs the required work.

OK, I didn't understand before what you had in mind when you asked how I use this feature in other MUA.

The problem with the round trip through the browser is that I have my desktop environment configured in a way that only a certain limited subset of MIME types is opened through the browser when I click on them. For example, I use an image viewer to open images by default. So, when I click on a URL that points to an image in Trojita, the file is opened by the image viewer.

Now, that particular helper app that's used to open a specific type of file may or may not have the functionality to save that file to a disk (for example, my GIF viewer isn't capable of doing that). So, I'm stuck with two options:

* copy the URL from Trojita and use wget or similar
* copy the URL from Trojita and open in a browser

Both are possible but both are annoying and the 'round trip' has gotten a lot more complicated than just clicking on a link.

> As an anecdotal data point about my specific usage patterns: when a link 
> refers to something which is not a web page, it's very often something 
> which requires authentication anyway. Trojita won't know what to do in that 
> case.

I don't see that many examples of this in my workflow, but wouldn't it be possible for Trojita to time out in such cases and report something like 'Unable to access'? I don't know how Trojita handles HTML content in messages, but the fact that it's capable of displaying it properly rendered means that it must be capable of downloading arbitrary stuff from the Internet, or not?

> We also do not want to deal with showing a progress GUI of possibly N 
> concurrent downloads, to track their state, to make this list persistent 
> and to recover from OS/session restarts, etc. In short, as Thomas said, 
> Trojita is not a download manager.

That's a good point, but couldn't this be hidden, for example, behind the systray icon? And I don't mean progress bars or something like that. Just a note that Trojita is trying to access so and so. Just an idea.

(In reply to Robert Kratky from comment #5)
> The problem with the round trip through the browser is that I have my
> desktop environment configured in a way that only a certain limited subset
> of MIME types is opened through the browser when I click on them. For
> example, I use an image viewer to open images by default. So, when I click
> on a URL that points to an image in Trojita, the file is opened by the image
> viewer.
> 
> Now, that particular helper app that's used to open a specific type of file
> may or may not have the functionality to save that file to a disk (for
> example, my GIF viewer isn't capable of doing that). So, I'm stuck with two
> options:
> 
> * copy the URL from Trojita and use wget or similar
> * copy the URL from Trojita and open in a browser
> 
> Both are possible but both are annoying and the 'round trip' has gotten a
> lot more complicated than just clicking on a link.

The DE that I use (Plasma) has a switch which controls whether an URL is always opened in a web browser, or whether the MIME type is guessed/checked (I don't actually know, maybe it uses its generic network stack to download or HTTP HEAD it first) and then an appropriate local application is used for its handling. Perhaps you can use a similar feature as well?

I believe that it's the job of the "rest of the desktop environment" to provide a wrapper which gets triggered when a user "just clicked a web link" to ask what they intend to do. I don't want to manage filetype associations within Trojita, either; these are bits which we simply delegate to the DE.

> I don't see that many examples of this in my workflow, but wouldn't it be
> possible for Trojita to time out in such cases and report something like
> 'Unable to access'? I don't know how Trojita handles HTML content in
> messages, but the fact that it's capable of displaying it properly rendered
> means that it must be capable of downloading arbitrary stuff from the
> Internet, or not?

Yes, the libraries which we use can be asked to download stuff from the Internet. However, this is limited to e-mail display, there's no extra UI, no download resuming and what not. There's no user-facing download manager tied to the HTTP stack.

> That's a good point, but couldn't this be hidden, for example, behind the
> systray icon? And I don't mean progress bars or something like that. Just a
> note that Trojita is trying to access so and so. Just an idea.

It can be done for sure. But I do not think that this /should/ be done within a MUA.

(In reply to Jan Kundrát from comment #6)
> (In reply to Robert Kratky from comment #5)
> > The problem with the round trip through the browser is that I have my
> > desktop environment configured in a way that only a certain limited subset
> > of MIME types is opened through the browser when I click on them. For
> > example, I use an image viewer to open images by default. So, when I click
> > on a URL that points to an image in Trojita, the file is opened by the image
> > viewer.
> > 
> > Now, that particular helper app that's used to open a specific type of file
> > may or may not have the functionality to save that file to a disk (for
> > example, my GIF viewer isn't capable of doing that). So, I'm stuck with two
> > options:
> > 
> > * copy the URL from Trojita and use wget or similar
> > * copy the URL from Trojita and open in a browser
> > 
> > Both are possible but both are annoying and the 'round trip' has gotten a
> > lot more complicated than just clicking on a link.
> 
> The DE that I use (Plasma) has a switch which controls whether an URL is
> always opened in a web browser, or whether the MIME type is guessed/checked
> (I don't actually know, maybe it uses its generic network stack to download
> or HTTP HEAD it first) and then an appropriate local application is used for
> its handling. Perhaps you can use a similar feature as well?

I use Plasma, too, but I actually like to open the individual types of files in their associated apps. Even from Trojita. But I'd like to have the opportunity to download the file instead of opening it when I choose so.

Even if I decided that I only want to open the files from Trojita in a browser, it's not possible. (Unless I'm mistaken, there'no way to configure this behaviour on a per-app basis.)

> I believe that it's the job of the "rest of the desktop environment" to
> provide a wrapper which gets triggered when a user "just clicked a web link"
> to ask what they intend to do. I don't want to manage filetype associations
> within Trojita, either; these are bits which we simply delegate to the DE.

That sounds reasonable, but I don't know of any DE that would implement this.

Perhaps it would be possible to implement custom menu items as Thomas suggested? I'd gladly write a wrapper script myself then.

The path of the least resistance is probably to start Trojita in an env with a custom `xdg-open` in your $PATH (and yes, that's pretty user-unfriendly) -- and hope that Qt decides to use this xdg-open in preference to whatever DE detection they might have in hand, too.

I am undecided on whether a patch for possibly overriding the platform support belongs to Trojita. I definitely won't write one.