Bug 45355 - Scrollwheel auto-targeting
Summary: Scrollwheel auto-targeting
Status: RESOLVED WONTFIX
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.0   Edit
Hardware: PC Windows 2000
: P3 enhancement with 10 votes (vote)
Target Milestone: ---   Edit
Assignee: Platform-UI-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 46646 49816 (view as bug list)
Depends on:
Blocks:
 
Reported: 2003-10-22 05:34 EDT by Jörg von Frantzius CLA
Modified: 2004-10-01 12:41 EDT (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jörg von Frantzius CLA 2003-10-22 05:34:19 EDT
E.g. in Mozilla/Thunderbird, turning the mousewheel automatically targets any
scrollable widget under the current mouse position, without explicitly having to
move the focus to that widget first. This is really handy to have: just move the
mouse over any list (or View, in Eclipse) and turn the scrollwheel to scroll it,
without having to click anywhere. 

The keyboard focus remains the same in Thunderbird, by the way, even when the
mousewheel targets a different widget.
Comment 1 Debbie Wilson CLA 2003-10-22 10:40:16 EDT

*** This bug has been marked as a duplicate of 45027 ***
Comment 2 Eric Estievenart CLA 2003-10-30 09:18:27 EST
Please change Component from UI to SWT.
I agree this is an interesting enhancement request.
Should consider an option to enable it in the preferences.
Just reopen when you have enough votes (let the 45027 bug closed)
--Steve
Comment 3 Jörg von Frantzius CLA 2003-11-05 06:19:26 EST
This is an enhacement proposal for the User Interface, and not a bug of SWT (as
the other bug 45027 is). I don't know where it would be implemented, but Grant
Gayed seems to think that SWT is the wrong place.
Comment 4 Debbie Wilson CLA 2003-11-05 11:28:52 EST
Discussion among dev teams indicates that swt won't do this because mousewheel 
scrolling is done natively, and in order to change the behaviour we would have 
to get in the way of each platform.  Overriding a native behaviour on all 
platforms is not something that swt should be doing.  
Comment 5 Grant Gayed CLA 2003-11-18 08:34:42 EST
*** Bug 46646 has been marked as a duplicate of this bug. ***
Comment 6 Jörg von Frantzius CLA 2003-11-18 09:32:43 EST
By the way, this behaviour would not have to be changed for all platforms. As
far as I know, at least on some Windowmanager/Linux distro combinations
(GNOME/MetaCity), Eclipse already behaves like that. There this is already
standard behaviour of the platform.

Changing the behaviour on Win32 would only bring that platform up to the same
level. Also, providing it only for Win32 would certainly make 99% happy of those
looking for it (and probably delight a lot of more people who didn't know about
the idea before).
Comment 7 Thomas Whitmore CLA 2003-11-19 20:13:49 EST
Most Windows apps use the wheel on hover, pretty much seems to be standard (as 
well as fundamentally deeply preferrable) for all MS stuff. Don't know about 
the underlying event queuing.

Wheel operation is a major major major usability point, since it is a common 
and well-used part of the basic control surface for users.
Comment 8 mark lybarger CLA 2003-11-20 20:48:58 EST
scrolls as expected on kde/linux. at work on win32, i have to click in a panel
to have it scroll there. does not scroll where the mouse is positioned over.
would love to have win2k work as in kde.
Comment 9 Debbie Wilson CLA 2004-01-12 10:43:37 EST
*** Bug 49816 has been marked as a duplicate of this bug. ***
Comment 10 Eric Woodruff CLA 2004-10-01 12:41:57 EDT
This behavior /used/ to work and my productivity misses it very much. I have
x-mouse enabled for WinXP but it no longer functions within Eclipse to switch
between views like it previously did.