From mint-bounce@lists.fishpool.fi Tue Oct 26 02:15:39 2004 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Message-ID: <417D9690.4060707@atari.org> Date: Tue, 26 Oct 2004 02:13:04 +0200 From: Odd Skancke User-Agent: Mozilla Thunderbird 0.8 (X11/20040928) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mint@fishpool.com Subject: Re: [MiNT] Wheel support in XaAES References: <417CD550.80306@atari.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-To: mint-bounce@lists.fishpool.fi X-original-sender: ozk@atari.org 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=3.8 tests=BAYES_00, RCVD_IN_SORBS X-Spam-Level: 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