> On Wed, Oct 30, 2002 at 07:45:19PM -0800, John Locke wrote:
>> Ah, but William stated above that Show All timed out ...
>>
>> I think the real issue here is not Squirrelmail, but your IMAP server.
>> Let me guess... you're using UW-IMAP.
>>
>> I was having similar trouble with some of my folders. Switched to
>> Courier-IMAP, and moved everything to Maildirs, and now it's speedy,
>> and Rick's method works fine.
>
> On any server you may still face a timeout if there are enough messages
> in it (some users here have a thousand or more in some folders).  In
> that case you need to a) raise the timeout value in
> functions/imap_general.php and b) increase the max_execution_time
> parameter in php.ini to match.

This simply isn't a useful option.  The timeout is currently 30 seconds. 
Waiting that long is painful enough.  Any more and I'd stop using e-mail
all together ;).

I don't understand the opposition to either suggestion, especially from
the lead architect here.  Marking an entire folder as read, or even
deleting it's contents, is not something that unusual for users to do.  It
may be that I'm a bit on the fringe with the volume of e-mail in a single
folder, but I bet there's still plenty of others in the same situation as
I.  But in any event, even if the folder only has, say 40 e-mails you have
to deal with, that's still several screens worth of e-mail.  The Show All
is useful in some cases, but even that's extra work in comparison to a
simple click on an Icon in the folder tree, for instance.  Saving users
time and effort should be one of the primary goals of ANY software
project, and in this case I think that's doubly important, since for many
e-mail is a large portion of what they spend time doing.

The Spam idea may sound off course at first, but only because I gave the
specific need I have for this.  I specifically stated, however, that I'd
be happier with a configurable folder (or list of folders), which could be
useful for other things as well.  For instance, most people prefer to keep
their INBOX clean, and move e-mail out after they've read it.  Often this
means putting the e-mail into a generic catch all folder, and it would be
much faster to have a link/button/etc that does this instead of having to
locate the folder in the drop down.

The suggestion to rename the folder so it shows at the top of the list is
a cop out.  It may be that I can't change the folder name.  Or maybe I
just don't want to.  In any event, in most cases the dropdown is
auto-scrolled to the currently selected entry when you drop the combo box
down any way, which still means I can have to spend time scrolling back to
the top to locate the folder.

The argument about realestate is debatable.  First, it's a plugin that one
doesn't have to enable, so the realestate taken may be zero.  Let the user
decide if it takes too much.  Second, as pointed out, there's other
plugins that are already adding buttons to the top.  As long as the
buttons are small, the realestate taken is often acceptable.  Third, for
this purpose it would be valid to add the buttons to the bottom of the
e-mail, since you'll typically want to read the e-mail before filing it
anywhere any way.  A "Fast File" list at the bottom, below the current
"Move Folder Dropdown" could be beneficial for many users.  It's just a
convenience, yes, but for those of us who deal with a LOT of e-mail, it's
an important one, and should be simple to implement.

The suggestion that I write it myself... I understand why this was said,
but the Open Source community has to realize (and I *am* a programmer who
has some Open Source contributions under my belt) is that not all users
*CAN* do this.  And even those who can may not be able to find the time to
do so.  If the suggestion is reasonable and would benefit others, you
should consider adding it to the list of TODOs, instead of dismissing the
suggestion by recommending someone do it themselves.

That all said, I'm not going to leave in a huff if you decide not to
implement these suggestions, and I'm appreciative of the very nice piece
of Open Source work you've provided.

-- 
William E. Kempf




-------------------------------------------------------
This sf.net email is sponsored by: Influence the future 
of Java(TM) technology. Join the Java Community 
Process(SM) (JCP(SM)) program now. 
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en
--
squirrelmail-users mailing list
List Address: [EMAIL PROTECTED]
List Archives:  http://sourceforge.net/mailarchive/forum.php?forum_id=2995
List Info: https://lists.sourceforge.net/lists/listinfo/squirrelmail-users

Reply via email to