Wednesday, May 03, 2000, 9:35:07 AM, Allie wrote:
> It doesn't take long before one realises that unless one writes his/her
> own application, one will never use a complex application out there that
> will do things exactly the way one wants. Developing the willingness to
> make concessions and getting used to the paradigm that most approximates
> your needs is essential.
Exactly. That is why I have taken the stance on some issues of "It exists
elsewhere, go there." This is especially true for single-account, multi-POP
and MDI. There are all of two email applications in the Windows market that
aren't single-account, multi-POP and MDI at the same time. In fact, finding
the exception to either of those on its own is hard to find. Based on that
fact alone there is no need to request it for TB!. It has been done. It has
been done quite a bit. If people want it they have the choice elsewhere. If
people want something other than MP/MDI they have very little choices so those
choices should be defended rather vigorously.
OTOH, there are some things which can be added which would not really
cause a detriment to the overall product. This is especially true in some
cases because:
a: they don't exist in other products yet.
b: they exist on the backend, away from the UI.
For example, personally, I'm far less apt to oppose some backend format
change on the database level because it doesn't directly effect how one uses
the product. MP/MDI, editor, spell checker, etc does. How the protocols are
handled does effect how one uses the applications.
To that end I /hope/ that the suggestions I make and the arguments I
present are based more on technical merit and on the backend than anything
else. I am well aware that the chances of someone making a client that suits
my tastes will be slim. OTOH I also hope that I'm not so far out my
suggestions don't have merit, either. I mean my whole demands on how IMAP
/should/ work, for example, I think are reasonable.
> It avoids forcing the user to get used to another applications
> idiosyncrasies and ways of doing things.
Exactly.
> Since this modularity is not well developed in Windows applications in
> general, one can well understand user appeals for changes to what they are
> accustomed to or prefer.
I won't say that it isn't well developed. I will say that it is
understated because of the lack of understanding of basic interoperability
issues as well as programming culture that ignored the advances that came
before it.
Oddly enough, in the unix world, the basic way that data is passed around
is temp files. Basic, easy to use, completely understood temp files. It
doesn't take a rocket scientist to plop a file down on the disk, tell the
editor to edit that file and wait for the editor to exit. However, because of
the TSR nature of some editors and the trend to make abstract things which are
better left real that isn't too practical in the Windows world. In short,
they ignored how things have been done for years and didn't offer an
acceptable replacement in the process. The end result is a lack of decent
conventions on passing data from one program to another while having some
half-assed standards to do just that. IE, just enough to look cool, not
enough to be actually useful.
--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
ICQ: 5107343 | main connection to the switchboard of souls.
-------------------------------+---------------------------------------------
--
--------------------------------------------------------------
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]>
--------------------------------------------------------------
You are subscribed as : [email protected]
