[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] Wheel support in XaAES
Hello,
The below is how I imagine wheel-support can be done in XaAES and is
already
implemented.
What a good news ! Great :)
However, I think that we need to find a decent value for WM_WHEEL,
it is 345 for now. Anyway, test this and let me know how it works.
XaAES and wheel mouse handling.
This has changed a little compared to the original documentation and
implementation. When the wheel is on a window whose owner dont know
about
mouse wheels at all, normal WM_ARROWED messages are sent.
... but only if the window has the corresponding slider, right ?
There is no extra
info added to these messages in this case, as it were in the original
implementation.
I think it's not a pb. If one want to manage the wheel... then he just has
to ask for wheel messages.
Currently mouse wheel events are sent to the owner of the window
underneath
the mouse pointer
Very good :)
in all cases except when owner of mouse_lock() is waiting
for MU_WHEEL.
Well... i see 3 kind of applications:
- applications that don't support mouse wheel: they will receive standard
WM_ARROWED messages only if the window has the corresponding slider.
- applications that support WM_WHEEL messages: they will receive WM_WHEEL
messages on mouse wheel click (msg[3] is the window under the mouse, even
if the window doesn't have the corresponding slider)
- applications that manage mouse wheel thru MU_WHEEL data. The main
evnt_multi() loop has the MU_WHEEL bit set, but this application may
perform some evnt_mesag() calls, or some evnt(MU_MESAG|MU_TIMER) calls and
here, the message WM_WHEEL should not be sent (imo) !
The problem is for the 3rd kind of application. If the application is busy
sending and receiving AES messages (GEMscript, VA-protocol...) and uses a
second evnt_multi(MU_TIMER|MU_MESAG) loop for that purpose, in that case a
mouse wheel click shall not be transformed to a WM_ARROWED message, nor to
a WM_WHEEL message.
This is an important point for me, because with the current design of
mouse wheel in XaAES, all my softwares will be of the 3rd kind.
I propose a simple solution few lines later...
For programmers who want to take advantage of mouse wheels in a better
way,
here's an overview;
wind_set(handle, WF_WHEEL, mode, wheel_mode, 0, 0);
handle Window handle, or 0 if one wants settings to apply to all
windows
opened hereafter by the application.
mode 0 = Turn extended wheel awareness off, 1 = Turn on.
wheel_mode
XWHL_REALWHEEL ( 0 )
When wheel_mode is set to 0 (XWHL_REALWHEEL), XaAES will
send
real wheel messages, constructed as follows;
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)).
XWHL_AROWWHEEL ( 1 ) This is the default wheel_mode
set if the
value passed is outside the available range. When this
mode is
selected, normal WM_ARROWED messages are sent upon each
wheel
turn. With this mode, WM_ARROWED messages are send even
when
the window has no ARROW gadgets.
Good !
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.
For this to work, WF_VSLIDE/WF_HSLIDE wind_get/set() modes
have
been extended. When the application gets the WM_xSLIDE
message,
it must pass back the position from the message unmodified
together with your modified position;
wind_set(handle, WF_[V,H]SLIDE, postion, unmodified, 0, 0);
Even if the application snaps slider movements and finds
that
the slider does not move, it has to pass back the
unmodified
slider position via wind_set(). In cases where the original
slider position match the prevsiously set position, XaAES
does
not set or redraw the slider. But it needs to collect the
'real'
position of the slider for wheel -> slider calculations to
work.
I think i understand the reason of this mode. In most systems that support
the wheel (i only tested mandrake and windows), a mouse wheel click is
equivalent to 3 (it's an average) line up/left/dw/right messages. For
example, in my xterm windom (under linux), the window content scroll by 3
lines per mouse wheel click.
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 cflib or
windom. Furthermore, i don't think that this mode will made the programmer
life easier. If a programmer want to transform a mouse wheel click to
several lines movement, then the easier way is to catch WM_WHEEL message
and call 3 times the internal function "move 1 line up/down" of the
application.
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.
Last:
for the naming of the constant, i would vote for removing the first 'X'
letter (WHL_REALWHEEL is ok, no need to prefix with a 'X')
best regards,
Arnaud.
PS: i'm very happy with the work done on the mouse wheel in XaAES... i
hope my atari hardware will soon support the mouse wheel ;)