[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] Wheel support in XaAES
Hello,
msg[0] = WM_WHEEL ( 345 )
msg[1] = ID of sender
msg[2] = ...
msg[3] = window handle
msg[4] = orient
msg[5] = wheel ID
msg[6] = wheel amount
msg[7] = Not used, always 0
'orient' is a bitmask where bit 0 indicates direction,
and
bit 1 indicates orientation;
bit 0 - 0 = up or left
1 = down or right
bit 1 - 0 = vertical (bit 0 indicates UP/DOWN)
1 = horizontal (bit 0 indicates LEFT/RIGHT)
'wheel ID' contains the wheel number. 0 is wheel #1,
etc..
'wheel amount' holds the number of wheel-turns.
I like this message... but an important information is missing: the
position of the mouse pointer (x and y). Without this information, the
message seems useless for me (anyway, it's far better than
WM_ARROWED/WA_WHEEL (IMO)).
I completely agree, we need to find a way to provide X and Y of mouse
too. Problem is... how?
msg[0] = WM_WHEEL ( 345 )
msg[1] = ID of sender
msg[2] = ...
msg[3] = window handle
msg[4] = X-position of the mouse
msg[5] = Y-position of the mouse
msg[6] = wheel ID
msg[7] = wheel amount
'wheel ID' contains the wheel number in the low byte (so we are limited to
256 wheels), and the high byte may be 0 (vertical wheel) or 1 (horizontal
wheel).
'wheel amount' holds the number of wheel-turns, positive value if the
wheel goes up/right, or negative value if the wheel goes down/left.
There's no spare word for futur extension... and the message doesn't have
the kstate information (less important than x/y position of the mouse, but
usefull too).
I think this mesage is ok for most applications. If one wants more
informations (kstate), then he has to add the MU_WHEEL flag in its
evnt_multi() loop.
XWHL_SLDRWHEEL ( 2 )
When wheel_mode is set to 2 (XHWL_SLDRWHEEL), XaAES
converts
wheel turns into slider movements. XaAES sends standard
WM_VSLID/WM_HSLID messages reflecting the wheel turns.
(...)
the slider equivalent is a good idea, but the AES is not the right
place for that (IMO). The right place for such stuff (transform mouse
wheel click to movement of several lines) is a higher GEM library like
(...)
Here I dont agree. The idea of having the AES do this is because then
the user can set a wheel-sensitivity that goes for all apps supporting
this mode. Using this mode is no harder than with normal WM_xSLIDE
I think we're not talking on the same thing.
What i'd like to say *is not* "remove this mode: it's not easy to use and
noboby will use it".
What i'd like to say *is* "AES must stay as simple and clean as possible".
If a function can be done by the application because the AES provides all
the requiered informations, then the right place for this function is in
the application, or in a high level GEM library. The right place is not
the AES.
I tried to understand to aim of this extension, and if AES is the right
place for this feature. IMO, AES should only provide function that can
only be done by the AES, or function that are done in a better way by the
AES than by an application. For this new mode, any application can very
easily simulate this mode by reading WM_WHEEL mesag and transform it to
slider event... it's very easy to do in the application side. I see no
advantage to add this feature in the AES.
BTW, there's a missing wheel_mode :
XWHL_MUWHEEL_ONLY, or XWHL_QUIET, or XWHL_NO_MSG to tell the AES that
the application will call event_multi() with MU_WHEEL when he'd like
to read mouse wheel events. The AES shall never transform mouse wheel
click to message.
Yes. This sounds reasonable. Regarding MU_WHEEL events, read what I
wrote at line 421 in xa_evnt.c and give me your thoughts. I think we
I agree :)
Let's talk about a clean way to implement mouse wheel in AES interface.
ATM, for the mouse, we have the following functions:
- evnt_mouse() to wait event on mouse position
- evnt_button() to wait event on mouse button
- evnt_multi() with flags MU_BUTTON, MU_M1 and MU_M2.
I see two ways for the mouse wheel feature:
1ST WAY:
we can consider mouse wheel as an independant feature. in that case, we
can think of a new function evnt_mwheel() to wait event on a wheel, and
MU_WHEEL as extra flag for evnt_multi().
short evnt_mwheel( short *mx, short *my, short *kmeta, short *wheel_id,
short *wheel_amount); with wheel_id and wheel_amount as defined in the
WM_WHEEL message. This function returns when a mouse wheel click occurs.
The evnt_multi() function will have two extra parameters: short *wheel_id
and short *wheel_amount, and an extra flag MU_WHEEL.
2ND WAY:
consider mouse wheel just as another mouse button. This is the TORG105 way.
-------- start -----------
Declaration: WORD evnt_button(WORD ev_bclicks, WORD ev_bmask,
WORD ev_bstate, WORD *ev_bmx,
WORD *ev_bmy, WORD *ev_bbutton,
WORD *ev_bkstate, WORD *ev_bwhlpbuff);
ev_hwlpbuff is a pointer to the 16 WORD (32 byte) wheel buffer. The
values in this buffer are valid if bit 7 (0x80) is set in
ev_bbutton. The wheel buffer provides the (signed) scroll width for
each available mouse-wheel.
--------- end -------------
-------- start -----------
Declaration: WORD evnt_multi(WORD ev_mflags, WORD ev_mbclicks,
WORD ev_mbmask, WORD ev_mbstate,
WORD ev_mm1flags, WORD ev_mm1x,
WORD ev_mm1y, WORD ev_mm1width,
WORD ev_mm1height, WORD ev_mm2flags,
WORD ev_mm2x, WORD ev_mm2y,
WORD ev_mm2width, WORD ev_mm2height,
WORD *ev_mmgpbuff, WORD ev_mtlocount,
WORD ev_mthicount, WORD *ev_mmox,
WORD *ev_mmoy, WORD *ev_mmbutton,
WORD *ev_mmokstate, WORD *ev_mkreturn,
WORD *ev_mbreturn, WORD *ev_mwhlpbuff);
The function evnt_multi is extended by one parameter, like
evnt_button. ev_mwhlpbuff corresponds to ev_bwhlpbuff used in
evnt_button.
--------- end -------------
Well... if you want to have my opinion, i don't like the 2ND WAY. I prefer
the 1ST WAY (a mouse wheel is not a mouse button: we cannot wait for mouse
wheel click to be pressed or released...).
best regards,
Arnaud.