I want to clarify that my question wasn't about changing double-click behavior, it's about reducing/removing the delay for single click behavior. Right now, there is 1/2 a second delay before loading an email preview, presumably to prevent redundant loading of the email when that click was the first of an intended double-click.
If reducing server load is more important than reducing end-user waiting, it makes sense. At our site, we'd rather use more servers and deliver a more responsive application. One thing that we've discovered is that if you don't schedule the single click behavior and just call it immediately on click, auto-loading the next message after dragging one to the trash won't work. (When "flag_for_deletion" = false). However, if you schedule it for 0 microseconds later, it still works. Can anyone think of other problems with reducing the dblclick_time? Thanks, Ziba On Thu, 14 Aug 2008 16:43:02 -0400, ziba <[EMAIL PROTECTED]> wrote: > > > Hi, > > I'm wondering what the purpose(s) of dblclick_time are as used in > program/js/app.js:this.msglist_select > > It seems clear that it will prevent the message preview from loading > while the user is about to hit their second click to open the full > message screen. There is some nice economy there. However, if they > are just single clicking with the intent to see the preview it adds > 0.51 seconds before the preview is shown. > > Are there other reasons for waiting dblclick_time + 10 after a single > click to show the preview? If not, I'd side with the faster preview > time over the economy of not loading the preview before loading the > whole message. >-- > > Ziba Scott > Web Application Developer > Web/DB Team, Information Technology Central Services > The University of Michigan _______________________________________________ List info: http://lists.roundcube.net/dev/
