Hello Steve & all fellow TBUDL members,
Friday, January 07, 2000, Steve unfortunately wrote:
SL> If you consider it a shortcoming then that is clearly a perception
SL> issue and *IS* a problem between chair and keyboard.
On whose end?
when "Cid" said:
>> You may not care to deal with mail from multiple accounts as one, but
>> some of us do.
SL> Bully for you, use another product, don't mangle this one for
SL> everyone else who doesn't work like you do.
Where does this "use another product" come from? Who is directing
traffic to and away from TB? This is just one issue we're dealing with
here, having an optional accounts column is not going to "mangle" TB
and NO one here has the truth by the tail.
>> I don't want to redirect messages all over the place, bouncing them
>> through my ISP or anywhere else for that matter.
First of all, as it stands, a message to the wrong account COULD be
filtered to a folder in the the main account, which has the identity
of the account desired and tickered to show it came in. But that's
still the long way around and the best of both worlds is to have an
optional accounts column, linked to the account the mail came in on.
Answering would send from the receiving account but the complement to
that would be a small popup box in the compose screen with the current
account shown, and all other accounts selectable behind it. That's all
it takes, so what's the beef? Excess code? How much? Incompatible? I
doubt it.
SL> Forwards are acceptable use, have been for years. If not, you can
SL> always have a local filter.
Solutions abound, as do preferences.
<snip>
>> Steve, I think you need to accept that your way may not be the
>> *right* way, it's just your way.
SL> I have accepted that. You and Alex need to accept that your way is
SL> not the right way, either, and keep your paws off a viable client.
It's pretty hard to type with paws and I didn't know that future TB's
design decisions had to be cleared with Steve first, or would I have
checked with him long ago.
>> If you are perfectly happy with the way it works, stick with 1.38e as long
>> as you like. You don't have to upgrade.
SL> Actually, yes, I do.
>> Hopefully, when 2.x comes out, it will have OPTIONS, and hopefully
>> you can continue to operate the way you do even if you do upgrade.
My earlier reply to this thread to that effect went ignored but I have
to concur. There should be no conflicts.
SL> The problem with options is that it forces code bloat, code
SL> complexity, configuration complexity. I'm all for options, but
SL> options that change the fundamental behavior of the program, that
SL> involve completely different ways of doing things and that, in
SL> essence, disable a large portion of code is nothing more than
SL> waste to me.
That is a valid criticism and the important thing would be to
determine if that is indeed the case. If so, it's certainly something
that needs to be weighed. I have my doubts though, maybe because I
don't think TB's designers are that stupid - they wouldn't go ahead
with it. And if it WERE the case (that the whole paradigm would we
turned around), maybe we are looking and his and hers (or different
lines of) TB's - red and blue, for me and you.
SL> Furthermore, there is only so much that you can put into "options"
SL> before people look at the options, get intimidated, and look
SL> elsewhere. That is where multiple products come in.
That's another valid point that also deserves consideration, but I'd
want to know more about what an accounts column option involves in
terms of conflicts (if any) with previous code. The option itself as
such doesn't seem particularly intimidating to me. And TB isn't a
product for cowards, anyway.
>> For the rest of us, that want to do things differently, we have a
>> right to ask for features, and should expect them to be
>> implemented, as paying customers, if they are supported by enough
>> people.
SL> You also have the right to move to another client.
All of us do, including you.
SL> I'm sick of this move that every program of a certain genre has to
SL> look and feel like every other product in the genre.
It's not that, it's a matter of efficiency, in relation to ones work
habits and thought patterns.
Have you ever evaluated Calypso? It's a candy ass mailer from an
unreliable company that never-the-less has some good features. If you
haven't and want to mess with it, www.mcsdallas.com will get you to
where you can download it.
>> Frequently, your responses to someone's wish list have been: "Bad
>> Idea" or "Wrong" type answers.
SL> Of course. I go on to explain why, most often in technical
SL> reasons. Saying...
>> Instead of a simple: "IMHO, this would not be effective because..."
SL> ...doesn't change the fact they are bad ideas and are flat out
SL> wrong.
Cid, you are making 2 mistakes. First of all, you are failing to take
into account the fact that you are dealing with "your priest and
shrink, your main connection to the switchboard of soul" and should
show more respect.
Second, please leave Steve alone as far as his way of expressing his
opinions. If it's rhetoric it's rhetoric, but who doesn't use it? I
suggest that discussions be directed to TB issues, rather than the
mannerisms of each contributor. Steve has a lot to contribute, as well
as the right to be right, wrong or 50/50.
In any case, there are others guys in Moldavia that are looking at
these issues themselves.
<snip>
SL> A Microsoft product is one that tries to do everything
SL> for everyone in one, large, monolithic application.
Very true.
SL> Do *YOU* see a PIM in TB! like there is in Lookout!?
Outlook. (OK, maybe that was intentional, in which case it's funny). I
use Ecco myself and have never bought an MS product.
SL> I don't. I don't bash all new ideas, I bash the bad ones or ones
SL> that would go down the path of excessive bloat.
A real Babe Ruth. May there never be silence in Mudville.
DH
And this server let me connect already.
--
--------------------------------------------------------------
View the TBUDL archive at http://tbudl.thebat.dutaint.com
To send a message to the list moderation team double click here:
<mailto:[EMAIL PROTECTED]>
To Unsubscribe from TBUDL, double click here and send the message:
<mailto:[EMAIL PROTECTED]>
--------------------------------------------------------------
