Merge lp://staging/~chasedouglas/grail/pivot_type into lp://staging/~oif-team/grail/grail2
| Status: | Rejected |
|---|---|
| Rejected by: | Chase Douglas |
| Proposed branch: | lp://staging/~chasedouglas/grail/pivot_type |
| Merge into: | lp://staging/~oif-team/grail/grail2 |
| Diff against target: |
2417 lines (+743/-1170) 23 files modified
include/grail-bits.h (+1/-0) include/grail.h (+46/-36) src/Makefile.am (+0/-7) src/gestures-drag.c (+0/-135) src/gestures-pinch.c (+0/-129) src/gestures-rotate.c (+0/-128) src/gestures-tapping.c (+0/-100) src/gestures-touch.c (+0/-98) src/grail-api.c (+12/-96) src/grail-bits.c (+9/-0) src/grail-frame.c (+159/-48) src/grail-gestures.c (+0/-210) src/grail-gestures.h (+0/-115) src/grail-impl.h (+1/-0) src/grail-init.c (+0/-2) src/grail-inserter.c (+0/-32) src/grail-inserter.h (+0/-2) src/grail-legacy.c (+104/-0) src/grail-recognizer.c (+353/-16) src/grail-recognizer.h (+39/-4) tools/grail-test-mtdev.c (+0/-1) tools/grail-transform.c (+17/-11) utouch-grail.sym.in (+2/-0) |
| To merge this branch: | bzr merge lp://staging/~chasedouglas/grail/pivot_type |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Henrik Rydberg (community) | Disapprove | ||
|
Review via email:
|
|||
Description of the change
RFC for this changeset that adds configuration of where the pivot should be determined.
Unmerged revisions
- 154. By Chase Douglas
-
Merge in grail 2 to grail 1 translation layer
- 153. By Chase Douglas
-
As an example, tell grail to use the convex hull pivot confinement in
grail-transform. - 152. By Chase Douglas
-
Use a red dot to denote the pivot point
The pivot point is also now drawn after the touches so it is visible when
on top of a touch point. Some drawing code was simplified by using
clear_screen. - 151. By Chase Douglas
-
Make the pivot point determination configurable
* Remove moveness from grail_element
* Remove thresh_scale and thresh_drag from control
* Introduce a control for the pivot type
* Fix translation computation
* Fix grail_element_transform so it uses the pivot point
* Add new functionality for computing different pivot points
* Determine the drag value based on strictly on the centroid motion
- This should fix grail 1 translation errors - 150. By Henrik Rydberg
-
Update copyright information
The license information was always right, but the copyright information
for this particular project was never quite right. Corrected with this
patch. No functional changes.Signed-off-by: Henrik Rydberg <email address hidden>
- 149. By Henrik Rydberg
-
Introduce the grail transform tool
This tool tests the transform capabilities of grail. Similar to a
map application, one can use a single finger, two fingers, a whole
hand or two hands to move the rectangle around, scale and rotate it.Signed-off-by: Henrik Rydberg <email address hidden>
- 148. By Henrik Rydberg
-
Introduce test-mtdev
A new tool (test-mtdev) is added, showing the usage of gesture frames.
Signed-off-by: Henrik Rydberg <email address hidden>
- 147. By Henrik Rydberg
-
Add gesture transform unit tests
Start the gesture frame test suite with some basic coordinate
mapping tests.Signed-off-by: Henrik Rydberg <email address hidden>
- 146. By Henrik Rydberg
-
Document the gesture frame logic
Add some notes on the math of the gesture frame computations.
Signed-off-by: Henrik Rydberg <email address hidden>
- 145. By Henrik Rydberg
-
Introduce gesture frames
This patch extends the API with parallel new/delete functions,
aiming to eventually replace the open/close function. The new
functions give access to the grail gesture frames, containing
gestural transform information. This information is useful in its
own right, and will eventually replace the internal recognizer.Signed-off-by: Henrik Rydberg <email address hidden>
Removing the moveness threshold values, i can live with that, no biggie
The transform matrix should include the pivot, or it would no be useful for other programs which expect a linear transform, which is also the most efficient.
What you call the center of rotation is precisely the same as the moveness = 0 special case,
so configuration could instead be done by allowing the cutoff radius to vary, instead of having separate "algorithms".
The rest seems to be a reproduction of what is in grail2, only less efficiently coded.
All in all, I can imagine reducing this to a ten-line patch, on top of the other grail2 branches, handling mode switches. We should also think about how/if we should model the degrees of freedom depending on what gesture types are being asked for, or if this should really be controllable by the app, or if simply all data should be sent.
Because the patch should really go on top of the original gesture frames branch, I am rejecting this particular merge request.