Thanks for the review Tav. It's been a busy few weeks, but I'm back.
2. Yes, I tried since the beginning to have SPCanvas::handle_touch() return false so that gtk_widget_real_touch_event() is used to generate the mouse emulation events. gtk_widget_real_touch_event() indeed gets called and generates an event, but for some reason, that event doesn't get received by Inkscape. I'll have to dig further. ----------------------------------------------------------------------------------------------------------------------- [use SPDesktop::rotate_relative_keep_point (Geom::Point const &c, double rotate);]
I tried using those functions, but couldn't avoid reading/writing the offset of the transform matrix directly.
Here's the only version that I got to work.
#if 0 desktop->_current_affine.setRotate(finalRotation); desktop->_current_affine.setScale(scale0 * scale); desktop->_current_affine.setOffset(-offset); #else Geom::Point const rotationCenter_dt(desktop->w2d(rotationCenter - desktop->_current_affine.getOffset())); // have to subtract offset because w2d matrix doesn't have it !
desktop->zoom_absolute_keep_point(rotationCenter_dt, scale0 * scale); desktop->rotate_absolute_keep_point(rotationCenter_dt, finalRotation); desktop->scroll_absolute(-offset); #endif
offset is highly coupled with the rotation and scaling. I thought there might be a way to describe the transform without that complicated expression for offset. I tried a few permutations of zoom_absolute_keep_point(), rotate_absolute_keep_point(), and scroll_absolute() but couldn't figure it out.
Is there any objection to adding a function in Desktop to set the rotation, scaling, and offset together?
-------------------------------------------------------------------------------------------------------------- "*had to roll back r15548 or else touch screen events get lost"
I've found this was a problem with gdk_seat_grab(), which doesn't listen for touch events. I've filed a report and possible solution:
https://bugzilla.gnome.org/show_bug.cgi?id=781757
This isn't a complete stopper. It only causes touch events to be dropped when using certain tools like selection. Using touch when holding other tools like tweak, there's no difference between gtk_device_grab() and gdk_seat_grab().
---------------------------------------------------------------------------------------------------------------- "How important is it to be able to scroll using two fingers?"
Probably not critical. If you use 1 finger to scroll, then you can no longer use your finger to drive the tools (I don't see any way to tell those actions apart). Giving that up might be OK, because I never pan with my fingers - only pan/zoom/rotate and dragging selections.
On Mon, Apr 24, 2017 at 5:39 AM, Tavmjong Bah <tavmjong@...8...> wrote:
Hi,
I've had a look at the code and have come comments.
General comments:
Coding style should conform to:
Loads of compiler errors of the type:
src/display.sp-canvas.cpp:1556:43: error: invalid conversion from
'gpointer {aka void*}' to 'GdkWindow* {aka _GdkWindow*}; [-fpermissive]
These are mostly in copying event data to bevent. Why is beventnecessary? Can't the function just return 'FALSE' to get gtk_widget_real_touch_event() to do the translation?
On Sat, 2017-04-22 at 04:27 -0700, Yale Zhang wrote:
Rotate should be useful. I think most people find it easier to draw vertical lines than horizontal since there's less wrist motion.
I've updated my touchscreen code to support canvas rotation. Anyone want to use it?
transform math: https://1drv.ms/u/s!AngRQgSreBCehTiw0R_rGV7gxQIP
A couple of notes: *awkward coordinate system - Why is the canvas completely off the screen when rotation=0, offset=0? It seems the window's Y axis points down while the document's Y axis points up?
Inkscape uses an inverted coordinate system as compared to SVG. This is a long standing "bug" which we hope to fix some day but it is so embedded inside Inkscape so that fixing every occurrence is a nightmare.
- why is a positive rotation counter clockwise? In a left handed
coordinate system, it should be clockwise.
It depends on where the rotation is taking place. Desktop uses right- handed, SVG uses left-handed. See above.
*I couldn't figure out how to set the rotation, zoom, and offset using the functions in the desktop class (scroll_to_point(), zoom_absolute_keep_point() and had to access the private affine matrix directly. Calling those functions in sequence seems to add unwanted offsets on top of each other instead of letting me set the offset directly.
I can help with this. One shouldn't need to access the private affine matrix. You probably want:
SPDesktop::rotate_relative_keep_point (Geom::Point const &c, double rotate);
and
SPDesktop::zoom_relative_keep_point (Geom::Point const &c, double zoom);
where 'c' is the point halfway between the two touch points in desktop coordinates:
Geom::Point const event_w(ave.x, ave.y); Geom::Point const event_dt(desktop->w2d(event_w));
c = event_dt;
Note also that rotation and scaling are handled independently of offset.
*had to roll back r15548 or else touch screen events get lost somehow.
This should be investigated as using gtk_device_grab (which you have reverted to) is deprecated.
- I couldn't figure out how to use the GTK gesture classes (which are
probably more robust), so wrote my own code for detecting zoom, rotate, and scroll gestures. When I tried, the gesture classes weren't receiving any events. 2nd, it seems only 2 finger rotation and zoom gestures are recognized, but not 2 finger scrolling. There is a 1 finger scroll gesture.
How important is it to be able to scroll using two fingers? I imagine it would be useful to be able to rotate and scroll at the same time. One finger scroll might work by ignoring the second finger.... (one would need to experiment with a gesture group containing zooming, rotating, and scrolling).
Tav
-Yale