Excerpts from William Morgan's message of Sun Jan 13 06:30:16 +0100 2008: > Excerpts from Marcus Williams's message of Fri Jan 11 09:20:58 -0800 2008: > > This patch adds a multi key combination to expand the thread index > > view to all available threads. Note that this could return _a lot_ of > > threads, which is why I've used a double keypress '!!' as a guard to > > accidental usage. Its useful in conjunction with the tag all and apply > > to all commands though. > > This does make me a little nervous. Is the use case always that you want > to apply a command to all threads for a given search? If so, I wonder if > it would be better to explicitly model that, without the intermediate > process of loading all the threads. > > If we're going to have a potentially long-running activity like this > available from the UI, then I'd prefer to do it in a manner that gives > the user an indication of how long until completion, the ability to > abort, etc. >
> How does gmail handle this type of thing? Or is everything so fast with > gmail that it doesn't matter? By default it occurs only seen threads (25,50,100 messages depending on configuration), but you have also a check box to apply on all the search results. Then that's indeed so fast that there's no need for a progress bar. However that's fast because operations are chosen to apply fast (add or remove labels, basically). -- Nicolas Pouillard aka Ertai
_______________________________________________ sup-talk mailing list [email protected] http://rubyforge.org/mailman/listinfo/sup-talk
