Hiya<br><br><div class="gmail_quote">On Sun, Nov 23, 2008 at 11:13 PM, Ton Roosendaal <span dir="ltr"><<a href="mailto:ton@blender.org">ton@blender.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi,<br>
<br>
1) Tablet mapping<br>
<br>
I'm not a tablet user... not sure how many options you have for a pen<br>
click. Currently the tablet event is registered as-such, but I can<br>
imagine you want tablet events to map to mouse clicks. Or do we leave<br>
this to the tablet drivers to handle?</blockquote><div><br>There really isn't anything much to worry about for tablets in terms of mouse events. The drivers already map tablet buttons to mouse clicks, which is how they are interpreted in Blender. Any additional side buttons on the tablet too are generally handled by the driver, mapping them to mouse buttons, key commands, etc.<br>
<br>The only thing different about tablets is that there's extra information such as the 'active tool' (eraser or pen for example), or pressure (float value from 0.0 - 1.0) or tilt (a vector). From memory these don't really work as 'events' per se, they don't trigger anything in a queue, they're just additional information that you should be able to get at any time. For example right now there's a float get_pressure() function that you can use within a painting loop, to get the current tablet pressure at that time.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">2) Mouse mapping<br>
<br>
To efficiently make use of user configs for left/right mouse<br>
especially, we should prevent this to happen in all cases. A<br>
keymap/handler definition therefore should use these defines if you<br>
intend this to be user-defined:<br>
<br>
KM_ACTION_MOUSE<br>
KM_SELECT_MOUSE<br>
<br>
And have those translated to left/right mouse based on the user preset.</blockquote><div><br>I really don't agree with this much. The current method of just 'swapping' mouse buttons is really not the best way of doing things and makes many things awkward- it was just implemented for simplicity at the time, since there was no proper way to customise. Especially in the painting modes, things get murky. Ideally it would be great to have full customisation over mouse buttons, being able to assign different commands to left / right / middle mouse buttons (with or without modifiers), and even extra side buttons that are on some mice too.<br>
<br>For example, look what you can do with Silo:<br><a href="http://www.silo3d.com/Tutorials/Mouse_Customization/Mouse_Customization.html">http://www.silo3d.com/Tutorials/Mouse_Customization/Mouse_Customization.html</a><br>
<br>i.e. not only should it be possible to set up customisable tools/menus on mouse buttons (i.e. left click select, right click radial menu) but it should also make it possible to make setups that mimic the 3D navigation configs in other apps (eg. Maya: Alt LMB rotate, Alt MMB pan, Alt RMB, zoom). Having just two options doesn't give nearly the amount of flexibility required.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">4) Simpler mouse support<br>
<br>
How will we support one- or two-button mice (laptops)? The current<br>
mapping gives conflicts with hotkeys in cases, will need some<br>
experimenting.</blockquote><div><br>With the above customisation, this could just be a matter of shipping with a preset '2 button mouse config' that just remaps things in a more convenient way for those devices.<br>
<br>cheers<br><br>Matt<br><br></div></div>