Yeah, I understand your point. I think in my case scrolling is the most natural behavior. Your right the scrollbar thumb stops shrinking...although not ideal so they don't get a visual feedback of how large the real message queue is...I think I can live with that. It's a lot better than the browser crashing because it can't handle the DOM size. (Some sort of a virtual/custom scrollbar could solve this.)
I have the HTML DOM element caching working quite well...its configurable but I default to start the cache at 2x the visible size...then as they scroll up I slowly pop the cache back on the DOM...then put back in the cache on the way back down. In all ways (except one) scrolling is seem-less, including using the mouse scrollwheel, you can't tell I'm adding/removing from the DOM...the exception is if your moving the scrollbar thumb directly...then that will be a bit jumpy...especially if a large message was added/removed from the DOM. I'm not sure how to handle this case...if I can at all. The only thing I haven't figured out yet is how to handle mouse selection ranges. They could make a large text selection where I have moved some of the DOM entries in their selection to the cache. I just posted another message about this. Basically I need a way to clear their first click point in the HTML widget. (We will handle real text searching differently...we will auto store these message streams to a database and support full text searching. But that's out of scope for now.) Thanks, -Dave On Aug 15, 9:26 am, Jens <jens.nehlme...@gmail.com> wrote: > I don't know your app and requirements but if you have so many log entries > to show, does scrolling still makes sense? I mean at some point the > scrollbar does not shrink anymore and scrolling becomes a pain if you have > so many items in your list. As an user I would never search through them > using scrolling but instead expect and use a search/filter widget to get > the log information I am looking for. Or you make your live log viewer only > contain the last 100 items and provide a CellTable/DataGrid which is no > live log view but instead displays all logs since now() and uses paging so > you can easily go back in time. > > Nevertheless, in my list I have used an AbsolutePanel inside the > ScrollPanel and set its height to <num items> * <fixed item height> and > while scrolling I have calculated absolute positions for the items. Without > fixed height you have to wait until an item is rendered to get its offset > height which would cause bad performance I think. > > -- J. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
