[squeak-dev] Mouse mapping preference in win32 squeak VM

Hello list,

The windows port of VM has two preferences
1 Button mouse
and
3 Button mouse

I understand that it kind of forcing VM to think that there is a mouse
with single button, or with 3 buttons.
But in windows API there are already support for 3-buttoned mices, and
you'll never get a message with middle button click if your mouse
don't have a middle button.

Also, in recordMouseEvent()  there are modifiers for red button:

red + alt -> blue
red + ctrl -> yellow

so, in this way, VM can generate events for all 3 button types even if
you having a single button mice.

Concerning '3 buttons' option, all it does is swapping the blue and
yellow buttons. But hey, we can swap blue/yellow mouse buttons from
preferences.
Maybe, historically, these preferences appeared in different time, but
currently they simply duplicate each other, and we really need only a
single one.

And at last, since mouse event recorded along with modifier keys
(alt/ctrl etc), i think that all logic concerning mouse buttons
mapping can live at language side without any loss of functionality.
What you think?


--
Best regards,
Igor Stasenko AKA sig.

 > What you think?

You description of the VM behavior is correct. And it could certainly be
moved into the image if that were desirable[*]. It's more a matter of
creating a synchronized release (i.e., one where both the preference is
on in the image and off in the VM to preserve current functionality)
after which this code could be safely removed.

[*] I'm not completely sure of that. It does create quite a bit of mess
in a fairly critical piece of code.

Cheers,
   - Andreas

Igor Stasenko wrote:

2008/11/18 Andreas Raab <[hidden email]>:
>> What you think?
>
> You description of the VM behavior is correct. And it could certainly be
> moved into the image if that were desirable[*]. It's more a matter of
> creating a synchronized release (i.e., one where both the preference is on
> in the image and off in the VM to preserve current functionality) after
> which this code could be safely removed.
>

I'm currently putting things together in a HostWindowPlugin rewrite.
The main goal is to make windowing & events optional and separated
from core VM functionality by putting all of them into new plugin.
There will be no default host window at your disposal, unless you
asking directly for it.
So, i'm concerned about making event recording more clean, preserving
most current functionality, but without obsolete stuff.

It will break some compatibility, for sure. But in the end, i hope, it
will bring more benefits than losses:
- an image could decide itself whether be headless or not
- host windows can be created with variety of different attributes (
like having titlebar/close button/border or not).

> [*] I'm not completely sure of that. It does create quite a bit of mess in a
> fairly critical piece of code.
>

Yes, considering that event handling in image is already quite a mess,
which makes the whole thing screaming: please, rewrite me! :)

> Cheers,
>  - Andreas


--
Best regards,
Igor Stasenko AKA sig.