Hullo list members,

First time writer here.

I am trying to write a (more on that later) for the Gimp that allows a 6-DOF device (specifically, a 3dConnexion SpaceTraveler) to manipulate a selected layer, with the most important functions being the ability to translate and rotate (rotating into the screen (a la perspective transform) would be nice too). Now, I tried to write a C-Plug-in but the driver for this device (on Linux) requires me to retrieve all events off an X Window -- fine, so my plugin pops up a dummy X-window to receive events. My plugin receives the events just fine and can track the state of the Device, but if I want to preview any operations I make through a gimp_dialog the X Events get squelched until the dialog closes. (Not to mention that whenever I try to use gimp_drawable_transform_rotate_default the plugin segfaults.)
So, my question is -- am I even approaching this the right way. Is there a lower level "plugin" (e.g. a Module or Extension, perhaps) that will lets me perform these operations? Has anyone tried to mimic this behavior before (I haven't seen any examples from my google searches)? The big picture is to make montaging a huge image with lots of individually-layered pictures, interactively, easier.

Thanks,

Eric J. Bowden

Thank you for the response Sven,

but if I want to preview
any operations I make through a gimp_dialog the X Events get squelched until the dialog closes.

You could do the same thing that the GIMP input controller modules do and read the events directly from the Linux Input layer instead of receiving them as X events. As long as this is the only application using the device, it should work just fine.

Is there an example of this somewhere? I've been trying to find a tutorial of some sort for the linux input API, but all I get are keyboards and mice -- the closest thing to what I've got would have to be a joystick.

Right now I've got the correct behavior, but the refresh rate is (understandably) awful. I'm basically calling the gimp_drawable_transform_2d_default procedure for each each motion event; the image drawable is changed directly (I decided to do away with the dialog box). I know that the tools>transform tools>* show outlines while performing the requested operations -- is there a way to tap into this infrastructure to improve my performance any? (Or any other performance tips/tricks would be helpful ...)

Sequentially, Eric

I know that the tools>transform tools>* show outlines while performing the requested operations -- is there a way to tap into this infrastructure to improve my performance any? (Or any other performance tips/tricks would be helpful ...)

Better yet, I've been looking at the gimprotatetool source -- it looks vaguely possible that I could instantiate a rotate tool in my plugin and simply pass it events through the motion procedure in the GimpTransformToolClass (although I confess I'm having trouble figuring out where to start). Is this a possibility? (I would like to use this route so, as I mentioned previously, I can leverage the outline-previewing capabilities of the transform tools in addition to the rotate functionality.)

Thanks, Eric

You can't access tools from a plug-in. You would have to write a tool and add it to the core.

Hrm. That's unfortunate. I don't see a way of doing this without unnecessarily duplicating a lot of work -- as creating a new core module is pretty much out of the question seeing how mind-boggling-ly monolithic the Gimp's toolbox code organization is at the moment. (Read: unknown time requirements + minimal documentation = disheartened)

Is there an example of this somewhere?

I already pointed you to it. The Linux Input controller module does it this way. This code lives in the modules directory.

Yes, I saw that -- but I don't understand quite what I can do with it; there're no comments =). Are you saying I would have to make something similar using the controller_linux_input as a "template"? Or am I supposed to register something with the input module to make it aware of the spaceball?

Thanks for your help Sven, Eric