[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] Wheel support in XaAES
Hello,
Arnaud BERCEGEAY wrote:
Hello,
If this WM_WHEEL message is OK, I think we should use that;
msg[0] = WM_WHEEL ( 345 )
msg[1] = ID of sender
msg[2] = ...
msg[3] = window handle
msg[4] = Mouse X
msg[5] = Mouse Y
msg[6] = keyboard shift status
msg[7] = Wheel info
'wheel info' consists of the following data;
bits 0-7 - Wheel amount (Is a signed 8-bit enough?)
bits 8-11 - orient
bits 12-15 - Wheel ID (16 wheels should be enough)
'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 think that wheel ID should not be associated with orientation. This
way system is easier to configure/make configurable. Same thing with bit
0 of orient. Do we need this bit or is it enough to change sign of wheel
amount, and use the sign of that as direction?
This message, as written above, is implemented now. However, see
towards the end where I mention extending AES message lenght...
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.
If the above is good, no need for that :)
I also added more info to the WM_ARROWED message when WF_WHEEL is set
to XWHL_AROWWHEEL. msg[5,6,7] is filled with x, y and kstate respectively.
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 dont know if I agree here, because now we're talking about a
function that is supposed to work identically across applications. And
this is a function that is heavily used all the time (ok, will be :)
)... having large amount of processes doing the same thing is not good.
And if one do this extremely visible thing different to the next
process, usage of mouse wheels become an annoyance instead of a nice
tool. I think the only place for such things is in 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.
I see plenty of advantages ;-) System configureability being the
biggest issue. Another nice usage is the "click mousewheel and set
scroll speed with mousemovements" function. This most likely have a name
too, but I dont know it :) This is one of few things I really like to
steal from Windose. I also think that the AES should do calculations
based on virtual sliders, so that apps wanting to be system-friendly can
use these to calculate wheel->slider actions. By this I mean that the
app sets the coords/position of a virtual slider, and the AES uses these
when generating WM_xSLIDE messages. This way, list/scroll-boxes
everywhere behave exactly the same everywhere, respecting
wheel-sensitivity set by the user.
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, sounds good. Not implemented, tho.
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.
This is the way I envisioned in my head. And while we're at it, add
fselect() and fpoll() parameters to xevnt_multi().
2ND WAY:
consider mouse wheel just as another mouse button. This is the TORG105 way.
--------- 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...).
I dont like this way either. And since many new things will be added
simultaneously, I think we should design a proper xevnt_multi() function
that XaAES applications might use. If we, for example, add a
appl_domain() kind of thing that makes XaAES extensions, like
xevnt_multi(), available we should also extend the AES message buffer
size, so that more info can be passed without extra work. Opinions?
Regards
Odd Skancke