Bug 379158

> Thunderbird has advanced options for IMAP servers:

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?

> IMAP server directory [text]

That's a poor man's NAMESPACE. It might have been relevant around 2000 with 
uw-imapd, but not anymore, IMHO.

> show only subscribed folders [boolean]

Trojita supports that just fine (although you'll need LSUB on the server 
side).

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

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

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

(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 footprint – on an old laptop you wouldn’t want Thunderbird in your tray waiting for new mails, with steadily increasing RAM usage that starts out one order of magnitude above Trojitá already. But I really do think Trojitá needs just a little bit more flexibility to become a real option.

Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version?

If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!