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 <aur...@math.berkeley.edu> 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
------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://www.hpccsystems.com
_______________________________________________
Xournal-devel mailing list
Xournal-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xournal-devel
