From mint-bounce@lists.fishpool.fi Tue Mar 22 00:11:34 2005 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Subject: Re: [MiNT] gemlib: change some AES constant names From: "Evan K. Langlois" To: Arnaud BERCEGEAY Cc: mint@fishpool.com In-Reply-To: References: <1111438016.11608.19.camel@taro.coolrunningconcepts.com> Content-Type: multipart/alternative; boundary="=-ogqbr4a22q1JnSP/gDB5" Organization: Cool Running Concepts Date: Mon, 21 Mar 2005 17:09:24 -0600 Message-Id: <1111446565.11608.47.camel@taro.coolrunningconcepts.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc14.midphase.com X-AntiAbuse: Original Domain - fishpool.com X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - CoolRunningConcepts.com X-Source: X-Source-Args: X-Source-Dir: X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-To: mint-bounce@lists.fishpool.fi X-original-sender: Evan@CoolRunningConcepts.com Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: X-Virus-Scanned: by amavisd-new at relay.boerde.de X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on relay.boerde.de X-Spam-Status: No, hits=-0.9 tagged_above=-50.5 required=7.0 tests=AWL, BAYES_00, HTML_MESSAGE X-Spam-Level: --=-ogqbr4a22q1JnSP/gDB5 Content-Type: text/plain Content-Transfer-Encoding: 7bit > The default is the reception of standard WM_ARROWED message if the window > has arrow widgets. So, for old application that are not aware of mouse > wheel, a mouse wheel clic will scroll the window content of 1 line (1 > WM_ARROWED message). Ok - the sane default is good. > Application that are aware of XaAES mouse wheel support have to declare > this to XaAES by calling > > wind_set( handle, WF_OPTS, 1, WO0_WHEEL, 0, 0); OK - and what happens if I have a mouse with two scroll wheels for vertical and horizontal scrolling? > Then, this window will receive extended message on mouse wheel event. The > default event is the extended WM_ARROWED message. The application can > change that by calling > > wind_set( handle, WF_WHEEL, 1, WHEEL_XXX, 0, 0); > > where WHEEL_XXX may be > #define WHEEL_MESAG 0 /**< AES will send #WM_WHEEL messages */ > #define WHEEL_ARROWED 1 /**< AES will send #WM_ARROWED messages */ > #define WHEEL_SLIDER 2 /**< AES will convert mouse wheel events to > slider events */ > > The extended WM_ARROWED message contains the number of lines to scroll per > mouse wheel click. Ah - thank you very much for the explanation! > The mouse button API is good to check simple-double-triple click on a > particular mouse button, to check the "mouse pressed" event, or the "mouse > released" event... It's not the same for mouse wheel. For mouse wheel, the > relevant information is the number of click that occured, and AES should > buffer them. For example, an application catch a mouse wheel clic, and > scroll the content of the window (or perform a zoom, or whatever attached > to the mouse wheel event)... If the user performs another mouse wheel > click while the application is busy (that is, out of the AES evnt_multi() > function), then the AES should send another WM_WHEEL (or extended > WM_ARROWED, or...) message, which is not possible if the mouse wheel click > is treated just like a standard mouse button. There is no buffering of events that happen outside of evnt_multi? Evnt_multi() and evnt_button() both return the number of times the button was pressed, so I assumed the AES would simply buffer the clicks. > In my opinion, the following should suit to all needs: > > - standard WM_ARROWED for applications that are not aware of mouse wheel > - WM_WHEEL message for applications that are aware of mouse wheel. I agree! > Last point: mouse wheel event should be use for a lot of things, and > moving the slider is just one of them (zoom in image viewer, go to > next/previous page in history for web browser, etc... depending of the > kstate (ctrl, shift...) and the type of application). I use mouse wheels to scroll pdfs and change pages, zoom images in my viewer, but have it off for the web browser ... I prefer to scroll the page with the wheel. Maybe if my mouse supported a second wheel, but I use a graphics tablet with only 1 wheel. Speaking of graphics tablet, is there another extension for mouse "pressure" and "device"? My graphics tablet and some touch screens will report pressure, and some support alternative input devices - like my mouse, eraser, and pen can all control the cursor globally depending on which one is on top of the tablet, but graphics applications know which device I'm using so that I can assign virtual tools to my mouse devices seperately. Pressure on mine is a byte value, but its higher on more expensive devices, up to 16 bit I think. > > To answer the question, WHL_REALWHEEL does seem redundant. I'm fine > > with the label change. > > good :) --=-ogqbr4a22q1JnSP/gDB5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit 
The default is the reception of standard WM_ARROWED message if the window  
has arrow widgets. So, for old application that are not aware of mouse  
wheel, a mouse wheel clic will scroll the window content of 1 line (1  
WM_ARROWED message).

