[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] gemlib: change some AES constant names
The default is the reception of standard WM_ARROWED message if the window
has arrow widgets. So, for old application that are not aware of mouse
wheel, a mouse wheel clic will scroll the window content of 1 line (1
WM_ARROWED message).
Ok - the sane default is good.
Application that are aware of XaAES mouse wheel support have to declare
this to XaAES by calling
wind_set( handle, WF_OPTS, 1, WO0_WHEEL, 0, 0);
OK - and what happens if I have a mouse with two scroll wheels for vertical and horizontal scrolling?
Then, this window will receive extended message on mouse wheel event. The
default event is the extended WM_ARROWED message. The application can
change that by calling
wind_set( handle, WF_WHEEL, 1, WHEEL_XXX, 0, 0);
where WHEEL_XXX may be
#define WHEEL_MESAG 0 /**< AES will send #WM_WHEEL messages */
#define WHEEL_ARROWED 1 /**< AES will send #WM_ARROWED messages */
#define WHEEL_SLIDER 2 /**< AES will convert mouse wheel events to
slider events */
The extended WM_ARROWED message contains the number of lines to scroll per
mouse wheel click.
Ah - thank you very much for the explanation!
The mouse button API is good to check simple-double-triple click on a
particular mouse button, to check the "mouse pressed" event, or the "mouse
released" event... It's not the same for mouse wheel. For mouse wheel, the
relevant information is the number of click that occured, and AES should
buffer them. For example, an application catch a mouse wheel clic, and
scroll the content of the window (or perform a zoom, or whatever attached
to the mouse wheel event)... If the user performs another mouse wheel
click while the application is busy (that is, out of the AES evnt_multi()
function), then the AES should send another WM_WHEEL (or extended
WM_ARROWED, or...) message, which is not possible if the mouse wheel click
is treated just like a standard mouse button.
There is no buffering of events that happen outside of evnt_multi? Evnt_multi() and evnt_button() both return the number of times the button was pressed, so I assumed the AES would simply buffer the clicks.
In my opinion, the following should suit to all needs:
- standard WM_ARROWED for applications that are not aware of mouse wheel
- WM_WHEEL message for applications that are aware of mouse wheel.
I agree!
Last point: mouse wheel event should be use for a lot of things, and
moving the slider is just one of them (zoom in image viewer, go to
next/previous page in history for web browser, etc... depending of the
kstate (ctrl, shift...) and the type of application).
I use mouse wheels to scroll pdfs and change pages, zoom images in my viewer, but have it off for the web browser ... I prefer to scroll the page with the wheel. Maybe if my mouse supported a second wheel, but I use a graphics tablet with only 1 wheel.
Speaking of graphics tablet, is there another extension for mouse "pressure" and "device"? My graphics tablet and some touch screens will report pressure, and some support alternative input devices - like my mouse, eraser, and pen can all control the cursor globally depending on which one is on top of the tablet, but graphics applications know which device I'm using so that I can assign virtual tools to my mouse devices seperately. Pressure on mine is a byte value, but its higher on more expensive devices, up to 16 bit I think.
> To answer the question, WHL_REALWHEEL does seem redundant. I'm fine
> with the label change.
good :)