The heading speaks for itself.
(Review ID: 48583)
======================================================================

N/A

Commit to Merlin.
  xxxxx@xxxxx   2000-06-30

A MouseWheelListener was added to BasicScrollPaneUI.  The listener code calls into BasicScrollBarUI to scroll the appropriate scrollbar.
 
  xxxxx@xxxxx   2000-09-06

Remember it's not just Microsoft who make these mice! Logitech, Mitsumi, Compaq,
 Genius, IBM and more are also in on the act. Meanwhile they ship as standard
with all Gateway, all Dan and many Dell PCs. Please don't disappoint all of us!

Mouse wheels are not the only mouse addition.  There are also mouse sticks (IBM
ScrollPoint)  that don't really act like the wheels because they send a
constant stream of actions while activated.
There is also a lack of standards between mice makers and types on how to have
the mouse send the data back through the mouse port the the OS.  In that fact
there is no one driver that will work with all mice and their wheels/sticks.
There is no guarantee that the OS mouse driver will even pass those events
through to a program in any fashion (be it native or otherwise) so how can Java
really expect to support the mouse exect if it was to take over the mouse port
and have a driver for that mouse.  That is not possible in many OS's, nor is it
practical to reinvent the wheel in Java by recoding all mouse drivers.
Most wheel mice have their own software that reinterprets the mouse codes in
the driver and translates them to window scrolling events that make sense.  For
windows this means a simple scroll event or similar.
In UNIX operatins systems, such as Linux, this is not an option.  There is not
just one GUI that everyone uses, nor is there any OS driver for mouse wheels. 
Thus the mouse is run by GPM or XWindows, and there's also imwheel which works
ontop of both of these other programs to send windows key events that are
appropriate for that client to have the client react in an appropriate manner.
The imwheel program sends keyboard events.  Some clients, such as those made in
KDE are wheel sensitive to the XFree86 ZAxis Pointer configuration.  Yet again
a special support option, with limited scope.
In the end the best option, I think, is to have the scroll bars react in
Windows the same way as normal windows do to scrolling events (whatever they
are) and in UNIX they should have default keys for scrolling.  This is the most
compatible solution.
Since there is no other common ground (heck Sun and Macintosh don't have these
kinds of mice at all, which is too bad for them), and different OS's require
such different solutions and amny of these solutions would be impractical, I
don't see Java supporting the wheel directly but rather reacting to the same
events that the wheel sends in the OS's that make sense.  Windows, Linux, and
FreeBSD (and any other XFree86 supported OS) make sense as far as I can see.
Forget low level support, but do go for the high level support that makes so
much sense!

No, java was designed to execute everywhere so what if you are in a Mac with
one mouse button, is a MSmouse portable across plataforms.
It must be a merely advantage on the Host OS, Windows and recently Linux Users,
use it as the OS is capable to do that.
think adding this feature to JScrollPane this wouldn't be a greate thing to do
if you see it as a Solaris Developer for Java.
Remember portability.

This is a basic function of many computer users today.  So many computers ship
with a wheel mouse I feel there is little choice.

The wheel on the mouse adds another interface to accessing data easily.  It is
very user-friendly, IMHO, and deserves to be supported.  Maybe some OSes do not
have this hardware feature available yet, but they will.  Makes sense to be
proactive and take care of this on the early side rather than later and not
have Java apps unable to take advantage of this improved hardware interface.

The heading speaks for itself. :)
Please, I'm kinda addicted to my little wheely.

Please support wheel mice !
The lack of wheel support is IMO the most annoying deficiency of a Java GUI
when compared with native GUIs.
Actually this request belongs to two categories: AWT and Swing. AWT should be
enhanced to provide appropriate events, ScrollPane/JScrollPane should react to
those new events.
It may be a good idea to also include support for horizontal scrolling -
although most mice today only have a vertical wheel.

I would like to put my vote to implement the mouse wheel scrolling
functionality. I use this feature frequently.

Please combine:
4174065
4250592
4199885
4202656
We need to have the scroll bars react the same way as normal windows do to
scrolling
events.  Thanks,
-G
P.S. This is a serious bug.

Could somebody enlighten me on how this could be
implemented in straight AWT?

I think you need a separate mouse event for the mouse wheel. 
It needs to work for more than just JScrollPane.  JScrollPane
can of course trap the event, but other containers need to
be able to listen for it too so they can decide which 
behavior they may want to implement.  
I would like to see another method added to MouseMotion
or Mouse that would tell whether it was Horizontal or
Vertical motion and a signed integer to quantify the
amount of movement.

