Re: [Xournal-devel] xournal touchscreen updates / windows to-do

[D M G. <dm...@uv...>]

Sorry Denis, everybody else. I have been quiet because I have been
traveling and I have been using a macAir during these last weeks (in
part due to its battery life, in part due to my X220 thinkpad having its
battery dying--i hate how lenovo kills batteries while they are still
useful). I might never buy a lenovo again.. we'll see...

Denis Auroux <au...@ma...> writes:

> Dear all,
>
> I finally have a laptop with dual pen+touch input (a Thinkpad Yoga),
> so some updates have been happening to how xournal handles input
> events.
>
> 1. Touch device options and tweaks:
>
> You'll see from the last few commits (in the git and cvs repositories
> at sourceforge.net) that there's now a bunch of new options and menu
> entries related to touch devices -- one is the "touchscreen as hand
> tool" option to map a touch device to the hand tool, another is a "pen
> disables touchscreen" option to disable the touch device in xournal
> when the pen is near the screen, and there are other tweaks to the
> event processing code. Note in particular, if you find that the
> interface becomes non-responsive and the pen won't stop drawing, the
> option ignore_btn_reported_up in the config file -- no menu entry for
> that one; the new default is true, the old default behavior was
> false. The old behavior is safer in terms of restoring sanity if
> xournal somehow fails to receive a button-release event, but it
> doesn't work at all with the Thinkpad Yoga's touchscreen.
>

> This is almost exclusively for Linux since in Windows the touch device
> is not recognized as a separate xinput device. (one could still use
> "pen disables touchscreen" to disable the Core Pointer when the pen is
> in range in windows as well, except the Core Pointer seems to already
> disable itself too much in Windows -- see below).
>

I have been using the "hand as touchscreen" feature for a long time in
Windows and I love it. It makes the interface much more natural (you
write with one hand, scroll with the other).

> It would be great if some of you with various touch/pen devices can
> test in the coming days and confirm that the new behavior doesn't
> cause any annoying regressions, and that the various new options do
> make life with a touchscreen somewhat better.

I will try your code in my thinkpad, although since I use my Thinkpad
Tablet 2 (TP2) I don't usually use the X220 for xournal except when I
don't have the TP2 around. But I'll try it today/tomorrow.

[...]

Ok, tested... one major bug that creates a crash. When you select the
new device the code crashes because you try to free a non-allocated
string (DEFAULT_DEVICE_FOR_TOUCH). This is a simple fix for that:

diff --git a/src/xo-file.c b/src/xo-file.c
index 59288bf..63d698c 100644
--- a/src/xo-file.c
+++ b/src/xo-file.c
@@ -1526,7 +1526,7 @@ void init_config_default(void)
   ui.poppler_force_cairo = FALSE;
   ui.touch_as_handtool = FALSE;
   ui.pen_disables_touch = FALSE;
-  ui.device_for_touch = DEFAULT_DEVICE_FOR_TOUCH;
+  ui.device_for_touch = g_strdup(DEFAULT_DEVICE_FOR_TOUCH);
   
   // the default UI vertical order
   ui.vertical_order[0][0] = 1; 


> 2. Windows:
>
> After installing MinGW more or less successfully, I'm again able to
> build xournal for windows. I got immediately hit with the issue of
> xournal crashing when done editing a text box, which has been reported
> here. Unfortunately, as soon as I tried to install gdb and add debug
> output to the code, the problem disappeared. I'll try to reproduce it
> again another day... however, if you have a working MinGW development
> environment, basic expertise in debugging, and do encounter this bug
> and can figure out where exactly things get stuck at the end of a text
> box editing action, that would be extremely useful. (Most likely, you
> want to attach gdb to a running instance of xournal and interrupt the
> execution when it gets stuck to get a backtrace.) Also, if some of you
> experience this bug intermittently, ideas about what causes it to
> happen or disappear would be helpful.

