6.0.0-git
2019-07-21

[#5872] unified scroll bars
Summary unified scroll bars
Queue DIMP
Queue Version HEAD
Type Enhancement
State Resolved
Priority 1. Low
Owners slusarz (at) horde (dot) org
Requester adrieder (at) sbox (dot) tugraz (dot) at
Created 2007-11-07 (4274 days ago)
Due 11/08/2007 (4273 days ago)
Updated 2008-04-16 (4113 days ago)
Assigned
Resolved 2008-04-16 (4113 days ago)
Milestone
Patch No

History
2008-04-16 18:05:48 Chuck Hagenbuch Comment #12
Assigned to Michael Slusarz
State ⇒ Resolved
Reply to this comment
Looks like mouse-wheel events are handled now.
2008-03-04 20:27:25 Chuck Hagenbuch Comment #11 Reply to this comment
Michael - with the js emulated scrollbar, would it be possible to 
support scroll-wheel events? If we can do that I'd be happy (and 
honestly, the minimal design of the current scrollbar works just fine 
for me).
2007-12-26 06:46:17 Michael Slusarz Comment #10 Reply to this comment
I guess what he meant was, to still listen to the scroll events, but
only fire the request to the server after a timeout, and cancel this
timeout as soon as there are more scrolling events. But it's well
possible that this es exactly what you were saying too.
Yup - exactly what I am saying.  This logic fails if a user moves the 
scrollbar too slowly.  And again - all this is irrelevant (as 
mentioned before) because even if the scrolling part worked, browser 
scrollbars are still broken in Opera - it duplicates any 
pagedown/pageup click with no way to capture and ignore the 
superfluous event - and scrolling using the arrowicons on IE breaks 
once the messagelist exceeds a certain size - the messagelist will 
move by 2 or more messages per click which does not happen on any 
other browser.
2007-12-22 09:07:06 jan (at) horde (dot) org Comment #9 Reply to this comment

[Show Quoted Text - 10 lines]
I guess what he meant was, to still listen to the scroll events, but 
only fire the request to the server after a timeout, and cancel this 
timeout as soon as there are more scrolling events. But it's well 
possible that this es exactly what you were saying too.
2007-12-22 07:01:23 Michael Slusarz Comment #8 Reply to this comment
Have you checked any of the full-page continuous scrolling
implementations to see how they deal with this?
None of them deal with this.  They will trigger multiple parallel 
requests.  For example, Yahoo Mail does this, but apparently the 
reasoning at yahoo is we don't care - we can just throw scores of 
CPU/IMAP power at the server level
Can't we do a timeout
to see if the scroll position has changed (sorry if this is well past
the point of what's been tried).
This is what we previously did, but position change is irrelevant.  We 
don't want to load a slice until the user releases the mouse button 
(or else you can generate a bunch (easily 10+) parallel requests - and 
since they are all blocking at the server level, the result is that 
the final message slice may take 30+ seconds to load - completely 
unacceptable.
I do agree that the difference between the two scrollbars isn't
great. I don't mind the message list one as much as Jan, but I
probably haven't used it as much either. The browser's widgets will
always be preferable for consistency, but internal consistency is
probably second best.
As mentioned previously, my plan is to spruce up the scroll bar 
graphically to make it look nicer (and also add arrow navigation at 
the top and bottom).  But as usual, any help with graphic design 
elements would be gratefully welcomed since I have no skills there.
2007-12-22 06:55:25 Michael Slusarz Comment #7 Reply to this comment
This is worthless.  It has the exact same issue as already mentioned - 
if you slowly scroll through the list without releasing the scroll 
bar, it will trigger a boatload of parallel requests to the server - 
because as previously mentioned there is no cross-browser method for 
determining when a user releases the mouse when dragging an internally 
created browser scrollbar.
2007-12-14 17:06:37 casper (at) biering (dot) dk Comment #6 Reply to this comment
Have you checked out:

http://www.siteartwork.de/livegrid/


2007-11-24 22:33:52 Chuck Hagenbuch Comment #5 Reply to this comment
Have you checked any of the full-page continuous scrolling 
implementations to see how they deal with this? Can't we do a timeout 
to see if the scroll position has changed (sorry if this is well past 
the point of what's been tried).



I do agree that the difference between the two scrollbars isn't great. 
I don't mind the message list one as much as Jan, but I probably 
haven't used it as much either. The browser's widgets will always be 
preferable for consistency, but internal consistency is probably 
second best.
2007-11-09 17:16:28 Michael Slusarz Comment #4 Reply to this comment
To be honest, I am *really*, I mean *really*, unhappy with the
message list scroll bar. I know you did this as a last resort because
there were some problems with the old implementation. But we can
never get nice looking scroll bars this way, because even if it's
styled better than now, it will never look like the
system's/browser's scrollbars.
Is there really no way to implement that with the old (or a
different) scrollbar widget?
I couldn't find any other cross-browser compliant scrollbar widget 
(and I looked for about 3 hours), so if you know of one let me know.



But the one thing we definitely can not do is use the browser's 
scrollbar.  There is absolutely no way to make it work cross-browser - 
and it is so bad, even within the same browser on different platforms, 
like FF on Mac vs. Windows/Linux, the behavior is different.  Other 
than FF for Win/Linux, there is no way to determine on any other 
browser when a user stops scrolling.  Without this feature, scrolling 
through any halfway large list of messages (say, 400-500 messages or 
so) pretty much results in having to do 5-10 simultaneous messagelist 
requests, and many of these messagelist requests are overlapping, and 
each blocks the other.  Absolutely kills the server.



Also, the old method simply will not work on any recent version of 
Opera (Opera fires two javascript events instead of one, and there is 
no way to stop either) and IE would break in mailboxes over a certain 
amount of messages (clicking on the down arrow in a large enough 
mailbox would result in the list scrolling down by 2 or more messages 
instead of 1).
2007-11-09 11:42:59 Jan Schneider Comment #3
State ⇒ Feedback
Reply to this comment
To be honest, I am *really*, I mean *really*, unhappy with the message 
list scroll bar. I know you did this as a last resort because there 
were some problems with the old implementation. But we can never get 
nice looking scroll bars this way, because even if it's styled better 
than now, it will never look like the system's/browser's scrollbars.

Is there really no way to implement that with the old (or a different) 
scrollbar widget?
2007-11-09 04:08:58 Michael Slusarz Comment #2
State ⇒ Rejected
Reply to this comment
No.  Using a javascript scroll solution for the folder list is 
overkill and would break auto-scrolling of that list.  The better 
solution is to format the scroll bar for the message list nicer, but 
I'm still waiting for help with that (my graphic design skills are 
horrible).
2007-11-07 22:53:37 adrieder (at) sbox (dot) tugraz (dot) at Comment #1
Type ⇒ Enhancement
State ⇒ New
Priority ⇒ 1. Low
Summary ⇒ unified scroll bars
Due ⇒ 2007-11-08
Queue ⇒ DIMP
Reply to this comment
It would be nice to have unified scroll bars in DIMP. At this time 
there are different scroll bars for the message list in the viewport 
and the folderlist in the left menu.

Saved Queries