Re: [MiNT] Wheel support in XaAES

[Odd Skancke <ozk@atari.org>]

 Hello,

Arnaud BERCEGEAY wrote:
> 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 ?

Yes, since I imagine apps that dont know about wheels and have no arrows
gadgets most likely will ignore WM_ARROWED messages anyway.... or?

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

 Thats what I think too :)

> >   Currently mouse wheel events are sent to the owner of the window  
> > underneath
> >  the mouse pointer
>
>
> Very good :)

 thanks :)

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

 Almost. These kinds need to have the ARROW widget, not 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)

 Again, its the ARROW widget, not 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...

> >               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?

> >                      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 !

 Thanks again :)

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

 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 
messages, the only difference is that the position value in the 
WM_xSLIDE message is passed back when setting the new slider position. 
If the application in question do not do any snapping or such stuff, the 
two values used in wind_set(handle, WF_xSLIDE, newposition, msgposition, 
0,0) will be the same. The problem is that the AES needs to accumulate 
real changes to be able to "pass a snap", if you know what i mean. So, 
the only diff is one extra param when setting the position of the slider.

> 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 
should follow my reasoning there :) Since we wanna add fselect()/fpoll() 
 functionality via evnt_multi() perhaps an extended version of 
evnt_multi() is in place?

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

 Fine by me :) The 'X' came from XaAES :)

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

 The current stuff works great with my Milan :)


regards,

  Odd Skancke