I agree with RSOPH (see below). I think the mouse movement should be an
additional event which AWT and Swing can implement support for. 

I don't see any good reason for not supporting a mouse wheel
(though it will remain bad style for programmers to rely on this
support for a long while, especially since many people are
using Windows without one of these wheeled mice) since on
any platform that does not have a wheeled mouse, you can
simply not deliver any of the mouse-wheel-scrolling events.
Furthermore, putting the support into the AWT would ensure
that programmers don't have to figure this out and add it for
themselves (which would result in far less portable code, of
course.)

I would like to voice my support for adding this functionality... 
even if I have to code conditionally to keep code portable, I 
think this would be a great addition as far as usability is
concerned!

If you have to code conditionally, the chances are the code
is not going to be portable.  And it is certainly not going to be
maintainable...

All of which illustrates just why wheel support *should* be in
the AWT.  Like that it will "just work" where that is supported
and will be ignored gracefully elsewhere.

I think two things are indisputable: (1) Java as a platform and as a language
does not want to be left behind in power. (2) The majority of mice on the
market now have wheels or scroll buttons. Wheels are now the standard.
Therefore, certainly Java should be able to work with wheel mice, and without
serious complexity of coding. 

This is a large productivity enhancement and as such a way should be found to
provide it.  
It is distinctly noticeable when support is absent.  As in "Oh this must
be a Java window - it won't scroll with the mouse wheel"

I believe that the Intellimouse was a very good idea and I believe that it
should be supported by Java and added to the Solaris O/S.

I too think that Java should suppor the wheel
mouse on Linux and MS platforms. Mozilla seems
to have figured out how to have cross platform 
scrolling in their code, and I believe Java should
as well. Sun, please remember that developers are
*not* your target market for Java. Regular users
of computers are. *They* are the ones who insist
that their latest gadget and gizmo that they just
bought at CompUSA work with our applications. 

Not having something as simple (to the user, remember)
as mouse wheel support really makes us developers
look bad because users simply expect stuff to work.
Users consider it our bugs when it doesn't and 
generally don't accept our excuse that "well, java 
just doesn't support that." Their next response will
always be "then don't use Java in my shop anymore."
That doesn't serve anyone's purpose.

How many bug votes does it take to get something simple
like this implemented?  It's been more then a year!

-G

Please do not forget about mices that have more than 1 wheel
and more than 2 buttons.  I am using a 3 button mouse with 2
wheel that is very convinient under X11.

everybody else has it....

but you guys have to prioritize...

From what I can understand and comprehend from the 
following discussions, and from whatever I know about JAVA, 
I can only say that let the hardware interact with the 
operating system through the drivers, while Java interacts 
with the operating system as well. Thus, hardware activity 
will send data to the operating system and the operating 
system will interact with the Java application/applet. 
Thus, instead of changing the Swing or AWT classes, 
implement changes in the JVM itself, so that wheel 
scrolling or stick movements result in the same effect, but 
without the developer having to write extra code for it. 
Well....thats my opinion...limited as it may be. Thanks.

Just wanted to note that the scroll wheels should work with
more than just JScrollPane... I would like to write code to
use it as well.
Also, the lag it takes to get something like this into Java
is a SERIOUS problem.  If Java features can't react to the
computing world fast enough, it will be left behind.

I have to admit that I am hooked on the wheel. I don't 
understand why such a simple and needed function has not 
been provided. If it is becausu it seems too microsoft, 
they are not the only ones with a wheel. This is positively 
a pet peeve with Java. The mouse wheel along with the 
optical sensor keep the mouse at the top as an input device.

Its been said before but it deserves repeating: users & management are getting
real tired of being told "sorry, Java doesn't support this".  Many C/C++ programmers
I work with ask why we still bother with Java.  Users continue to ask why we switched
from languages that offered them everything they needed to a language that can't
meet their expectations.  If it wasn't for the fact that other companies (like IBM) often
jump in and cover many of Sun's deficencies, Management would have forced us to
abandon Java a long time ago.  So many projects start off as 100% pure Java and end
up with at least 50% C++ simply because no one was satisfied with the results in Java.

Our customer is asking for mouse-wheel support. What are we 
supposed to say?

If you're interested in this bug, be sure to check out 
bug 4289845, it looks like Sun is looking at adding 
wheel support for Merlin.

This would be a great feature. Its an easy way to spot a
java application on a Windows machine.

