<div dir="ltr"><div>I find this thread worrying in many regards -- if we follow your reasoning, Thunderbird is to become a software product that's set in stone, where no single feature ever changes and the software remains as is for the next 20 years because "that's the way we like our email client". Why are we putting any efforts in, then?<br><br></div><div>Such a point of view:<br></div><div>- stifles innovation in Thunderbird: if I have to implement a new feature, I don't want to spend twice as much time writing the backwards-compatibility layer that makes sure your habit never changes;<br></div><div>- sends the wrong message: if we want to convince people that Thunderbird is alive, making sure their email software never changes from release to release is the best way *not* to achieve that;<br></div><div>- is not representative of the new user base we're trying to conquer: I don't think people on this mailing list, myself included, can claim to see this software in the eyes of a fresh users.<br><br></div><div>So please, let's be moderate when expressing opinions on new features. While I agree that the changing the offline sync settings by Gloda may have been a little heavy-handed, the Recipients column is fairly minor, and is most likely to take 30 seconds to revert for anyone who actually wishes to do so. People in this thread, obviously, have hundreds of folders, but our userbase is not entirely made up of tb-planning :). It is not completely unlikely that less technically-savvy users think "wow that's a cool new feature" when they get the upgrade. If they are not upgraded by default, they will never discover it.<br><br></div><div>On a personal note, I enjoy the new feature very much; I was super happy to see the thread pane get a refresh (I think that's the first time it happened since I started using Thunderbird!). I tried to implement such a column in Conversations (the "Between" column), and my implementation is vastly inferior to the new Recipients column, meaning I'll be able to drop my poor code in favor of the better one in Thunderbird. That's great news!<br><br></div><div>Cheers,<br><br></div><div>Jonathan<br></div><div><br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 10, 2015 at 1:11 PM, Jörg Knobloch <span dir="ltr"><<a href="mailto:jorgk@jorgk.com" target="_blank">jorgk@jorgk.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 10/04/2015 15:59, Andrew J. Buehler wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
what would the convertor code do in a case where someone has_both_  the<span class=""><br>
- From and the To columns visible, in the same folder? This may be an<br>
unlikely case, but if someone did do it intentionally, none of the<br>
possible courses of action I can think of (except leaving the columns<br>
untouched) seems more likely to avoid disrupting the user's intent than<br>
any other. (Especially if the columns are not adjacent.)<br>
</span></blockquote>
<br>
The current implementation removes any From and Recipient column it finds and replaces it with Correspondents. If both columns are present, the position of the Recipient column is used.<br>
<br>
If an automatic upgrade is desired, the user should be able to disable it via a preference, like Firefox' new searchbox (browser.search.<u></u>showOneOffButtons).<br>
<br>
I suggest to turn auto-upgrade off be default. Having it on by default would mean that users who really don't want it need to research how to turn it off.<br>
<br>
I raised bug 1152706 on the issue.<br>
<br>
Jorg K.<div class="HOEnZb"><div class="h5"><br>
______________________________<u></u>_________________<br>
tb-planning mailing list<br>
<a href="mailto:tb-planning@mozilla.org" target="_blank">tb-planning@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/tb-planning" target="_blank">https://mail.mozilla.org/<u></u>listinfo/tb-planning</a><br>
</div></div></blockquote></div><br></div>