i have hit by it to the point that I don't use it. We need to check the
code. I suspect that it is a function that is expected to return a value
(potentially an error) and that is not being checked. I'll take a look
too.

> Another bug I'd like to figure out is the drawing area being
> unresponsive to touch/mouse/... after drawing with the pen with xinput
> enabled (and the wacom driver), until one clicks somewhere outside of
> the drawing area. (There seem to be other variants of this

I know what creates this (it is indeed a bug, but it is also the way you
set the canvas at startup, if I remember correctly, I have to check my
notes, since I spent some time tracking it). I'll have to look at the
code, but one of the flags in it creates it.

[...]
I don't remember exactly which one, but I think it is one of these
flags:

  // set up and initialize the canvas

  gtk_widget_show (GTK_WIDGET (canvas));
  w = GET_COMPONENT("scrolledwindowMain");
  gtk_container_add (GTK_CONTAINER (w), GTK_WIDGET (canvas));
  gtk_scrolled_window_set_policy(GTK_SCROLLED_WINDOW (w), GTK_POLICY_AUTOMATIC, GTK_POLICY_AUTOMATIC);
  gtk_widget_set_events (GTK_WIDGET (canvas), 
     GDK_EXPOSURE_MASK | GDK_POINTER_MOTION_MASK | GDK_BUTTON_MOTION_MASK | 
     GDK_BUTTON_PRESS_MASK | GDK_BUTTON_RELEASE_MASK | GDK_KEY_PRESS_MASK | 
     GDK_ENTER_NOTIFY_MASK | GDK_LEAVE_NOTIFY_MASK |
     GDK_PROXIMITY_IN_MASK | GDK_PROXIMITY_OUT_MASK);
  gnome_canvas_set_pixels_per_unit (canvas, ui.zoom);
  gnome_canvas_set_center_scroll_region (canvas, TRUE);
  gtk_layout_get_hadjustment(GTK_LAYOUT (canvas))->step_increment = ui.scrollbar_step_increment;
  gtk_layout_get_vadjustment(GTK_LAYOUT (canvas))->step_increment = ui.scrollbar_step_increment;

Now, I have talked to friends who use xournal on TP2s and they like this
bug/feature because it makes accidental scrolling non-existent. Once you
know the bug is there, every time you want to scroll, you touch the top
right side (usually have some empty space---the area to the right of the
icons) to "enable" touch again. Once you do it few times, it becomes
second nature.

> issue). Debugging the event code suggests that GTK+ never passes the
> button press and pointer motion events to us -- presumably using the
> wacom pen puts GTK+ in a mode where Core Pointer events don't get
> passed along anymore.  If this is a GTK+ bug, a custom GTK+ DLL might
> need to be packaged with the 'semi-official' Xournal win32 build. This
> one should be within my abilities -- I understand the GTK+ xinput code
> reasonably well, though I've never looked at the win32 side of it.
>
> Yet another issue is the general trouble with fonts and text and
> export / printing. I am not sure I am competent to do anything here,
> but I'll take a look. Ditto for the bug that causes copy-paste to go
> "numb" sometimes (the clipboard starts giving xournal the wrong data
> at some point, and when this happens xournal just rejects the
> copy-paste attempts instead of crashing).
>
> Any other bugs of a similar severity level (things that crash, don't
> work at all, or are generally major annoyances to using xournal in
> windows) ?

I think the paste and text box are the ones.


but there is one that really annoys me and I haven't been able to figure
out: text boxes that are "saved" as PDF are not readable in OS X, but
text boxes that are "printed" to PDF work. it is argued that it is a OS
X bug, but we if we can work-around it...

>
> Ah, another note: those of you who report that the beginning of pen
> strokes is sloppy / missing / slow to appear:
> in Windows 8.1 at least, I solved this by going to Control Panel ->
> Pen and Touch -> disable Flicks
>
>
> Thanks in advance for any feedback you can provide, either on touch
> device behavior in linux or on the main windows issues to be sorted
> out.
>
> Best,
> Denis

-dmg