Re: [MiNT] gemlib: change some AES constant names

["Arnaud BERCEGEAY" <arnaud.bercegeay@free.fr>]

Hello,

> 1 - if you can tell the AES if you want slider, arrow, or wheel events,
> then the application programmer has enough logic to know that the wheel
> event exists, and could easily handle a wheel event as arrow or slider
> events themselves.

right.

IMO, WM_WHEEL message is enought. Then, when an application receive such  
message, the application can decide to move the slider or to do something  
else...

BTW, XaAES provides 3 ways to inform an application that the mouse wheel  
has been turned, and the application should choose the more suitable.

> 2 - The mouse wheel itself shouldn't require that the application have
> specific support for it, so I'm assuming that slider events are a
> default?  or is the default something else?

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).

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);

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.

You can read /freemint/xaaes/src.km/newcalls.txt for more details.

> 3 - The AES already supports more than 3 buttons, and a mouse wheel
> isn't an analog device.  Its actually clicking button 4 or 5 when you
> turn the wheel.  In my opinion, the API already supports these buttons!
> Likewise, the horizontal wheel is buttons 6 and 7 usually.

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.

> Wouldn't it be easier to have the AES send slider messages (and maybe
> send arrows if there are no sliders on the window) if the application
> doesn't have mouse buttons 4 and 5 in the button mask, and just send the
> button events if they are?

I don't like very much the idea of having mouse wheel click attached to  
mouse button, and i think that mouse wheel API should be simplified.

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.

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).

> To answer the question, WHL_REALWHEEL does seem redundant.  I'm fine
> with the label change.

good :)


best regards,
Arnaud.