[Bf-committers] Linux plugin (was: Re: NDOF -- new commit)

[Ettore Pasquini]

On 7/31/07 4:41 PM, "Martin Poirier" <theeth at yahoo.com> wrote:

> Hi Ettore and Jean-Luc
> 
> --- Ettore Pasquini <ettore_pasquini at 3dconnexion.com>
> wrote:
> 
>> On 7/31/07 10:57 AM, "Jean-Luc Peurière"
>> <jlp at nerim.net> wrote:
>> 
>>> For when can you have your binaries ready ?
>> 
>> I have completed the linux plugin, it's available
>> here:
>> 
> http://cubelogic.org/blender/builds/2007-07-31/3DxBlender-linux-i386.tar.gz
>> 
> 
> Following the readme, When asked to map the left and
> right buttons in the driver, I couldn't find any entry
> AP1 and AP2 in the drop down menu. Selecting Button 1
> and Button 2 seemed to do the trick though. (using
> driver version 1.2.11).
> 

Thanks for letting me know. You are right. I just corrected that.  I might
have had an experimental build of the 1.2.10 driver...


> The Transform implementation is really bugging me
> though because it floods the undo levels with
> infinitesimal steps. I'm thinking it would probably be
> easier and cleaner to just add Ndof as a special input
> in the Transform functions (on par with Numerical
> input) with the twist that you could use the device to
> initiate transform and the two buttons to
> confirm/cancel once done (this would give long nice
> atomic undo steps, like normal). The down side is that
> it could only do either translation or rotation at
> once (maybe it's an upside for others though).
> 
> Sounds like a nice and easy project to do, so I'm
> putting that on top of my stack (should have some time
> in the coming weeks).
> 
> Too late for SIGGRAPH, obviously, but release is still
> far off.
> 
> Thoughts?

If I understand correctly, IMO this solution is the best for the user
because of the need to confirm or cancel what he just did - could be
stressing after a while.
I think it would be better if all this was automatic implementing maybe a
transaction mechanism, like:
- when entering transform mode, we open a new "transaction"
- user _continuously_ moves the cap as much as he wants
- once we detect a pause in user motion, we close the transaction. This will
result in one atomic undo step.
- we get ready for a new transaction.
Of course, I have no idea how the  undo mechanism work in blender ,:-) so I
don't know how feasible this is. Basically we'd need a way to group each
micro-step in a sequence of steps and expose only the sequence.
Opening/closing the transaction is doable with proper timing, or even easier
with just observing for a all-zero vector.

Just my 2 cents...

Ettore