https://bugs.kde.org/show_bug.cgi?id=379158
--- Comment #2 from Sebastian Lisken <sebastian.lis...@gmx.net> ---
(In reply to Jan Kundrát from comment #1)
Thanks for the response, Jan.
> Actually, these are largely work-arounds for legacy or misconfigured IMAP
> servers. The mere fact that something in TB is available as a GUI option
> doesn't mean that it's needed. Which one of these prevents you from doing
> something in Trojita?
Just to clarify, I am not arguing for a one-to-one adoption of Thunderbird’s
options. I agree that an option should not be included for its own sake. I only
listed all of these because I wasn’t sure enough how they work in terms of the
IMAP protocol and how they interact. I did expect a few redundancies much like
the ones you explained.
> > show only subscribed folders [boolean]
>
> Trojita supports that just fine (although you'll need LSUB on the server
> side).
Does it support both the "true" and "false" state of this option? In any case,
I have no particular interest in this option, this was only a suggestion to be
taken on in case the developers find it useful enough.
> > server supports folders that contain sub-folders and messages [boolean]
>
> There's no need to have that checkbox in the settings; Trojita handles it
> implicitly.
Good. Again, that was just something for the developers’ consideration.
> > three namespaces: personal
> > namespace [text], public (shared) [text], other users [text],
> > and allow server
> > to override these namespaces [boolean].
>
> That's again NAMESPACE. I agree that it would be nice if Trojita offered
> user-visible bits for these, but what do you need them for? Do you have an
> account which actually doesn't publish these mailboxes via a single LIST
> hierarchy?
I guess that with capital NAMESPACE you are referring to an IMAP command.
Apologies for not bothering to look this up – I’d leave it up to you how to
structure any options you may want to offer here. But setting the namespace –
not necessarily with the same options, just something that behaves sensibly –
is the option I am strongly interested in. See below.
> > For configuring GMail well the server
> > directory can be set to "[Google Mail]" (with brackets, without
> > quotes) for a
> > much improved display, as the standard GMail labels on shown at
> > the same level as the inbox.
>
> Yes, this is a server-side choice whether various folders are listed as
> children of INBOX or at the same level. I don't think that it warrants an
> extra UI override to tweak the visual representation here, frankly. Does
> that one extra level which is nonetheless automatically expanded bother you
> that much?
>
> > Other IMAP servers also introduce unnecessary nesting
>
> Yes, I'm sure that there are servers which introduce extra nesting. At my
> former workplace, we also used to have one in place. However, that was
> prior to 2006 IIRC. Are you *still* stuck with one of them today?
I think the fact that GMail has such a structure makes it interesting to
configure, and the popular German ISP (and email provider for its customers)
T-Online (the successor of the state-owned postal service) is another example.
I recently configured someone’s Outlook IMAP settings for a T-Online account
and had to enter INBOX in an option (Outlook’s equivalent for what we’re
discussing here) to get rid of one tree level. I have only briefly tested a
GMail account in Trojitá though and have no T-Online account of my own.
It is not just an inconvenience to have another node to expand (even if the
client software expands it by default). There might also be confusion if
Trojitá users might want to create an IMAP folder outside the hierarchy
envisaged by the provider. Either this is possible but the folder (or label in
the case of GMail) is either invisible or somehow unusual, or it is rejected
and the user might well not know enough about the details to understand why. In
either case the absence of the NAMESPACE option creates potential for confusion
in such cases.
My context is advocacy for mail clients in the face of e-mail becoming
generally less popular and proper client software losing out against
provider-specific apps and providers’ own web interfaces. If there is a fairly
easy option that can make the use of a mail client more logical or simple then
in my view it should be offered. And, by the way, my advocacy is for FOSS
clients of course. The T-Online customer I mentioned above was running Outlook
already and regrettably would not have been able to deal with a change of
software. While I know Thunderbird best (but not the details of the IMAP
protocol, sorry) I can think of one or two people whom I’d like to convince to
take up client software and who might prefer Trojitá for its small foot
