[KPhotoAlbum] Patch for initial support for 6 degrees of freedom devices.

[Ben Martin]

On Sat, 2008-04-26 at 21:11 +0200, Jan Kundrát wrote:
> Ben Martin wrote:
> >   Attached is a patch to use the libsixdof library
> 
> Hi Ben,
> first of all, do you have a link to some information about this device, 
> so that I can at least imagine how it looks like?

This is the one I have;
http://www.3dconnexion.com/3dmouse/spacenavigator.php

But there are many such devices. The basic idea being you can move it in
x,y,z axis, tilt it in x and y and rotate it in z axis. That particular
one has 2 buttons as well.

Bindings get more interesting when you also have a load of buttons on
the device;
http://www.3dconnexion.com/3dmouse/spaceexplorer.php

Disclaimer: I'm not affiliated with 3dconnexion in any way.

> 
> > Support is currently limited to: next/prev image, zoom in/out, pan
> > around x,y and rotate image. This does make a reasonable first stab at
> > exposing functionality and using a 6dof device when in slideshow mode.
> 
> I'm only guessing about what the 6dof device looks like, but wouldn't it 
> make sense to provide some configuration for users, too?

I decided to make configuration done in ~/.libsixdofrc. This way you can
setup modal configurations (using a button to change what the movements
do until you do something else to return to the "main mode"). This is
why the function table is exposed, libsixdof takes care of the bindings
and configuration of device->function itself.

I plan on having a configuration option in sixdof that an app can call
to get a Qt/GTK widget if it wants to let the user do configuration from
the GUI... but thats a later project.

> 
> > The patch is a little ugly, the myApplication should really be migrated
> > into another cpp file etc. I'd love to use dbus/dcop to allow libsixdof
> > to automatically find and expose interesting functions to avoid the
> > function table part, but thats another story for another
> > hackfest :/
> 
> Is there any way you can get without the boost library? I'd love to 
> avoid more dependencies than is already required (unless the libsixdof 
> already depends on boost), and using another library kind of increases 
> initial requirements that a newcomer to the code must master. That's why 
> we don't use STL inside KPA, either (according to Jepser, the author).

libsixdof itself uses boost. I initially started coding it in just ANSI
C but I can move a lot faster if I take advantage of the language and
libraries I know for C++. I could possibly update the C++ interface to
libsixdof to only use function*s for its functor and signals. But there
is already the C interface which has these limitations builtin.
But it just feels strange the libsixdof C wrapper from a C++
application.

If I contain the code in a sixdof.cpp in the patch then only one file
will get the boost headers included and things will be more
compartmentalized.

> 
> The way you did the function binding also looks rather un-Qtish, but I'm 
> not sure if this can be changed.

I could make a thin wrapper, I am tempted to do so. Have a subclass of
KApplication that takes care of events for you already and throw more Qt
native feeling into the function table bindings. Also add in a
sniffWithDBus()
method that can setup function tables using dbus/dcop exposed methods
which have the right method signature. 
But once again that is more of a sixdof 0.1.0 feature :/

> 
> >   Because the autofools is a little differently setup in kphotoalbum I
> > hacked config.h to #define HAVE_SIXDOF and changed the Makefiles
> > manually here.
> 
> Please note that the kde3 branch is more or less dead now. We've 
> migrated to kde4 version and the new build system is cmake-based.
> 
> Also note that if you want this integrated in KPA, it must be switchable 
> on/off on compile time cleanly, with no manual steps required.

This is what I planned. The majority of folks don't care about 6dof. But
for those who do then having the ability to turn it on or have the build
detect 6dof and add in support would be the best compromise IMHO.

> 
> > Let me know if this is desired functionality mainline... I'm fairly keen
> > to get support mainline so I don't have to maintain a bunch of patches
> > for different apps that I add 6dof too. I'm happy to clean up the patch
> > if there is interest.
> 
> Please convert it to the kde4 version, make it easily switchable on 
> compile time and try to match "coding style" with the rest of KPA. I see 
> no problem in merging that patch, then :).

Excellent! I'll send through a new patch once I tinker with the
KDE4/KPA.

> 
> Cheers,
> -jkt
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://mail.kde.org/pipermail/kphotoalbum/attachments/20080427/205318e6/attachment.sig>