Ok - the sane default is good.

Application that are aware of XaAES mouse wheel support have to declare  
this to XaAES by calling

wind_set( handle, WF_OPTS, 1, WO0_WHEEL, 0, 0);

OK - and what happens if I have a mouse with two scroll wheels for vertical and horizontal scrolling?

Then, this window will receive extended message on mouse wheel event. The  
default event is the extended WM_ARROWED message. The application can  
change that by calling

wind_set( handle, WF_WHEEL, 1, WHEEL_XXX, 0, 0);

where WHEEL_XXX may be
#define WHEEL_MESAG     0   /**< AES will send #WM_WHEEL messages */
#define WHEEL_ARROWED   1   /**< AES will send #WM_ARROWED messages */
#define WHEEL_SLIDER    2   /**< AES will convert mouse wheel events to  
slider events */

The extended WM_ARROWED message contains the number of lines to scroll per  
mouse wheel click.
Ah - thank you very much for the explanation!

The mouse button API is good to check simple-double-triple click on a  
particular mouse button, to check the "mouse pressed" event, or the "mouse  
released" event... It's not the same for mouse wheel. For mouse wheel, the  
relevant information is the number of click that occured, and AES should  
buffer them. For example, an application catch a mouse wheel clic, and  
scroll the content of the window (or perform a zoom, or whatever attached  
to the mouse wheel event)... If the user performs another mouse wheel  
click while the application is busy (that is, out of the AES evnt_multi()  
function), then the AES should send another WM_WHEEL (or extended  
WM_ARROWED, or...) message, which is not possible if the mouse wheel click  
is treated just like a standard mouse button.

There is no buffering of events that happen outside of evnt_multi?  Evnt_multi() and evnt_button() both return the number of times the button was pressed, so I assumed the AES would simply buffer the clicks.

In my opinion, the following should suit to all needs:

- standard WM_ARROWED for applications that are not aware of mouse wheel
- WM_WHEEL message for applications that are aware of mouse wheel.
I agree!

Last point: mouse wheel event should be use for a lot of things, and  
moving the slider is just one of them (zoom in image viewer, go to  
next/previous page in history for web browser, etc... depending of the  
kstate (ctrl, shift...) and the type of application).
I use mouse wheels to scroll pdfs and change pages, zoom images in my viewer, but have it off for the web browser ... I prefer to scroll the page with the wheel.  Maybe if my mouse supported a second wheel, but I use a graphics tablet with only 1 wheel.

Speaking of graphics tablet, is there another extension for mouse "pressure" and "device"?  My graphics tablet and some touch screens will report pressure, and some support alternative input devices - like my mouse, eraser, and pen can all control the cursor globally depending on which one is on top of the tablet, but graphics applications know which device I'm using so that I can assign virtual tools to my mouse devices seperately.  Pressure on mine is a byte value, but its higher on more expensive devices, up to 16 bit I think.

> To answer the question, WHL_REALWHEEL does seem redundant.  I'm fine
> with the label change.

good :)

--=-ogqbr4a22q1JnSP/gDB5--