Re: [MiNT] Wheel support in XaAES

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

Hello,

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

yes, orientation (vertical/horizontal) is a property of Wheel ID, it's not  
the wheel ID.

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

I really don't care. if you keep the direction bit in 'orient', it's ok  
for... and if you decide to change the sign of wheel_amount, it's ok for  
me too :o)

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

great :) the MU_WHEEL flag will become useless...

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

I see you point : we both agree that this function may be usefull, but we  
disagree about the conclusion.

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

The function is "transform mouse wheel to slider events", and this will  
differ from an application to another. This function cannot be universal,  
because the action of mouse wheel depends on the type of  
window/application.
For example, for some application (web browser, word editor), wheel may be  
used to scroll the slider, and CTRL+wheel may be used to zoom in/out. For  
other applications (slideshow), wheel may be used to go to previous/next  
picture in the list and CTRL+wheel may be used to zoom in/out. In a  
formular, when the mouse is on a popup (not the menu popup, i meant when  
the mouse is over the G_BOXTEXT that will open a menu popup when the user  
click on it), in that case mouse wheel may be used to scroll between  
choices of the popup (without opening the menu popup), and that, even if  
the formular is in a window with sliders.

about the "large amount of processes doing the same thing is not good", i  
see two points: the resources allocated and the modularity. For resources,  
a solution is shared library. For modularity, the solution is high GEM  
library, and is not AES.

You're right: it's a very good idea to have the same look and feel in all  
applications, but this is not AES purpose. AES shall provide functions to  
inform the application about evnt that occured, and provide other  
functions to manipulate AES stuff (windows, objects...). The link between  
them is done by the application.
For example, AES send WM_CLOSED message to the application to infor it  
that the user has clicked on the close gadget, and then the application  
command the AES to close the window. If an application want to do  
something else when WM_CLOSED is received, then it's possible (for  
example, the desktop go to upper directory when the closer widget is  
clicked).

If we want (and i want) the same look and feel over application, then we  
have to write a "application Man-Machine Interface guideline", and every  
programmer shall follow these rules.

Let take few examples:
- the shortcut CTRL-U should be used to close the top window
- the shortcut CTRL-Q should be used to quit the application
- the first menu of the menu bar should contain the name of the application

If you want the AES to be responsible for the same look and feel over  
applications, then when the AES receives the CTRL-U key, evnt_multi shall  
return a WM_CLOSED message and no MU_KEYBD event. When an application  
receives CTRL-Q, the AES shall send AP_TERM and no MU_KEYBD. When an  
application install a menu (menu_bar()), the AES shall copy the registered  
name of the application in place of the 1st menu title...

Back to the wheel stuff: the AES should inform the application that an  
wheel event has occured, and the application may move the slider  
(recommanded), but can do something else if the CTRL key is pressed, or if  
the cursor is over a popup button for example.

The AES should not do any link between inputs (wheel event) and command.

It's the rule of the application, not the AES... and because most of  
theses links between inputs and command are always the same, if you don't  
want to develop this piece of code for each application, then you can use  
a high GEM library.

To sum up, the missing piece is a guideline for application look and feel.

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

there are two kind of configuration:

AES side configuration, which include the configuration of the layer  
between drivers (keyboards, mouse) and AES. This is for example the  
inversion of left and right mouse button, use middle button as double  
clic, etc... The AES side configuration also contains all internal  
parameters of the AES (widget color or skin...).

Application side configuration: how the application should react when it  
receive a particular event from the AES. This may be "scroll 3 lines on  
each mouse wheel event"...

For the application side configuration, this can be done by the AES using  
a new conf_xxx library for instance, but once again, the AES shall not  
override the role of the application.

> Another nice usage is the "click mousewheel and set scroll speed with  
> mousemovements" function.

Same remark: the AES shall report that the mouse wheel button (middle  
button for me) has been pressed, and then the application may call a new  
function wind_scroll() to do what you want. The link between "the middle  
button has been click" and the "scroll on mouse movement" command shall  
not be done by the AES. Such link can be done in the high GEM libraries.

> This most likely have a name too, but I dont know it :) This is one of  
> few things I really like to
(..)
>   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?

discussion about the select/poll stuff in the other thread.

About bigger mesage buffer... well, this is the aim of msg[2], no ? Then  
appl_read may be used to read the end of the message.

best regards,
Arnaud.