My company is switching from an MS-centric development 
environment to a mostly-java based environment.  A major 
limitation? No support in java IDE's for the scroll 
mouse!!!  This feature of pretty much every new mouse is a 
HUGE development time saver, and it is sad to see such a 
functionally completely missing in Java.  

I too will add my vote for mousewheel support.  We recently 
wen tot JBuilder 3.5 which is entirely Java.  Now I have no 
mousewheel support.  Believe it or not, the mousewheel is a 
time saver which in turn increases productivity.  I thought 
it was silly at first.  After I tried one, I can't live 
without it.  I use it naturally now, even as I read through 
these responses.

Sun has committed in 4289845 to add mouse wheel support (it's about damn time).

Mouse wheels have become a de facto standard with nearly
every PC (whether running Windows, Linux, even Solaris). To
support them will increase portability across multiple
platforms, not hinder it. e.g. If you're on a Mac w/only one
button, only one button is supported. There's no harm in
supporting additional hardware.

If Java does not get in sync with new technologies it will 
not last long. Good Luck.

This is a serious shortcoming of Swing-based apps such as 
Forte and Together/J, jCVS, and every other Java app out 
there.  The swing GUI should support alternate input 
devices such as mouse wheels but including other devices as 
well.

Java can still be portable and support different pointing 
devices. It's a poor excuse to hide behind "portability."  
Portability does not mean don't support devices that are 
not common across all platforms.  Do some design work for 
and listen to your customers!!!!

A question is whether such a feature should be supported by 
adding a <code>mouseScrolled(MouseEvent e)</code> to 
MouseListener or MouseMotionListener or to add a new 
<i>generic</i> event type not necessarily tied to a mouse, 
such as a <code>scrollUp(ScrollEvent e)</code>. The later 
would make sense if scrolling input we implemented a 
different way on a different platform. This brings up the 
question of how AWT/Swing handles touch screens? This will 
be common on Palm type computers. Does <i>every</i> 
touchscreen event map to a mouse event?

Not supporting the wheel IS a BUG. If a feature is not 
available in a particular OS, then it doesn't work (users 
from that OS won't miss it). However it does elsewhere, not 
supporting it makes it painful for those that are used to 
using this basic "Human Interface Device".

As a more general fix, how about instituting a button mask 
for mouse buttons 4 and 5?  That way we can write our own 
code that attempts to catch buttons 4 and 5 (which are 
usualy the mouse buttons) and if that doesn't work for the 
user (because he's using a "mouse stick" ) then we can give 
him the chance to turn it off.

I think this is probably the most benign way to institute 
this feature request.  Just give us access to teh mouse 
buttons, and then let us write the code to handle it.

I you use JBuilder3.5 there is an addin that do the job :

http://czerwonykapturek.tripod.com/

It even has the mouseover scroll feature and the 
shift+scroll to roll on curent file selected !

This is Win32 only for now but as you get the whole src ...
you may port the JNI part to Linux.

Just enjoy scrolling ... before 1.4 arives :)

With the java application I've made. I always make a mistake of using the wheelbutton to scroll down and 
it's annoying everytime it does not work. :-)  It feels like being left behind times. 

"A MouseWheelListener was added to BasicScrollPaneUI.  The listener code calls
  into BasicScrollBarUI to scroll the appropriate scrollbar."

Okay, so when/where can we get this fix?  (You don't know how much whining
has gone on about this.)  Thanks.

develope software

How i can in Jsp with my java programm!

For people interested in supporting mousewheel under 
windows, go to 
http://www.codeproject.com/java/mousewheel.asp

Rather than be forced to wait for merlin to magically 
appear, I thought you should know that I've got a working 
fix at 
http://www.rosbaldeston.freeserve.co.uk/java/mousewheel/ 

fdsg
sdfg
df
sg
sdfg
df
g

Are there any hacks that enable mousewheel support globally 
without having to subclass a "special" kind of JFrame short
of merging JFrame and JMouseWheelFrame and replacing the 
class in the core library?

fixed?

Why only a *MouseWheelListener* is added to the 
BasicScrollPaneUI? What about the scrolling functionality 
of touchpads and the like?
Alternative input-devices (read: not mice) like touchpads  
often also actively support scrolling. In the case of my 
touchpad I can slide a horizontal or vertical edge and my 
window will scroll: Very convenient and intuitive. It seems 
likely to me this is caused by events sent by the device-
driver to the targeted native window, where-in the light-
weight Java components are embedded. I can imagine that 
this would be regular scrolling-events which could be 
handled as well by the Java scrolling mechanisms.