cignoni
commented
8 years ago The main idea is that at certain event the js part invokes a cpp function that perform the "hard" part of the task (like for example selecting or reporting the info about the clicked point).
For this task we need a consistent way to pass the viewing information between the js system and the cpp part. This is fundamental because the processing part is done with actions defined in screen space.
For example this is what happens when the info picking tools is started:
- the icon of the tool is enhanced and in the tab below the option of the tools appears
- the icon of the mouse is changed and the selected tools grab the mouse focus. Since the activation of the tools all the mouse events are intercepted are intercepted and managed by the tools. Pressing alt allow to bypass the tool and the mouse event are passed as usual (so mouse movements rotate the object)
- when the user do a mouse down mouse up release, the framework call an 'apply' method of the tool plugin with the current camera parameters and the mouse position.
- camera parameters are passed using a vcg::Shotf object
There is another class of plugins that should be added with its own tab: Tools
'Tools' are pieces of functionality that include direct interaction with the mesh itself by mean of mouse actions:
Each tool plugin should manage mouse input, Should have a clear start/stop The tool tab contains an icon for each tool. The first icon is a trackball and it allow to return to the standard browsing mode. The space below the trackball is used for tool parameter. Somewhere on the screen there should be a remainder of what tool mode the system is.
To allow a robust way of implementing undo each tool can modify the mesh(es) only by mean of c++ functions that take in input a mesh and some parameters like camera and finalized mouse input (e.g. the selection tool works by calling a c++ function that take in input the view parameters and the on screen rectangle given by the user).